Handle unencrypted password in login-password for topology node
Description
blocks
is blocked by
relates to
split to
Activity
Ivan Hraško February 14, 2024 at 8:35 AM
.. and waiting for cherry-picks to stable branches.
Ivan Hraško February 14, 2024 at 8:32 AM
Now we need to complete .
Ivan Hraško February 14, 2024 at 8:27 AM
This issue has been solved by https://git.opendaylight.org/gerrit/c/netconf/+/109035 and in .
Ivan Hraško January 5, 2024 at 10:09 AM
The issue is blocked by and . The change type to binary does not solve those as the only way to reliably use encryption service is via RPC. Needs more investigation.
Peter Šuňa October 24, 2023 at 9:09 AM
I will investigate the potential consequences of AAAEncryptionServiceImpl throwing an exception in case of encryption or decryption failure. IMHO, the primary concept is to delegate the validation of password values to the data store, relieving upper layers of this responsibility.
netconf-node-topology:login-password/password
is supposed to keep the encrypted password of a NETCONF device. However, in some cases a password saved in field may work even if it's not properly encrypted becauseAAAEncryptionService.decrypt
may return the original password when decryption fails.For example, the following request with unencrypted password
makes controller attempt to establish a NETCONF session with
adminadmin
as the password after failing to decrypt the password:In this case the connection failed because the password is incorrect. But there are many cases where the correct unencrypted password works.
This behavior encourages keeping unencrypted password in the configuration because it may not discovered or it may be simply ignored because it works. Also, this may cause confusion since some may work but some may not.
So the device should not be activated when decryption fails to mitigate the issue.