[krupan]

When will we stop using passwords?! They are an elementary school kid “secret club” game taken way, way too far. They are totally broken. Nobody can come up with and remember good passwords. Nobody can store passwords securely. 100% busted.

Instead of continuing to debate what makes a good password, we need to put our energy into better techniques altogether! No more shared secrets! Let’s talk about one-time codes, asymmetric key cryptography, hardware tokens, anything but passwords!!

[mojuba]

In one of my current web-based projects I decided to experiment with magic links sent via email. They are pretty convenient (and secure enough) but turns out there's a problem with mobile email clients: they tend to open links in isolated embedded browsers and then forget the cookies. For most non-technical people this is a show stopper unfortunately.

I then went with one-time 6-digit sign in codes that are emailed to the user. These are secure enough if done right, but now I'm wondering if they will feel secure to the users.

P.S. I might change it to a one-time alphanumeric code, which should feel more secure.

[GoblinSlayer]

You know that the opened token is linked to the initial client session. You can unblock that session and the user can proceed in the non-isolated browser. You have this workflow with codes anyway: the user must open an email then go back to the browser and type in the code. With the link you will save on the typing.

[mojuba]

Interesting! (I searched, even asked on SO, couldn't find any solution for this). So to elaborate: I first store a nonce in cookies as a login session token. Once the code is validated somehow, I unblock it on the backend, and on a first chance also set my main JWT cookie if not yet set. Excellent, that solves it!

P.S. Unless there are some security implications - need to think about it a bit more. Thanks!

[kevincox]

I find this way less convienent because my password manager automatically fills in my username and password. So I can log in with 1 click. With "magic links" I need to enter my email (which may be autocompleted, but it is much less reliable) and then wait for the email to show up. (Assuming I have my email available.) Also email is never going to be reliably "instant" spam techniques include bouncing an email and waiting for a retry which is going to frustrate users and slow down login.

Additionally my security is now tried to the email I use which may be undesirable.

So I see why this exists, but please consider also supporting username+password at least until something else browser-integrated comes along.

[mojuba]

I know but it comes at a price of some users who don't use a password manager setting silly weak passwords.

In one of my mobile apps that manages KeyChain user/passwords correctly, I still see a lot of password reset requests. I can't even think of a reason why people would ignore autofill so often. The result is, although I haven't checked, but wouldn't be surprized if there were still a lot of "password123"'s in the DB.

So neither are passwords a good option, it seems.

[nybble41]

Don't let the user set the password, just assign them something random. If you let users pick their own passwords some of them are guaranteed to pick insecure ones (i.e. anything which isn't random and unique to that site).

Though frankly we should be able to do far better than one-off shared secrets for each account. WebAuthn, for example, with the browser as the authenticator, protected by either a client-side master password or biometrics. That would be at least as good as a password stored in a password manager, with the advantage that the user doesn't need to store (and sync) unique passwords for every site. To log in from a new device just enroll a second authenticator.

[krupan]

My experience with password managers is that it works that well on about 10% of websites/apps, and I have to resort to copy and paste from the password manager everywhere else. It's not that great

[mojuba]

10% is pretty low though. In my case Safari does it right in maybe 80% of cases. However the ones (websites and apps) that do it wrong can be very annoying.

[kevincox]

That seems incredibly low. Using Firefox's built-in password manager I definitely get >90% of sites. The only site that I use frequently where it doesn't work is my bank because the "card number" isn't recognized as the username.

But even copy-paste isn't too difficult. Roughly as much clicking as the magic-link solution in my experience.

[BeFlatXIII]

Having to check my e-mail for each login is a major annoyance. Perhaps something like SQRL[0] may help.

[0]: https://sqrl.grc.com/pages/what_is_sqrl/

[jsmith99]

