2

It seems that the current best practice for storing passwords on the web is to use bcrypt as opposed to sha256 or any other hashing algorithm. Bcrypt seems fantastic, with one flaw as I see it: if I have a database filled with passwords using a work factor of 10 and I want to increase that work factor to 12 because computational power has increased, then I have no way of doing this without knowing the users password, meaning waiting until they login again. This causes problems for uses who have abandoned their account.

It seems to me then that an alternate solution would be to use sha256 and do a number of passes equal to 2^(work factor). If I do this, then when I want to increase the work factor I can just do the difference in the number of passes for every stored password.

I've written a bit of code to do exactly that, and I'd like to get feedback from everyone on whether this is a good idea or not.

https://github.com/rbrcurtis/pcrypt

rbrc
  • 872
  • 1
  • 6
  • 13
  • take a looks http://stackoverflow.com/questions/10963209/web-app-passwords-bcrypt-and-sha256-and-scrypt/10963468#10963468 Also take a look at the comments I had but processing power grows exponentially, bcrypt can be configured as such, fundamnetally you are on the right track about the 2^work_factor but bcrypt already has this built in with large salt spaces and everyhting so why bother reinventing the wheel... – Samy Vilar Jun 12 '12 at 21:10
  • Because bcrypt doesn't allow you to take an existing hashed password and rehash it at a higher work factor without knowing the user's password. That's the entire point of this. – rbrc Jun 12 '12 at 21:57
  • sorry about that got caught up with another problem, yes your absolutely right that is an issue, but rehashing seems a bit dangerous , what if you fail to properly keep track of the number of times, what if while you where rehashing your entire dataset users are loggin in or something happen, theres so many what ifs that I feel is not worth the risk, this is why so many people just use bcrypt with a high enough work_factor, its really up to you, do you feel comfortable manipulating the hashes this way? – Samy Vilar Jun 12 '12 at 23:30
  • Of course I feel comfortable doing this. I've already written code that reliably ups the work factor given an existing hash. Check it out, it's easily tested. Currently logged in users have a session id that is independent of their password hash and so wouldn't be effected by an out-of-band process to up the WF on existing users. The issue is that a high enough work factor today is not a high enough work factor tomorrow (which could easily be 6 months from now), and a too high work factor today means slow logins and registrations. – rbrc Jun 12 '12 at 23:47
  • You can upgrade passwords to new hashing scheme when user logs in (and provide correct password). It's not ideal but working solution. – vbezhenar Jun 13 '12 at 13:53
  • Yeah that's the best I've come up with too, but as I said in the OP, this causes problems for users who have abandoned their account. – rbrc Jun 13 '12 at 17:50
  • Man thats a tough one, if they've abandon their account are we still liable? (I think we are :( ), can we simply disable their accounts when its time to update all the hashes and if they want to re-enable it can they just fill out a form of some kind to verify their identity. – Samy Vilar Jun 13 '12 at 20:00
  • Yeah I think we are too... the best I've got is to disable their account, delete their password and have them use password recovery next time they want to use the site. Hardly a good solution. I suppose this is the problem that all the sites with md5'd passwords are facing now. – rbrc Jun 14 '12 at 01:19

2 Answers2

1

Did a lot of digging and reading papers on these various encryption algorithms. What finally gave me a sort-of answer was this question on crypto.stackexchange.com. My algorithm is somewhat similar to shacrypt, which I hadn't heard of previously, but is still not as good as bcrypt. Reason being that bcrypt, in addition to the work factor, also requires more memory to process than the sha2 family. This means that it cannot as effectively be parallelized in GPUs (although to some extent it can be, and more easily in an FPGA) while sha2 can (and easily). As such, no matter how many passes of sha2 one does, it will still not be as effective as bcrypt.

As an aside, scrypt is significantly better still because it has both a work factor for CPU and a memory factor (and as such is essentially impossible to parallelize in a GPU or FPGA). The only issue is that the nodejs library for scrypt is essentially unusable at present so that might be something to put some effort into.

Community
  • 1
  • 1
rbrc
  • 872
  • 1
  • 6
  • 13
0

A potential solution for upping the number of bcrypt passes(or work factor. I don't actually use bcrypt but this is an algorithm-agnostic answer):

For each entry the table where your passwords are stored, also store the number of passes it was hashed with. When you up to more passes, save all new passwords with that number of passes, and set all passwords with less passes than that to expire in 7 days. When they make a new password, hash it with the right number of passes.

Alternatively, you can not reset the password, but the next time they try to login, rehash their password and store it in the table. This does mean that if people haven't logged in, in a long time, their passwords are more susceptible to breach in the event of a DB comprimise. That being said, it's more worth it for the attacker to attack the mass of people with more passes, than the few with less passes(nevermind, because of salts, this last sentence is wrong).

Cruncher
  • 7,641
  • 1
  • 31
  • 65
  • You have basically rephrased what the OP said, without answering the question (what to do about abandoned accounts). – deceze Mar 14 '14 at 19:38
  • @deceze The OP already answered the question as asked. I was providing a way to use bcrypt and get similar behaviour to what he wants – Cruncher Mar 17 '14 at 13:22