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!!
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.
But like password resets, you're hosed if your email is hacked (unless you have 2FA).
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.
P.S. Unless there are some security implications - need to think about it a bit more. Thanks!
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.
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.
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.
But even copy-paste isn't too difficult. Roughly as much clicking as the magic-link solution in my experience.
> 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.
> 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.
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.
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!
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.
From the user point of view, they will still need to remember the password to unlock this private key.
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.
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.
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.
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.
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.
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.
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.
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/...