10 ms·

In fact hashing the password is better than encrypting them! If you encrypt a password, it means that somewhere you have a key that you use to decrypt it to ch

In fact hashing the password is better than encrypting them! If you encrypt a password, it means that somewhere you have a key that you use to decrypt it to check if it's valid on the user login. It means that there is a way that you (or more importantly an attacker) can use to decrypt the passwords. Instead if you use a good hashing algorithm is practically impossible to find the password given the hash. Yes if the password is really simple you can get it, but come on, if the password is really simple what's the point of protecting it? By the way I think that we should phase out password anyway, I mean that I prefer to implement in the applications that I develop a password-less authentication: when you want to sign in a mail (or an SMS) is sent to you, you click on a link with a temporary token and you are authenticated. No password to remember, not having to implement forgot password, change password, recover your password, not having to store the password, not having the user have to choose a password, and I hate choosing password (in fact I ended up using a password manager that generates random passwords for me, but it's not the ideal solution, because then password have to be synced on all my devices, not all websites/apps have forms made correctly to support password manager, and the password manager extension (Bitwarden) goes in conflict with the integrated Firefox password manager so I end up having password saved in the password manager and other in Firefox and it's a mess).

YetAnotherNick 6y ago
You generally encrypt the hash of the password. Pepper can be thought as a form of encryption.
- tialaramex 6y ago
  Who is this "you" that will "generally encrypt the hash" ? And no, pepper is not encryption. Encryption is reversible, you can decrypt the ciphertext with the key. Hashing isn't encryption / Confidentiality isn't integrity / RAID isn't backup / Income isn't profit Not knowing the difference doesn't mean there isn't a difference.
  - couchand 6y ago
    What the GP describes is absolutely correct. It may not be all that common but it is a known pattern. That you haven't heard of it doesn't mean it doesn't exist. > An alternative approach is to hash the passwords as usual and then encrypt the hashes with a symmetrical encryption key before storing them in the database, with the key acting as the pepper. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#peppering https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
  - afiori 6y ago
    I always wondered something: does using a secret key as salt and keeping the last (few) block(s) of a block cipher as output produce a reasonable hashing algorithm? maybe with three salts, one for the key, one as a prefix to the password and one as a suffix?
leephillips 6y ago
Every time I want to use the service I have to go through this? I don’t think I would like that. Much easier to just paste in my password. Plus these emails are like sending passwords in plain text. If they are intercepted someone can impersonate me.
- runbyfruity 6y ago
  1. If someone intercepts your password you're screwed anyway. How many of your emails are intercepted regularly? 2. If someone has access to your email, you're screwed anyway because they can lock you out and reset every password. Your email password, effectively, becomes the password for that website. I.e. security-wise, I think they're equivalent.
  - garmaine 6y ago
    > If someone intercepts your password you're screwed anyway. How many of your emails are intercepted regularly? Every single one of them. Email is a plain text protocol.
    - tialaramex 6y ago
      In practice, today, this is not very true. There are three components worth looking at. Each of them is popularly secured with TLS. Firstly, submission, sending an email you just wrote from your client to a server. This is usually done over a specifically TLS-secured "SMTP submission port" 587 although it can also be done with STARTTLS. Second, relay, getting email from your server to somebody else's server. A large proportion of today's servers default to STARTTLS over SMTP for MX. So this means when they connect to a peer server to exchange mail they'll enquire about using TLS and do so if possible. A passive adversary can't stop this happening. Finally, delivery. Almost all modern IMAP clients default to using TLS with IMAP, so this step will be encrypted. Even in clients that don't require TLS a passive adversary can't stop them upgrading by default if possible.
      - garmaine 6y ago
matthewmacleod 6y ago
By the way I think that we should phase out password anyway, I mean that I prefer to implement in the applications that I develop a password-less authentication: when you want to sign in a mail (or an SMS) is sent to you, you click on a link with a temporary token and you are authenticated. Please don’t do this. For one thing, SMS is fundamentally broken as a secure delivery method. But more than that… it’s just so, so deeply annoying.
- oneplane 6y ago
  But how will you log in to your SMS inbox? With an email? But what if that requires an SMS inbox as well. Once we're in the realm of 'you only have to remember this one password' you might as well use a password manager that unlocks with that password and does the rest for you (be it with autofill or webauthn and the likes). Yubikeys are fine too, even as a single factor in some cases.
- weavie 6y ago
  I worked in an office that had no mobile signal. So for me a 2fa SMS involved walking out of the office and down the road for a few minutes until the SMS came through and then running back to my desk in the hope that I get there in time to enter the code before it times out.
  - ed25519FUUU 6y ago
    No WiFi calling??
    - throwit4tonight 6y ago
      You may not be able to get your phone on the corporate network without installing their MDM, and you may not want to give your employer the ability to wipe your phone.
      - xeromal 6y ago
        Or the ability to glean what you do on your phone!
