SHA-3 is KECCAK

Rikki Cattermole alphaglosined at gmail.com
Mon Jan 27 01:56:53 PST 2014


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.


More information about the Digitalmars-d mailing list