5 ms·

> 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

> 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 using the old algorithm for old logins? When should you erase all passwords from inactive who haven't logged in and thus still use the old algorithm. (If you are interested in this problem, Django's user model uses a pretty straight forward and good approach[1]). Outsourcing them is not the answer. It is a good idea to add that for the user's convenience but I hate it when websites only offer the option to login with "your" favorite social media. But even then, by outsourcing the passwords, you are risking your users' privacy by giving them to Google/Facebook/etc. This even discriminates users' privacy when they are not using Facebook for authenticating because facebook can see that user X visited your website (and sometimes even all URLs from that website you have visited). This is because those "Login with" and "Like" buttons always hit Facebook's and Google's servers with every webpage. [1]: https://docs.djangoproject.com/en/1.9/topics/auth/passwords/ https://docs.djangoproject.com/en/1.9/topics/auth/passwords/ Edit: Forgot the link, thanks!

kevin_thibedeau 10y ago
> How long would it take to implement a change which updates the hashing algorithm for new logins while still using the old algorithm for old logins? As long as you remember to store the cost parameter along with each hash it's just a matter of increasing the default cost and reusing the old ones.
- Matt3o12_ 10y ago
  I was talking about the algorithm. Let's say bcrypt is considered insecure in 5 years (even with 100 iterations) and you are supposed to use another hash algorithm. Is your code and database able to handle that? If so, great but I don't think many people implement this and depending on your code, this can get difficult.
hk__2 10y ago
> Django's user model uses a pretty straight forward and good approach[1] You forgot to post the link.
- niftich 10y ago
  Not OP, but here's the official Django doc on the topic, including a section further down about upgrading the hash without needing a login: https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#password-upgrading 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: http://tech.marksblogg.com/passwords-in-django.html http://tech.marksblogg.com/passwords-in-django.html
lpage 10y ago
> 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 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.
- Matt3o12_ 10y ago
  You are right, if the company you outsource your task to is actually better then you. In LinkedIn's case, outsourcing was the wrong decision because they used pretty bad "tools". You should also only outsource if you trust the other company to be "competent" and protect your interests. For instance, I would have trusted Mozilla with their OpenID alternative but not Google, Facebook, and LinkedIn (though I'm pretty sure Google knows how to keep the login data safe, I'm more worried about privacy in that case). 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".
- jfroma 10y ago
  Disclaimer: I work for Auth0. 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.
- 10y ago
voycey 10y ago
The point of bcrypt though is that it is (more) future proof in that the hash generation is slow as balls and can be made exponentially slower by increasing the difficulty. Other than some kind of algorithm weakness this slowness will translate through to the brute force attack thus taking longer for an attacker. BCrypt also has something that means it is harder for a GPU to crack it (mutable RAM memory tables or something). As for migrating passwords - you can use a fallback password hasher that checks against a previous hash should the main one fail - then once the login is successful re-hash with the newest algorithm!
- Matt3o12_ 10y ago
  You can't really know how future proof it is, though. As far as I know, nobody has proven it to be unbreakable. Right know we can't break it, we can only brutal force it but maybe tomorrow a mathematician finds some properties to calculate all possible inputs of a certain length for the hash within a reasonable time. Or maybe they find another way that doesn't include brutal force (statistics, ...). What I'm saying is that passwords are hard in general (to store, to enforce policies properly, ...) and just because bcrypt is "unbreakable" right now, doesn't mean it has to be in 5 years. Your last paragraph describes nicely what needs to be done, but is your code ready for that? Maybe your database password/salt column only allows X characters, now you need to rebuild the database. Maybe something else expects the passwords to have that specific format (another micro service, some script, ...). Re-hashing a password can be hard if this possibility was not considered from day one.
  - deleted 10y ago
    [deleted]

kevin_thibedeau 10y ago

> How long would it take to implement a change which updates the hashing algorithm for new logins while still using the old algorithm for old logins? As long as you remember to store the cost parameter along with each hash it's just a matter of increasing the default cost and reusing the old ones.

Matt3o12_ 10y ago
I was talking about the algorithm. Let's say bcrypt is considered insecure in 5 years (even with 100 iterations) and you are supposed to use another hash algorithm. Is your code and database able to handle that? If so, great but I don't think many people implement this and depending on your code, this can get difficult.

hk__2 10y ago

> Django's user model uses a pretty straight forward and good approach[1] You forgot to post the link.

niftich 10y ago
Not OP, but here's the official Django doc on the topic, including a section further down about upgrading the hash without needing a login: https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#password-upgrading 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: http://tech.marksblogg.com/passwords-in-django.html http://tech.marksblogg.com/passwords-in-django.html

lpage 10y ago

> 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 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.

Matt3o12_ 10y ago
You are right, if the company you outsource your task to is actually better then you. In LinkedIn's case, outsourcing was the wrong decision because they used pretty bad "tools". You should also only outsource if you trust the other company to be "competent" and protect your interests. For instance, I would have trusted Mozilla with their OpenID alternative but not Google, Facebook, and LinkedIn (though I'm pretty sure Google knows how to keep the login data safe, I'm more worried about privacy in that case). 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".
jfroma 10y ago
Disclaimer: I work for Auth0. 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.
10y ago

voycey 10y ago

The point of bcrypt though is that it is (more) future proof in that the hash generation is slow as balls and can be made exponentially slower by increasing the difficulty. Other than some kind of algorithm weakness this slowness will translate through to the brute force attack thus taking longer for an attacker. BCrypt also has something that means it is harder for a GPU to crack it (mutable RAM memory tables or something). As for migrating passwords - you can use a fallback password hasher that checks against a previous hash should the main one fail - then once the login is successful re-hash with the newest algorithm!

Matt3o12_ 10y ago
You can't really know how future proof it is, though. As far as I know, nobody has proven it to be unbreakable. Right know we can't break it, we can only brutal force it but maybe tomorrow a mathematician finds some properties to calculate all possible inputs of a certain length for the hash within a reasonable time. Or maybe they find another way that doesn't include brutal force (statistics, ...). What I'm saying is that passwords are hard in general (to store, to enforce policies properly, ...) and just because bcrypt is "unbreakable" right now, doesn't mean it has to be in 5 years. Your last paragraph describes nicely what needs to be done, but is your code ready for that? Maybe your database password/salt column only allows X characters, now you need to rebuild the database. Maybe something else expects the passwords to have that specific format (another micro service, some script, ...). Re-hashing a password can be hard if this possibility was not considered from day one.
- deleted 10y ago
  [deleted]