hyperpape 6y ago
This author has discussed these sorts of proposals: https://www.troyhunt.com/heres-why-insert-thing-here-is-not-a-password-killer/ https://www.troyhunt.com/heres-why-insert-thing-here-is-not-..., https://news.ycombinator.com/item?id=18381675 https://news.ycombinator.com/item?id=18381675
deleted 6y ago
[deleted]
tdrp 6y ago
Regarding simple passwords, we added a check against the top 100K seclist passwords when first registering, to keep users from using easily guessable passwords (we also had an experiment where we checked if that password was one of the frequently compromised ones). Literally this converted into: 1- Users abandoning on sign-ups "oh how am I supposed to find a password I will remember" 2- Users bashing us on the app store reviews: "make it super hard to sign-up" even though we only ask for username and password, not even an e-mail 3- Users logging in, liking the app, then a few months later when they got logged out for whatever reason, completely forgetting what their password was and not having a fallback e-mail. We ended up pulling it back. We just have a small note now that says "easily guessable password" but allow them to proceed with registration.
- identigral 6y ago
  This is a good summary of a novel we've been writing based on our experience of tackling similar issues with clients. Working title: Misaligned Incentives. The best real-world solutions we've seen address this issue head-on by providing tangible incentives to the user in such a way that motivates them to act and doesn't harm the overall business objective. Example: product/service discount in a form of a coupon if you register a 2nd auth factor. Finding that balance is challenging, it is very context-sensitive. Selling it to the service owners is even more fun.
- cpeterso 6y ago
  You could make the minimum password length longer than the longest SecList password. Then users can’t reuse any of those insecure passwords! Plus it’s also a fast O(1) check. :)
  - IshKebab 6y ago
    Yeah that's at least 12 characters though. Quite annoying.
    - afiori 6y ago
      It is very easy to get long passwords, just double them
angst_ridden 6y ago
The email approach is what StreamYard does. If someone gets a forwarded email within a short timeframe, they have access. Then they cookie you with an access token. This is both good and bad. When I needed a whole team to have access to my account, I just built a mailing list, and used that address for signing up. Yes, it was annoying that we'd all get email every time someone logged in on a new device, but it was also pretty straight forward to use.
rkeene2 6y ago
The US Government got rid of passwords starting in 2004. It's a good idea.
bagacrap 6y ago
it's called two factor for a reason! You're suggesting a return to one factor, but ditching the PW and using the backup means of auth. What's supposed to happen is that you combine something you know (pw) with something you have (phone) as it's generally difficult for an attacker to get both.
LaFolle 6y ago
What about encrypting the hash of password+salt and keeping the key really safe? Would that be a better strategy?
- hatsunearu 6y ago
  Cryptographically, encrypting doesn't actually add any more security so... no point imo edit: but infosec isn't completely equal to cryptography, so some deterrence like that will prevent some attacks. But it's like adding a real beefy padlock on your door (the hashing), and then putting a piece of tape to keep your door shut. Or putting a piece of tape over the keyhole of your padlock.

YetAnotherNick 6y ago

You generally encrypt the hash of the password. Pepper can be thought as a form of encryption.

tialaramex 6y ago
Who is this "you" that will "generally encrypt the hash" ? And no, pepper is not encryption. Encryption is reversible, you can decrypt the ciphertext with the key. Hashing isn't encryption / Confidentiality isn't integrity / RAID isn't backup / Income isn't profit Not knowing the difference doesn't mean there isn't a difference.
- couchand 6y ago
  What the GP describes is absolutely correct. It may not be all that common but it is a known pattern. That you haven't heard of it doesn't mean it doesn't exist. > An alternative approach is to hash the passwords as usual and then encrypt the hashes with a symmetrical encryption key before storing them in the database, with the key acting as the pepper. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#peppering https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
- afiori 6y ago
  I always wondered something: does using a secret key as salt and keeping the last (few) block(s) of a block cipher as output produce a reasonable hashing algorithm? maybe with three salts, one for the key, one as a prefix to the password and one as a suffix?

leephillips 6y ago

Every time I want to use the service I have to go through this? I don’t think I would like that. Much easier to just paste in my password. Plus these emails are like sending passwords in plain text. If they are intercepted someone can impersonate me.