How is this better than oauth (assuming you use a provider who doesn't have or doesnt share your real name).

[krupan]

More annoying than passwords?

[perryizgr8]

Of course. I can type a password from memory, or it can be auto-filled by the browser/password-mgr. No interruptions before signing in. Having to open email inbox means switching tabs/context.

[krupan]

You never forget a password and/or your password manager generates passwords and auto fills them with no hiccup for every website and app out there? Also changing passwords when a site policy requires it or when (not if) a breach happens? Because that is NOT my experience.

[perryizgr8]

Yes, occasionally there is a hiccup with the password system. But email link or code is disruptive and irritating 100% of the time.

[BeFlatXIII]

My password manager fills them in for me. E-mail means switching tabs and remembering which account I used to sign up for the service to know where to check.

[voiper1]

Sometimes the magic links or codes expires in X minutes. That helps them feel secure.

But like password resets, you're hosed if your email is hacked (unless you have 2FA).

[mojuba]

Not only expiration, you also limit the number of attempts, the IP address, you verify an additional nonce token generated for the specific request, etc.

The security of your email is typically taken care of by a more sophisticated system like GMail, that will do captcha, they remember your geographic region, your habits, etc.

Given the above, I'd say alphanumeric one-time codes are better in terms of entropy and feel. They look like passwords but you don't need to remember them.

[krupan]

So, no worse than passwords at all

[saltyfamiliar]

I don't use a password manager and my email account is by far one of my most secure accounts so I actually love signing in to things like this. It beats having to remember another battery-horse-stapler type password. For more paranoid users you could add a 2FA option.

[perryizgr8]

> one-time 6-digit sign in codes that are emailed to the user

> I'm wondering if they will feel secure to the users

I don't know about secure, but most users will feel extremely irritated for sure.

[yosamino]

> Nobody can store passwords securely. 100% busted. [...] Let’s talk about

> one-time codes

One-time codes rely on a password: either it is stored in your 2FA App, or they rely on your email password, or they rely you storing a password somewhere else. OTP rely on stored secrets.

You can make these secrets be much larger than the humble password and call them "private keys" :

> asymmetric key cryptography, hardware tokens

If these are not protected by a passphrase they can be stolen. Which seems like a variation of "nobody can store passwords securely". To mitigate the effects of them being stolen, you need to protect them with a password.

I sympathize with your desire, but it's not that easy, although I do think that we can reduce password usage.

But fundamentally a password is a trust anchor in your brain. I have yet to find a way around this limitation.

[smaudet]

I don't actually think passwords are broken at all - I mostly used to see this from people pushing biometrics or hardware tokens (people selling stuff).

How we use them, is very much broken. What is the point of a password that a bit of social engineering can bypass? Why are passwords required to get info on my ice cream rewards? Shouldn't I just get a coupon instead?

You should only use passwords that mean something and they should not be resetable, otherwise you have something closer to a one time token with a replay attack. Forget the password? Tough luck. Either it should not have needed one, or it should have some tangible effect which causes the user to highly value forgetting or getting it stolen.

We have engineered a state where we can't remember passwords because we are actively encouraged to ignore them, passwords are fine, how and when we use them is not.

[krupan]

“ fundamentally a password is a trust anchor in your brain.”

In other words, something you have (until you forget it). But also something you have to give to someone else after which all security bets are off.

A private key is also something you have (until you lose it). It is not something you ever have to give to anyone else. If you protect it with a password you don’t have to give that password to anyone else.

Big difference!

[krupan]

I feel like this whole argument is saying, "these other solutions have problems that somewhat resemble problems that passwords have, so just keep using passwords." Sorry I'm not convinced.

[taeric]

I'm curious how you think these other items work. They ultimately boil down to a shared secret that is beyond what you can remember. Which... isn't the best thing, necessarily.

Consider, if I leave my hardware token at home when I go on vacation, I'm basically locked out of all of my accounts. This is fine, as I typically plan for this to be the case. But it is an attack vector. I can't even audit my protected assets while away.

[Zamicol]

The point of public key cryptography is that there isn't a shared secret.

[GoblinSlayer]

A shared secret is not an attack vector though, a reused secret is. If you reuse an asymmetric key, it will identify you across the world. But if you don't reuse an asymmetric key, then the point of asymmetric cryptography is moot and is no better than a password manager.

[nybble41]

Using something like the Hierarchical Deterministic approach used for modern cryptocurrency wallets ("HD wallets") you can reuse a single master asymmetric key for any number of logins without linking those logins together.

In this scheme there is a single master private key which you protect in whatever way seems best and never share with anyone. From this master private key you can derive any number of subordinate private keys, each with its own public key. You share one of those public keys with each service, along with the derivation path, and authenticate using the corresponding private key. Only the unchanging master private key needs to be stored, so unlike a password manager there is no need to make new backups or sync a password database across multiple devices when you set up a new account. Best of all, without either the master private key or the corresponding master public key there is no (known) way to show that any two subordinate keys were derived from the same master key—they appear unrelated.

[krupan]

Identifying yourself is the whole point of logging in to a website. Yes, if you want to maintain a distinct digital identity for each website you’ll need to use a different key pair for each website, which by the way is actually feasible.

With our current email-address-and-password scheme that is so difficult to do it might as well be impossible. You’d need a distinct email account for each distinct digital identity that you want to maintain.

[GoblinSlayer]

If a web site wants your email address or phone number, it will require them, asymmetric cryptography won't help you. On the other hand, this very site uses password authentication, but doesn't require an email address.

[yosamino]

While technically correct, a private key will usually need to be encrypted to provide adequate security.

From the user point of view, they will still need to remember the password to unlock this private key.

[taeric]

Further to this point, the shared item is moved to a public key and the infrastructure to facilitate communication. Such that it is not a panacea. Getting away from trust in the system is...

Likely you will envision a system to register your key. And then you have to have a bootstrap to authenticate to this system. Probably a password.

[krupan]

Right, if it’s not a panacea then we should definitely not pursue it.

[taeric]

Not my point. Just not clear that the alternatives actually are better. Again, I use hardware tokens. Not seeing my family join me on that anytime soon.

List of problems with every approach always falls back to, "what happens if you lose it?"

And the resolution to that is always outside of the technical chain.

[krupan]

But from a security point of view this is a massive improvement! That password is never shared with anyone else. Someone has to first get ahold of your private key before they can start brute forcing that password in order to steal credentials. This is not a trivial thing! Plus users only need that one password, not a unique one for every website/app.

[jjav]

More generically than "shared secret" which is one implementation, the idea is shared trust.

We both (client and server) trust some common background info. It can't be hand-waved away because that trust must exist or be established.

Shared secrets (passwords) are close to an optimal solution when considering all possible criteria. Various forms of PAKEs can be better sometimes, but not very popular. Other solutions address different threat models, often with more significant tradeoffs than a shared secret.

[krupan]

How is any of that worse than passwords? I only see improvements. Still not perfect, but big improvements.

[taeric]

My question is how is it any better? A weak link is the trust chain, in both.

For problems, easy ones to consider is that of access. Easy to forget to take a key with you. Or lose it in a fire/disaster.

You can also be compelled to turn over a hardware token. Or a digital file.

[Aerroon]

Hopefully never. Or at least not in the near future. Almost every other method is going to have privacy implications because they will rely on something you have or something you are. You can't compel passwords in a similar way that you can compel people to give physical tokens or fingerprints or retina scans.

[krupan]

Fingerprints and retinal scans are not something I proposed. Your point is valid for those. Your point is not valid for hardware tokens vs. passwords. Especially when you consider that passwords used for authentication have to be written down somewhere and shared with a third party for them to work at all.

[throwawayffffas]

I agree and go even further that "something you have" is equivalent to a password. Even though "something you have" tends to be a public-secret key pair.

[dredmorbius]

PKI and physical tokens, preferably not involving plugging into any ports (NFC devices) have been my suggestion for most of a decade now.

Passwords were adopted when comuting was something that occurred at a specific facility and the goal was to keep the people, largely the users one already knew of, out of one-another's accounts and data.

The persistence of passwords in a world of global access and billions of devices is ... ludicrous.

And the failure of both enterprises and governments to identify better standards and practices is criminal.

[MattPalmer1086]

Theres some nice research on a framework to assess different authentication schemes, e.g. security, usability, etc.

Turns out passwords aren't great at most things but the alternatives often have big downsides.

https://www.microsoft.com/en-us/research/wp-content/uploads/...

[rkeene2]

The US Government thought they were bad, and got rid of them. In 2004 (Thanks George W. Bush!)