4 ms·

The article inaccurately describes generating a password hash & using it as "storing a password".

by rehevkor5 11y ago

sarciszewski 11y ago
The title has been corrected as of ~half an hour ago.
- rehevkor5 11y ago
  I still see "How to Safely Store Your Users' Passwords in 2016".
  - sarciszewski 11y ago
    That's the correction. Given that the audience for this blog post is developers, I feel that the current title is precise enough. People who know about password hashing don't need this advice. People who are storing passwords need this advice.
balls187 11y ago
My point is simply if you can avoid storing user credentials, avoid storing their credentials. For many services, the most valuable data they contain happens to be the user credentials that the service uses to authenticate the identity of the user. If you assume that users share their credentials across multiple services, if your system is attacked, and you improperly stored their credentials, you've caused way more damage, than the data you were trying to secure. For example, take your run of the mill online todo app. If an attacker got access to the all the todos, vs an attacker got access to the all the todos and all the user passwords (even if securely stored). What is more valuable to an attacker?
- sarciszewski 11y ago
  > What is more valuable to an attacker? Generally: Being able to deploy malware through a site users trust so you can attack them directly, en masse. But the password hashes are a good runner-up.
- ngrilly 11y ago
  I agree that it's better to avoid storing user credentials, but what do you suggest instead to authenticate the user?
  - balls187 11y ago
    If you don't require privileged elevation, then I'm a fan of just using an email address and send "magic links" + persistent (but expiring) sessions. For mobile apps, I think using SMS and One-Time Passwords is sufficient as well. You can also use a delegated auth system put in place by OAuth v2, or something like Google Accounts, Twitter, etc. Those services do get pushback, as not every uses Gmail (or likes to give any run of the mill app access to Google account data).
    - ngrilly 11y ago
      > If you don't require privileged elevation What do you mean by privileged elevation (I'm talking in the context of a web app)? > just using an email address and send "magic links" + persistent (but expiring) sessions Do you mean something similar to what Medium does? https://medium.com/the-story/signing-in-to-medium-by-email-aacc21134fcd https://medium.com/the-story/signing-in-to-medium-by-email-a... I like it too. But what about delays in receiving emails (when I suggested this approach to some customers, they were worried about that)? > You can also use a delegated auth system Yes, outsourcing the authentication is another solution, but some (most?) users are not comfortable with giving so much power to Google/Twitter/GitHub/etc. (as you wrote in your comment).
      - balls187 11y ago
        > What do you mean by privileged elevation (I'm talking in the context of a web app)? For example, prior to changing account settings, reauthenticate the users, regardless if they have a valid session. > I like it too. But what about delays in receiving emails (when I suggested this approach to some customers, they were worried about that)? Combo of email & SMS. As Bruce Schneier has written, security is usually a trade off of user experience.

The article inaccurately describes generating a password hash & using it as "storing a password".

sarciszewski 11y ago

The title has been corrected as of ~half an hour ago.

rehevkor5 11y ago
I still see "How to Safely Store Your Users' Passwords in 2016".
- sarciszewski 11y ago
  That's the correction. Given that the audience for this blog post is developers, I feel that the current title is precise enough. People who know about password hashing don't need this advice. People who are storing passwords need this advice.

balls187 11y ago

My point is simply if you can avoid storing user credentials, avoid storing their credentials. For many services, the most valuable data they contain happens to be the user credentials that the service uses to authenticate the identity of the user. If you assume that users share their credentials across multiple services, if your system is attacked, and you improperly stored their credentials, you've caused way more damage, than the data you were trying to secure. For example, take your run of the mill online todo app. If an attacker got access to the all the todos, vs an attacker got access to the all the todos and all the user passwords (even if securely stored). What is more valuable to an attacker?

sarciszewski 11y ago
> What is more valuable to an attacker? Generally: Being able to deploy malware through a site users trust so you can attack them directly, en masse. But the password hashes are a good runner-up.
ngrilly 11y ago
I agree that it's better to avoid storing user credentials, but what do you suggest instead to authenticate the user?
- balls187 11y ago
  If you don't require privileged elevation, then I'm a fan of just using an email address and send "magic links" + persistent (but expiring) sessions. For mobile apps, I think using SMS and One-Time Passwords is sufficient as well. You can also use a delegated auth system put in place by OAuth v2, or something like Google Accounts, Twitter, etc. Those services do get pushback, as not every uses Gmail (or likes to give any run of the mill app access to Google account data).
  - ngrilly 11y ago
    > If you don't require privileged elevation What do you mean by privileged elevation (I'm talking in the context of a web app)? > just using an email address and send "magic links" + persistent (but expiring) sessions Do you mean something similar to what Medium does? https://medium.com/the-story/signing-in-to-medium-by-email-aacc21134fcd https://medium.com/the-story/signing-in-to-medium-by-email-a... I like it too. But what about delays in receiving emails (when I suggested this approach to some customers, they were worried about that)? > You can also use a delegated auth system Yes, outsourcing the authentication is another solution, but some (most?) users are not comfortable with giving so much power to Google/Twitter/GitHub/etc. (as you wrote in your comment).
    - balls187 11y ago
      > What do you mean by privileged elevation (I'm talking in the context of a web app)? For example, prior to changing account settings, reauthenticate the users, regardless if they have a valid session. > I like it too. But what about delays in receiving emails (when I suggested this approach to some customers, they were worried about that)? Combo of email & SMS. As Bruce Schneier has written, security is usually a trade off of user experience.