yehster wrote on Thursday, May 16, 2013:
Preliminary version of password security changes.
The basic premise is anywhere client-side SHA1 hashing of passwords was previously done has been replaced with RSA encryption of the password.
In addition, simple SHA1 hashing previously in place has been replaced with blowfish + salt. Now stored in new table “users_secure”. With the intention of implementing a mechanism where a database user with higher privileges will be used to handle user/password operations in the near future. This approach should mitigate some risk of SQL-Injection issues.
An administrator creating a user or changing an existing user’s password requires re-confirmation of the administrator’s password.
A user changing his own password also must confirm his present password.
The RSA encryption and blowfish strategies are being applied in the ON-site portal as well. Offsite portal is unchanged.
SSL is still highly recommended, but what happens is whenever a password needs to be transmitted, the client requests a one-time-use public-key from the server. Server stores the corresponding private key in a new table rsa_pairs. When the client sends the data, the server retrieves the private-key from the DB and uses it to decrypt the sensitive information from the client. The private-key is then deleted from the table after it’s used.
Assuming there are no major bugs, migration of the data in the tables themselves does not require any effort. The first time a user logs in the SHA1 hash is replaced with blowfish/salt automatically.
There is a new global flag ‘password_compatibility’ that can be toggled after all user’s password have been updated, that prevents any “stray use” of SHA1. (The compatibility/migration routines are always skipped and only authentication by blowfish will work.
The main point is to address potential “pass-the-hash” and rainbow table vulnerabilities.