runbyfruity 6y ago
1. If someone intercepts your password you're screwed anyway. How many of your emails are intercepted regularly? 2. If someone has access to your email, you're screwed anyway because they can lock you out and reset every password. Your email password, effectively, becomes the password for that website. I.e. security-wise, I think they're equivalent.
- garmaine 6y ago
  > If someone intercepts your password you're screwed anyway. How many of your emails are intercepted regularly? Every single one of them. Email is a plain text protocol.
  - tialaramex 6y ago
    In practice, today, this is not very true. There are three components worth looking at. Each of them is popularly secured with TLS. Firstly, submission, sending an email you just wrote from your client to a server. This is usually done over a specifically TLS-secured "SMTP submission port" 587 although it can also be done with STARTTLS. Second, relay, getting email from your server to somebody else's server. A large proportion of today's servers default to STARTTLS over SMTP for MX. So this means when they connect to a peer server to exchange mail they'll enquire about using TLS and do so if possible. A passive adversary can't stop this happening. Finally, delivery. Almost all modern IMAP clients default to using TLS with IMAP, so this step will be encrypted. Even in clients that don't require TLS a passive adversary can't stop them upgrading by default if possible.
    - garmaine 6y ago

matthewmacleod 6y ago

By the way I think that we should phase out password anyway, I mean that I prefer to implement in the applications that I develop a password-less authentication: when you want to sign in a mail (or an SMS) is sent to you, you click on a link with a temporary token and you are authenticated. Please don’t do this. For one thing, SMS is fundamentally broken as a secure delivery method. But more than that… it’s just so, so deeply annoying.

oneplane 6y ago
But how will you log in to your SMS inbox? With an email? But what if that requires an SMS inbox as well. Once we're in the realm of 'you only have to remember this one password' you might as well use a password manager that unlocks with that password and does the rest for you (be it with autofill or webauthn and the likes). Yubikeys are fine too, even as a single factor in some cases.
weavie 6y ago
I worked in an office that had no mobile signal. So for me a 2fa SMS involved walking out of the office and down the road for a few minutes until the SMS came through and then running back to my desk in the hope that I get there in time to enter the code before it times out.
- ed25519FUUU 6y ago
  No WiFi calling??
  - throwit4tonight 6y ago
    You may not be able to get your phone on the corporate network without installing their MDM, and you may not want to give your employer the ability to wipe your phone.
    - xeromal 6y ago
      Or the ability to glean what you do on your phone!

hyperpape 6y ago

This author has discussed these sorts of proposals: https://www.troyhunt.com/heres-why-insert-thing-here-is-not-a-password-killer/ https://www.troyhunt.com/heres-why-insert-thing-here-is-not-..., https://news.ycombinator.com/item?id=18381675 https://news.ycombinator.com/item?id=18381675

deleted 6y ago

[deleted]

tdrp 6y ago

Regarding simple passwords, we added a check against the top 100K seclist passwords when first registering, to keep users from using easily guessable passwords (we also had an experiment where we checked if that password was one of the frequently compromised ones). Literally this converted into: 1- Users abandoning on sign-ups "oh how am I supposed to find a password I will remember" 2- Users bashing us on the app store reviews: "make it super hard to sign-up" even though we only ask for username and password, not even an e-mail 3- Users logging in, liking the app, then a few months later when they got logged out for whatever reason, completely forgetting what their password was and not having a fallback e-mail. We ended up pulling it back. We just have a small note now that says "easily guessable password" but allow them to proceed with registration.

identigral 6y ago
This is a good summary of a novel we've been writing based on our experience of tackling similar issues with clients. Working title: Misaligned Incentives. The best real-world solutions we've seen address this issue head-on by providing tangible incentives to the user in such a way that motivates them to act and doesn't harm the overall business objective. Example: product/service discount in a form of a coupon if you register a 2nd auth factor. Finding that balance is challenging, it is very context-sensitive. Selling it to the service owners is even more fun.
cpeterso 6y ago
You could make the minimum password length longer than the longest SecList password. Then users can’t reuse any of those insecure passwords! Plus it’s also a fast O(1) check. :)
- IshKebab 6y ago
  Yeah that's at least 12 characters though. Quite annoying.
  - afiori 6y ago
    It is very easy to get long passwords, just double them

angst_ridden 6y ago

The email approach is what StreamYard does. If someone gets a forwarded email within a short timeframe, they have access. Then they cookie you with an access token. This is both good and bad. When I needed a whole team to have access to my account, I just built a mailing list, and used that address for signing up. Yes, it was annoying that we'd all get email every time someone logged in on a new device, but it was also pretty straight forward to use.

rkeene2 6y ago

The US Government got rid of passwords starting in 2004. It's a good idea.

bagacrap 6y ago

it's called two factor for a reason! You're suggesting a return to one factor, but ditching the PW and using the backup means of auth. What's supposed to happen is that you combine something you know (pw) with something you have (phone) as it's generally difficult for an attacker to get both.

LaFolle 6y ago

What about encrypting the hash of password+salt and keeping the key really safe? Would that be a better strategy?

hatsunearu 6y ago
Cryptographically, encrypting doesn't actually add any more security so... no point imo edit: but infosec isn't completely equal to cryptography, so some deterrence like that will prevent some attacks. But it's like adding a real beefy padlock on your door (the hashing), and then putting a piece of tape to keep your door shut. Or putting a piece of tape over the keyhole of your padlock.