|
Hi, To store (and use) our users password in the database, we use the couple of function ENCRYPT and DECRYPT. To encrypt the password we use the following instruction : UPDATE USR SET UsrPass = ENCRYPT('toto', 'TheVeryLongKey', '(AES256') WHERE ...
Lately we decide to change the key of encryption, so to get all the users password of a database we execute the folowing select : SELECT UsrID, CAST(DECRYPT(UsrPass, 'TheVeryLongKey, 'AES256') AS LONG NVARCHAR) AS UsrPass FROM USR ORDER BY UsrID" For most of the our client database we didn't have problems but on two database we have this error : ERROR : -851 08W63 Decryption error: Input must be a multiple of 16 bytes in length for AES I d'ont understand why we have this error and how to "fix" it. |
|
I finally found the solution : the "usrpass" was not encrypted for only one user in those twoe database ! Thank you all for your responses. I will have a little chit chat with some people on monday :). Fun fact, when I execute "SELECT UsrID, CAST(DECRYPT(UsrPass, 'TheVeryLongKey', 'AES256') AS LONG NVARCHAR) AS UsrPass FROM USR ORDER BY UsrID" in interactive sql I don't have the error message, it manage to give me a readable string. |
|
Other than the typo in the encryption algorithm '(AES256', your commands look OK, i.e. SELECT CAST(DECRYPT(
ENCRYPT('toto', 'TheVeryLongKey', 'AES256'), 'TheVeryLongKey, 'AES256') AS LONG NVARCHAR)
does return 'toto'. This would imply that somewhere in your database there are rows where the column contains a value not inserted using this method. You can run You can also check with the isencrypted function whether the data has been encrypted with the specified algorithm and key.
(09 Dec '21, 15:38)
Volker Barth
|
Aside: Do you need to store actual (albeit encrypted) passwords? Often it is more secure to never store them but only their (probably salted) hash. That's what SQL Anywhere does itself, too.
FWIW: Is the according column a (LONG) BINARY? AFAIK, otherwise character set conversion could lead to issues.
Yes the column is a long binary.
It is the fastest way for us to secure this part, but I know it is not the optimal way to do it.
We had a similar situation where we had to change the encryption key. After much QA and discussions we decided to prompt the users with new passwords. We also lost the password history for each user but it was deemed that it is a one time effort for the users. There may be bad data in the databases due to whatever reasons.
Oops. That's undesireable.