Hacker News Reader

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.

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.

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.

No WiFi calling??

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.

Or the ability to glean what you do on 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.

It's disturbingly annoying, I agree

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

Yeah that's at least 12 characters though. Quite annoying.

It is very easy to get long passwords, just double them

Or just append a long number like "password12345" (13 characters).

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.

yeah it's a dating app

Would social login (Google, Facebook, Twitter etc) be a partial solution here? Basically outsourcing the authentication.

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.

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.

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

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.

It’s stored in plain text on every server along the way. That’s where it is vulnerable.

> every server along the way.

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.

95% of inbound email traffic to Gmail is encrypted with TLS.

https://transparencyreport.google.com/safer-email/overview?h...

Password reset emails are already extremely common and a way of implementing the "second factor only" method in the OP.

No they cant for any entity that properly implements security. This is the entire point of u2f.

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.

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

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.

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

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.

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

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.

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

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?

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