3 ms·
> as using them is barely above plain text in terms of security these days How so?
by TomGullen 12y ago
> as using them is barely above plain text in terms of security these days
How so?
- watwut 12y agoIf I recall right, those functions are too fast. It is too easy to iterate through all kinds of possible passwords and you are likely to find plenty of matches. At minimum, you need to add unique salt to each password. It forces the attacker to run dictionary on each account separately. It is also recommended to use different slower hash function or iterate MD5/SHA1 thousands times, so he will be much slower.
- jacobparker 12y agoTry to avoid directly invoking "SHA256" in your own security-related code. good: http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2 gooder: http://en.wikipedia.org/wiki/Scrypt http://en.wikipedia.org/wiki/Scrypt Maybe avoid using SHA256 with them because of Bitcoin ASICs. If your passwords get leaked in hashed form, even with these, you'll still want to tell your users and advise/force them to change their passwords. Forcing makes more sense if you have 2FA to something not likely to be accessible with their previous password (SMS maybe?)
- Daiz 12y agoCracking them is so fast these days that they don't offer much in terms of security. For example, take a look at this post: http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html http://www.troyhunt.com/2012/06/our-password-hashing-has-no-... Then note that it was posted two years ago. GPUs surely haven't gotten any slower since then.
- TomGullen 12y agoSame applies to all hash functions. It's how you implement it that counts.
- scottlinux 12y agoSee hashcat. :) It is easy to crack those types of hashes these days. Or even just search for the hash in google.
- TomGullen 12y agoSame applies to all types of hashes. Implementation counts more than which function you choose.