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).
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.
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.
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.
Support for that is very uneven. Most UK networks only support it if you have an iPhone or a Samsung phone, and sometimes only if you bought the phone from the network directly.
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.
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.
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.
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. :)
Does your app really need people to register an account? I’ve seen plenty of apps that make people sign up when there’s absolutely no reason to require it.
The caveat with a third party oauth solution is that you are now dependent and reliant on the third party to _let_ you use them to log in. Here are some fun experiences I’ve had with Facebook over the last couple of years:
- Our app was _deleted_ without any notice and any means of appealing (didn’t appear in the appeals page, and of course there’s no human support). We even filed a ticket and were told that they couldn’t help us because the app was “gone” in their system. Luckily we require an email address or we would have completely lost the ability to authenticate a subset of our users.
- A different internal app was banned from using “Facebook Login” because we were “providing a broken user experience” — the app was not even exposed for login in our system. We couldn’t appeal because the warning notice didn’t allow responding from our mailing list. Changing the primary contact didn’t work either, and we even disabled the login on the app just in case. Still revoked with no means of getting it back.
Google has been less awful to work with, but they make you jump through lots of hoops to get public login permissions. In summary, think very carefully about a third party Oauth solution.
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.
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.
This is misleading. Remember our context here is that we're getting a sign-in token for some web site, let's say it's the EXA Metal Pole Limited (Europe) site, example.com
The plain text is stored briefly on EXA's outbound mail server mail-blast.example.com, and then it's transmitted to my inbound MX mx1.tlrmx.org, stored very briefly there, and passed to the IMAP server imap.tlrmx.org.
So that's three servers, but, one of them is controlled by the same people as the site we're logging into. If they want a backdoor they can just make one, they don't need to steal their own sign-in tokens, that would be really stupid.
OK, so two servers left. But those are both operated by me, the recipient of the tokens. Why am I stealing my own tokens? To what end? "Oh no I broke into my own account and have impersonated myself" ?
Now, many people use say GMail instead of their own mail servers. But can we reasonably say these people's mail was "intercepted" by GMail, the outfit they've explicitly chosen to receive and store email on their behalf?
And even if we insist upon using the word "intercepted" this way ("The Buccaneers pass was intercepted by Mike Evans" [Evans is a Buccaneers Wide Receiver, the pass was presumably meant for Mike and so we would not ordinarily call this an interception, but if you insist...]) it's unclear what unexpected gain is achieved. GMail could just build their own backdoor and sign in as you to get the tokens instead of "intercepting" them if for some crazy reason that was what they wanted.
Email is federated, not point to point. It quite often hops between a couple of servers. Cloud hosted stuff typically gets routed through the cloud provider first (and whatever intelligence agencies are tapping that feed), which then pushes it to the top-tier smtp server nearest the destination for obscure hosts.
Still we’re in a perverse situation here. Running your own server is getting harder to do since everything operates on white lists, and I wouldn’t trust the big name providers for something like this.
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.
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.
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.
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?
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.
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).