NetXMS Support Forum

Hi,

I'm using agent authentication feature but there is something that I'm unable to understand.

I encoded 1234567890 using nxencpasswd tool and I got kc23yKtK4oq+OxuoSFDBCcKmCn7xK8e4wqYKfvErx7g= as value. I put 1234567890 in the agent parameter on console (see attachment agent_params_1) and kc23yKtK4oq+OxuoSFDBCcKmCn7xK8e4wqYKfvErx7g= in the agent configuration file (see attachments agent_config_1). Everything works fine, I'm able to communicate with the agent.

Then I did another test: I put the SHA1 value of 1234567890 (that is 01b307acba4f54f55aafc33bb06bbbf6ca803e9a) on both side, agent configuration file (see attachment agent_config_2) and agent parameter in the console (see attachment agent_params_2) and it works fine.

Finally, I did the third test putting directly 1234567890 in both places (agent config file and agent params, I avoided to attach this screenshot) and even in this case it works fine. So, seems that whatever I put works...

As per this post:

https://www.netxms.org/forum/configuration/agent-authentication/

I have to encrypt the password using nxencrpasswd to use the EncryptedSharedSecret! But as per my tests seems that it works even using it as it is

Please not that I have always restarted the agent after changing the shared secret.

Regards,
Marco

You dont put a hash into the config, you put the shared secret in there.
The agent and server then hash it internally to communicate.

So in your example 1, agent hashed '1234567890' into a SHA1 hash, sent data to server.
Server checked data by checking if its configured secret matches the SHA1 hash.

In your example 2, its actually the same, but the shared secret '01b307acba4f54f55aafc33bb06bbbf6ca803e9a' is hashed using SHA1.
That means, that while you input a shared secret that is theoretically a SHA1 hash in itself, Agent and server still hashed it.

Communication would not be possible if both sides only knew the hash, thats not how cryptography works.
Both sides need to know the clear-text secret in order to create hashes and validate the payload.

In case 3, you input an encrypted shared key.
Agent decrypts it, then hashes the cleartext value and sends data to server.
Server also decrypts the shared key, and again checks if the hash of the received data matches its cleartext shared secret.

The encryption only serves the purpose of both parties not exposing the shared secret directly in cleartext in configuration files / database.

Hi Tomaskis,

I'm still not understanding

Quote from: tomaskir on March 27, 2017, 11:47:35 PM
You dont put a hash into the config, you put the shared secret in there.
The agent and server then hash it internally to communicate.

my point is that I'm able to successfully communicate with the agent in all the three cases and, as per your explanation, sounds differently:

Quote from: tomaskir on March 27, 2017, 11:47:35 PM
Communication would not be possible if both sides only knew the hash, thats not how cryptography works.
Both sides need to know the clear-text secret in order to create hashes and validate the payload.

and I should'n be able to communicate in all cases I shown.

Regards,
Marco

In which case should communication not be possible?

As I posted above, even if you put a secret that is a hash itself into the configs, NetXMS doesnt treat it as a hash, but as a clear-text shared secret.

Quoten your example 2, its actually the same, but the shared secret '01b307acba4f54f55aafc33bb06bbbf6ca803e9a' is hashed using SHA1.
That means, that while you input a shared secret that is theoretically a SHA1 hash in itself, Agent and server still hashed it.

Quote from: tomaskir on March 28, 2017, 12:30:51 PM
In which case should communication not be possible?

As I posted above, even if you put a secret that is a hash itself into the configs, NetXMS doesnt treat it as a hash, but as a clear-text shared secret.

Quoten your example 2, its actually the same, but the shared secret '01b307acba4f54f55aafc33bb06bbbf6ca803e9a' is hashed using SHA1.
That means, that while you input a shared secret that is theoretically a SHA1 hash in itself, Agent and server still hashed it.

According to documentation I understand that I have to put encrypted value (with nxencpasswd) into the EncryptedSharedSecret parameter but in my 2nd and 3rd example I didn't encrypt anything:

https://wiki.netxms.org/wiki/Agent_Configuration_File
EncryptedSharedSecret
Agent's shared secret used for remote peer authentication, encrypted using "nxencpasswd -a". If RequireAuthentication set to no, this parameter has no effect.

I'm aware that technically I can just compare the two values and if they don't match I can try to decrypt one then check again if they match (and so on...), but honestly to me doesn't seems so clear reading the doc, this is the reason for the question

Regards,
Marco

As mentioned previously, agent and server need cleartext key to communicate.

You can encrypt the cleartext key in Agent, or on Server, thats OK.
Or you can only encrypt the key on one side, thats also OK.

Since encryption is a reversable process, as long as both parties can get the cleartext key (either have it input directly, or decrypt it when provided as encrypted using nxencpasswd), then communication can happen.

After both parties have the cleartext key, they can use hashing crypto functions to assure that communication is authenticated and secured.

I hope that better explains it

Maybe its best to exactly describe a scenario that you think should not work, and we can see whats happening

Quote from: tomaskir on March 28, 2017, 03:46:31 PM
You can encrypt the cleartext key in Agent, or on Server, thats OK.
Or you can only encrypt the key on one side, thats also OK.

Yes, this is what I found myself with the three different tests, and this is why I said that from the documentation I wasn't able to understand that you can have all the combination, since for the clear text on the agent side there is the field SharedSecret


Regards,
Marco