Changing design and rails 3 to use bcrypt instead of sha

Question

I have a rails 3 application that uses an authentication program. I would like to switch to using bcrypt instead of sha in the application, but I can not find any resources that explain the process of moving from one to another. I assume that you will need to have some kind of reserve in order to cope with the fact that passwords are currently salty in a certain way with the help of a step ...

Has anyone done this before ?! Any tips, tutorials, walkways, etc.?

Answer 1

I do not think there is a solution that you would like. I know only two options -

reset all user passwords and send them an e-mail, informing them that this was done (and, preferably, why they don’t worry so much)

when each user logs in, check the old hash system that you had, if it checks, create a new bcrypt hash in a new column, then delete the old, less secure hash and start the slow migration this way.

The mathematical strength needed to create a rainbow table to move around is unlikely.

Answer 2

Here is the best algorithm for ya that will allow you to switch all at once. You will need to figure out how to implement this in development, but here is the diagram. This is not mine, found on the Internet at the specified URL.

---

http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-password.html

• Suppose you have a database containing password hashes for n users on your site, and for each user you have a salt si and a hash hi (where hi was calculated using some algorithm such as SHA1 or MD5). (Note that the rest of the instructions work; if there is no salt, just ignore it).

• Suppose you decide to use scrypt. For each user, you first create a new random salt value s'i, and then calculate a new hash h'i using the scrypt formula (s'i, hi) and store the new salt and hash in the database. You throw away the old weak hash and forget that it ever existed. So you are left with two salt values ​​and a new hash. (I ignored the other scrypt options that leave the reader to determine).

• When the user logs in and presents the password p, you use your old weak hashing algorithm (suppose it is md5 (salt, password)) to calculate the hash for comparison as follows: scrypt (s'i, md5 (si, p) ) and compare this to the h'i stored in the database.

• If, like last.fm, you also allow third-party users to allow users by presenting the old hash value instead of the password, then you can use this scheme. When the third party presents the hash h for user i, you compute scrypt (s'i, h) and do the comparison.

• If step 4 is not needed, you can move on when the user logs in. After successfully logging in with the password p, you can completely eliminate any traces of the old weak hash by selecting the new random salt value s''i and calculating scrypt (s''i, p) and storing it in the database.

This can make your password database more secure if it is stolen without any effort by your users.

Answer 3

User Model:

devise: encryptable

developer migration file:

t.encryptable

Are these settings available?