31–40 of 79 posts
Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence. If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for a…
Yes, sure. You should not be using anything but Bcrypt et al for passwords (salt, salt, salt!) – but... Out of curiosity. What if these passwords were SHA-512 hashed (unsalted) rather than SHA1? Anyone know of comparable articles?
Earlier quoted context omitted.
> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…
> Django's user model uses a pretty straight forward and good approach[1] You forgot to post the link.
https://docs.djangoproject.com/en/1.9/topics/auth/passwords/...
Here's a blog post which covers the same topic in an easy-to-understand form, including why computationally-expensive password hashing is important:
85% cracked in a few days is seriously depressing. What does a box like the one mentioned in the article cost? Any estimate on the time to crack the remaining 15%?
I know of at least one person on LinkedIn using passwords of the form 2jzAwGyOzfxNoW0u3lTIIa (i.e., 22 digits & mixed-case letters); calculating 209.7 million hashes per second he should be able to crack his first one of that sort of password in about 182,686,540 years.
I cordially wish him the best.
Earlier quoted context omitted.
bcrypt uses unique salts per-password. The hash outputted by the bcrypt function is actually several delimited fields that have been joined into a single string. This means that if multiple users use a common password like 'pass123', the hashes stored in the database will still each be unique. Any attacker trying to reverse all of the password hashes will have to reverse every single one individually in a targeted ma…
What are the advantages of bcrypt compared to SHA based hashes with unique salts?
Salting protects against rainbow tables [1], but it doesn't change the fact that computing a SHA256 hash is fast.
Password hash functions like PBKDF2, bcrypt, scrypt, Argon2 are designed to be computationally expensive, to make a password-cracking endeavor take even longer.
Argon2, the winner of the Password Hashing Competition and the current state-of-the-art, for example, has two ready-made variants: Argon2d is more resistant to GPU cracking, while Argon2i is more resistant to time-memory tradeoff attacks [2].
Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence. If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for a…
> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…
It very much is, if you're outsourcing to someone who can do it with greater competence than the average team can. Keeping current on the crypto, designing with the ability to sunset algorithms in mind, continuous pen testing, investing in physical security/network security/HSMs/you name it definitely isn't cheap or easy. Unless you're in the business of doing _that_ you're almost certainly better off having someone do it for you.
That said, I'm with you on the social logins front. I have/had? hope for OpenID Connect as an alternative so it would be great if someone neutral like Mozilla jumped on the bandwagon.
I forgot root password on my old IRIX / SGI Octane2 and had to "crack" it a few months ago. Turned out it was using full eight characters and was on the tail-end of the alphabet. It took less than a day to guess it on an older two-gpu 680GTX machine with cudaHashcat. Also, how awesome of IRIX guys was to not allow more than 8 characters in a password?
http://stackoverflow.com/questions/2179649/are-passwords-on-...
Some of the answers on that page suggest it changed around 2000, and SGI Octane 2 was still being sold in 2004(?), but I don't know how rapidly systems changed.
Earlier quoted context omitted.
> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…
> Outsourcing them is not the answer It very much is, if you're outsourcing to someone who can do it with greater competence than the average team can. Keeping current on the crypto, designing with the ability to sunset algorithms in mind, continuous pen testing, investing in physical security/network security/HSMs/you name it definitely isn't cheap or easy. Unless you're in the business of doing _that_ you're almost…
In this case, what I would do is to use a framework that makes getting those things wrong hard. Django is a great example for that. They provide you with a generic user model that does password handling for you. They also add a few middlewares by default to protect you against CSRF, click jacking and many more. While django can be really slow, and hard to use when doing something "unsual", you can learn a lot from it. I don't know many frameworks that make security so much easier. In Go, you can do all those things as well but that requires that you are aware of those security measures to use them, which is not ideal for junior developers or "fast moving startups that don't have time to invest in security measure".
Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence. If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for a…
Unsalted hashes in 2012 was negligence already...
It bothers me that my most valuable login is probably my weakest.
Earlier quoted context omitted.
> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication. Should we all be using "Login with LinkedIn", then? Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still usin…
> Outsourcing them is not the answer It very much is, if you're outsourcing to someone who can do it with greater competence than the average team can. Keeping current on the crypto, designing with the ability to sunset algorithms in mind, continuous pen testing, investing in physical security/network security/HSMs/you name it definitely isn't cheap or easy. Unless you're in the business of doing _that_ you're almost…
I couldn't agree more with this comment.
Storing username and passwords is really hard. Using a secure hashing alg is trivial compared to other time consuming problems like handling brute force attacks or other kind of anomalies like a distributed attack trying to use a db of leaked email and passwords from other services.