On Monday, 27 January 2014 at 09:08:04 UTC, Uranuz wrote:
Thanks for responses. I considered to use scrypt for now, because as described is's harder to hack it with brute force using GPU, ASIC, FPGA than bcrypt. But it has some limitations too. I've tried to tweak it to use more memory and less computation time but failed. Another question for me is how would I support this type of password authentication. After some years computation powers will grow and I will need to modify my hased keys stored in DB to adequately resist this. So I need some protocol where some parameters could be tweaked I'll be able to "rehash" or make some additional iterations with existing password hashes with no need to disturb users that "we have some security updates and ask users to change their passwords". So this part of reply is interesting for with from described point of view.
Just a quick thought of the hash migration might be to store the algorithm version (lets say 0 for scrypt). Then when you do an opCmp on the hash password or how ever you're comparing. And it checks out it'll update and save it on login.
If it gets too out of date then maybe ask them to login to change their password.
