A website that allows login via forgot password -> send email -> reset password should skip passwords entirely and use magic links instead.
Also, at this point there’s a huge number of previously leaked passwords. So websites should simply not allow passwords that have appeared in those leaks.
I always forget how stinking nice password manager autofill is until I have to fight with magic links because some service hates me. And most implementations I've seen only log you in from the new link the email sent, not the original page. So if you are trying to log in on a device your email isn't signed in on, you get to type the entire thing in on your second device.
More times than I would like, I have had to manually type out some ludicrously long secret key/token/url. Could we please standardize on only using long strings that do not require il1o0 in them? I suppose it is a failure of Latin or the default fonts with which I am frequently stuck, but it would save me a minor bit of life aggravation.
> And most implementations I've seen only log you in from the new link the email sent, not the original page.
Probably because:
- Bad actor A attempts to login
- User B sees the email and unthinkingly clicks the magic link
- Bad Actor A now has access.
There are probably ways around this (browser session/cookies/IP/etc must match?) but that'd be a common enough scenario...
Common enough that e.g. Microsoft Authenticator switched from sending a notification that you can tap to approve/reject (same as scenario above) to needing to enter a 2-digit code that you also see on the webpage (so without seeing Bad Actor A's page you cannot enter the code and approve their login).
I absolutely hate the magic links :S
A whole bunch of AI companies are going that route where you can’t have a password and login via magic links - eg Perplexity
There is no less attractive use of blockchain tech than login. The biggest problem with login security isn't attesting to an identity, it's account recovery; blockchains make that incredibly difficult.
Fair enough, I guess for crypto wallets there isn’t any recovery that can be done if you lose the private key. In the end a cryptocurrency wallet is usually just a pub/priv keypair, so purely for login/identity purposes it’s similar to passkeys. And can be backed up easily.
What I wanted to say is that hopping around different ‘dapps’ is quite seamless from a login point of view (and has benefits like ability to pay for goods immediately).
Often I don’t even proceed exploring some website if it asks me to create an account since the friction is high.
In any case, this popped into my head as I was exploring openrouter.ai yesterday (routing layer for LLMs, you buy credits and can use many models), and they had a “Login with MetaMask” option, which is rare for non-crypto websites, and it worked quite seamlessly.
Ah, the crypto industry known for being exceptionally secure in their practices, always vetting their security, and never cutting corners. We should do what they do.
(Don't ask about what happened to the Ronin Network, Poly Network, FTX, Coincheck, etc, etc)
just like we have to separate the art getting the artist, we have to separate cryptocurrency from the cryptography. The underlying primitives are sound. Still not gonna factor 4096-bit keys any time soon, quantum computers won't be able break that for at least another decade.
This person is wildly overthinking their problems.
Early in the piece, they marvel that it's somehow OK to email magic login links to people, but not to SMS logins. Yes: among other reasons, that's because there's nobody an attacker can realistically call on the phone or bribe at a neighborhood cell phone store to rehome an email account. Nobody wants to do away with SMTP more than I do, but everybody has it, and most people (by an overwhelming majority) host it with their absolute most secure provider.
Get past the SMS/SMTP thing. You're doing a low-sensitivity CMS application. It would be bizarre for you to have a Passkeys implementation. It's even weird for you to do login-with-Google or SIWA. Just mail magic links! Be done with it!
TOTP is dead tech. Implement the full gamut of OIDC provider logins --- most of which have better TOTP implementations than you'll come up with (but also tend to steer their users away from TOTP) and forget that it exists.
I'd like to have a coda here about how things get much harder if you're a high-sensitivity application. But they don't. Mostly what happens is that OIDC signon gets much more important.
The bit about TOTP secrets being worse, harder-to-rotate passwords also misses the point of why passwords are bad and why unmasked TOTP seed storage is not in fact that big of a deal, but who cares? Just don't do TOTP.
> they marvel that it's somehow OK to email magic login links to people, but not to SMS logins
The answer here is that, even if you aren't emailing magic links, you're emailing magic links: the "forgot my password" flow is effectively a magic login link, because it uses your email as your single authentication method. There's then no additional loss of security if you use magic links instead of passwords.
What's wrong with TOTP? Are you using that term in a technical sense to mean something specific or are you referring to any situation where someone needs to consult an app on a second device to receive a code to present to the first device?
How does a server using WebAuthn know that the client it is talking to is the right one? For example, say my bank wants to use WebAuthn instead of a username and password to let me access my account. How does the bank's server know that the public key I give it (via my browser) corresponds to my account?
Also, what if my device gets stolen? How do I prevent someone else from accessing my account, since the secret needed to do so is on the device, not with me?
1) They link the public key to your user account in their database.
2) Passkeys are 2FA by default. Someone needs to steal your phone where the private key is stored (first factor) and they would need your Face ID / Touch ID / PIN Code (second factor). Just loosing your phone doesn't give someone else the chance to use your passkey for authentication.
The way I think of it is: my browser’s password manager is the phishing-resistant portion of the system, and TOTP ensures that I am the one sitting at my browser.
Passkeys sound interesting, but I have a (perhaps incorrect) user-hostile big-tech lock-in feeling from them. I really could be wrong, but it feels like the intention is for us all to have to use accounts from Google, Microsoft, Facebook or Apple (maybe Mozilla, maybe), using browsers from Google, Microsoft or Apple (maybe Firefox), on OSes from Google, Microsoft or Apple.
Yes, that might be a strategic thinking of big tech. Still you can use third-party password managers like Bitwarden, KeePassXC or 1Password to take care of your passkeys. I think, for most non-technical users, they will go for the Apple/Google/Microsoft credential manager option but if you're more tech-savyy, there are ways to stay independent of big tech.
Agree. If I show my parents or great-parents TOTP, they're usually lost and hate it. Recently, I've seen a study that anyway +90% of users choose SMS OTP over TOTP.
> why unmasked TOTP seed storage is not in fact that big of a deal
Wait, why is it not a big deal? Isn’t this similar to storing a plain text password server side? (OK, not user generated). If my server gets hacked, doesn’t the hacker get all the totp’s for everyone, much like getting everyones password?
Because the secrets have no intrinsic value. If you believe your database has been compromised, you just invalidate them all. The problem with password compromise is that passwords are re-used: losing a user password is a big deal. There's a reason there's no "Has My TOTP Seed Been Pwned" site anywhere.
Losing a user password is a “bigger deal” when the password is re-used, I get this point.
> Because the secrets have no intrinsic value
This is too strong. In general, it’s not possible to know my database has not been compromised. TOTP invalidation isn’t a trivial thing either, particularly if it was used instead of passwords and not as a 2nd factor.
Not really (I can login to some systems with just TOTP, but TOTP was registered as a supplemental to something else). I guess your point is that having the seeds exposed is as big a deal as having salted hashes exposed. Which is to say, not a big deal.
> I would much rather use TOTP than be forced to use a phone number. Phones can break.
Phones / SMS is also less secure than TOTP. It’s odd that most orgs that require 2FA yet accept only phone calls or sms as the second factor are financial institutions.
Controversial opinion: Username and password is perfectly fine.
To provide an example that most people here are probably comfortable with: An SSH key is effectively a really long password with cryptographic properties. It's a single factor, one thing, that you use to complete a challenge for the server. We are fine to use SSH keys as our only authentication factor for servers, with IP whitelisting where security trumps convenience; why should we feel uncomfortable using long passwords as our only authentication factor for websites, with opt-in MFA when security trumps convenience?
Instead, websites enforce terrible 8-20 character passwords with a recipe of strict requirements to help crackers, and a download of the flavor of the month authenticator app that quickly becomes burdensome and annoying.
Why does my library think they're Fort Knox and want me to get an authenticator app? The tech is fine, but its universal forced application bugs me. It's like those campaigning for enforcing MFA everywhere never considered that different users have different risk appetites/tolerances.
The problem with passwords comes when humans mismanage passwords and pick bad ones. Passwords themselves are fine.
Mutual TLS was necessary but a giant pain in the butt for an app I worked on that needed to do over the air updates over WiFi. Getting it working across all of the moving parts was a significant part of the overall effort for the OTA part of that project.
OCSP existed back then which helped but I don’t know if stapling had been widely implemented yet.
Yes, I deliberately didn't say it was _exactly_ a long password. I was more trying to get across the single-factor side of it.
In any case, if the service handles passwords properly and the user generates one password per service (both wild far-out concepts unfortunately), leaking the salted hash would not matter.
Not to admit to poor security practices in public, but I don't generate different ssh keypairs for every server I log in to. If each keypair represents one password, and we're never supposed to reuse a password, I'm in trouble.
> We are fine to use SSH keys as our only authentication factor for servers…
Are we? True 2FA for ssh keeps getting easier. There’s FIDO2 support now for example. The gold standard includes 2FA and I don’t see why that shouldn’t continue filtering down to common practice, just as has already happened with ssh keys.
> An SSH key is effectively a really long password with cryptographic properties
"An SSH key is basically a really long password, but also at the same time it's not a really long password, and you interact with it entirely differently." OK.
Modern password managers make long passwords vaguely "look like" SSH keys much in the same way a truck might vaguely "look like" a train. But they only achieve this by taking over the creation and use of the password entirely, even going so far as to tie them to origins in your browser, to prevent them from being inserted into a hostile webpage (phishing attacks still work just fine.)
So they're not really passwords anymore, just bearer tokens. But bearer tokens are not SSH keys, anymore than a password is an SSH key.
The SSH analogue to login passwords are SSH passwords, not SSH keys. And nobody uses SSH passwords anymore for the same reason people don't like web passwords, today (at least on the web 90% of the time you can email reset.) Even the follow up methods like credential stuffing are identical; typing in a password to a hostile SSH server will absolutely result in that username+password being spammed at every possible service as a brute force method. The reason this method isn't still popular today is because collectively ~everyone started using keys like 20 years ago for everything. But credential stuffing and phishing are still massive problems for the web.
Many of the questions about TOTP lengths / timing / storage are covered in the Security Considerations part of the RFC[1]. This is written in fairly plain language. The meta answer is if you're implementing a security protocol yourself, you should always be reading the RFC for this sort of thing. If you're designing a library to implement a security protocol, you should document the parts that need to be implemented according to spec (e.g. storage / transmission / time / etc.).
On a what can we do perspective. We actually need some higher level concepts in play than just the APIs. What you really care about is:
1. You can identify the user.
2. The identity used by the user doesn't have a single point of failure.
Passkeys solve only the first part. You want the browser to tell you that the user has synced the passkey to another place other than just the browser. Or you want some other way to remove the reliance on a single factor.
The problem you really have though is not everyone has the same ability to sync passkeys. For some apps giving you an email address is likely secure enough to satisfy requirement 2. I hate it being the primary option though - that's annoying AF.
The credentials api seems rather opaque to the user. What happens if I want to log in temporarily from a strange computer that isn't synced? Will I be shit out of luck? What if I don't have my own device with me?
I am anxious about the fact that if you lose your phone in the modern world, you are in for so much work and inconvenience. I don't carry my personal laptop everywhere you know. So throughout the day, for many hours my phone is basically 1FA, not 2FA, and I think that goes for lots of people.
59 comments
[ 3.0 ms ] story [ 44.2 ms ] threadAlso, at this point there’s a huge number of previously leaked passwords. So websites should simply not allow passwords that have appeared in those leaks.
Probably because:
- Bad actor A attempts to login - User B sees the email and unthinkingly clicks the magic link - Bad Actor A now has access.
There are probably ways around this (browser session/cookies/IP/etc must match?) but that'd be a common enough scenario...
Common enough that e.g. Microsoft Authenticator switched from sending a notification that you can tap to approve/reject (same as scenario above) to needing to enter a 2-digit code that you also see on the webpage (so without seeing Bad Actor A's page you cannot enter the code and approve their login).
The ”login” is the dapp showing the user a message to sign to prove they own the key, then you can sign the message, and that’s the whole login.
There’s various ways to implement it, but here’s a quick tutorial for doing login with MetaMask. https://docs.metamask.io/wallet/how-to/sign-data/siwe/
What I wanted to say is that hopping around different ‘dapps’ is quite seamless from a login point of view (and has benefits like ability to pay for goods immediately). Often I don’t even proceed exploring some website if it asks me to create an account since the friction is high.
In any case, this popped into my head as I was exploring openrouter.ai yesterday (routing layer for LLMs, you buy credits and can use many models), and they had a “Login with MetaMask” option, which is rare for non-crypto websites, and it worked quite seamlessly.
I can share a blog post about this topic that I recently wrote if you're interested in some details (e.g. Coinbase did it this way).
(Don't ask about what happened to the Ronin Network, Poly Network, FTX, Coincheck, etc, etc)
Early in the piece, they marvel that it's somehow OK to email magic login links to people, but not to SMS logins. Yes: among other reasons, that's because there's nobody an attacker can realistically call on the phone or bribe at a neighborhood cell phone store to rehome an email account. Nobody wants to do away with SMTP more than I do, but everybody has it, and most people (by an overwhelming majority) host it with their absolute most secure provider.
Get past the SMS/SMTP thing. You're doing a low-sensitivity CMS application. It would be bizarre for you to have a Passkeys implementation. It's even weird for you to do login-with-Google or SIWA. Just mail magic links! Be done with it!
TOTP is dead tech. Implement the full gamut of OIDC provider logins --- most of which have better TOTP implementations than you'll come up with (but also tend to steer their users away from TOTP) and forget that it exists.
I'd like to have a coda here about how things get much harder if you're a high-sensitivity application. But they don't. Mostly what happens is that OIDC signon gets much more important.
The bit about TOTP secrets being worse, harder-to-rotate passwords also misses the point of why passwords are bad and why unmasked TOTP seed storage is not in fact that big of a deal, but who cares? Just don't do TOTP.
The answer here is that, even if you aren't emailing magic links, you're emailing magic links: the "forgot my password" flow is effectively a magic login link, because it uses your email as your single authentication method. There's then no additional loss of security if you use magic links instead of passwords.
Bear in mind the saying: it's impossible to make anything foolproof because fools are so ingenious.
Also, what if my device gets stolen? How do I prevent someone else from accessing my account, since the secret needed to do so is on the device, not with me?
2) Passkeys are 2FA by default. Someone needs to steal your phone where the private key is stored (first factor) and they would need your Face ID / Touch ID / PIN Code (second factor). Just loosing your phone doesn't give someone else the chance to use your passkey for authentication.
Passkeys sound interesting, but I have a (perhaps incorrect) user-hostile big-tech lock-in feeling from them. I really could be wrong, but it feels like the intention is for us all to have to use accounts from Google, Microsoft, Facebook or Apple (maybe Mozilla, maybe), using browsers from Google, Microsoft or Apple (maybe Firefox), on OSes from Google, Microsoft or Apple.
Wait, why is it not a big deal? Isn’t this similar to storing a plain text password server side? (OK, not user generated). If my server gets hacked, doesn’t the hacker get all the totp’s for everyone, much like getting everyones password?
> Because the secrets have no intrinsic value
This is too strong. In general, it’s not possible to know my database has not been compromised. TOTP invalidation isn’t a trivial thing either, particularly if it was used instead of passwords and not as a 2nd factor.
Fair enough.
What is "SIWA"?
Phones / SMS is also less secure than TOTP. It’s odd that most orgs that require 2FA yet accept only phone calls or sms as the second factor are financial institutions.
To provide an example that most people here are probably comfortable with: An SSH key is effectively a really long password with cryptographic properties. It's a single factor, one thing, that you use to complete a challenge for the server. We are fine to use SSH keys as our only authentication factor for servers, with IP whitelisting where security trumps convenience; why should we feel uncomfortable using long passwords as our only authentication factor for websites, with opt-in MFA when security trumps convenience?
Instead, websites enforce terrible 8-20 character passwords with a recipe of strict requirements to help crackers, and a download of the flavor of the month authenticator app that quickly becomes burdensome and annoying.
Why does my library think they're Fort Knox and want me to get an authenticator app? The tech is fine, but its universal forced application bugs me. It's like those campaigning for enforcing MFA everywhere never considered that different users have different risk appetites/tolerances.
The problem with passwords comes when humans mismanage passwords and pick bad ones. Passwords themselves are fine.
You know how much more convenient it is to just open a browser and go to a webpage and already be logged in?
[1]: https://en.wikipedia.org/wiki/Common_Access_Card
Safari (Apple), IE/Edge (Microsoft), and Chrome (Google) all operate their own ad networks. I'm sure they'd love their own version of X-UIDH [1].
[1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
OCSP existed back then which helped but I don’t know if stapling had been widely implemented yet.
In any case, if the service handles passwords properly and the user generates one password per service (both wild far-out concepts unfortunately), leaking the salted hash would not matter.
More of a problem is password reuse for multiple sites, which is impossible when using SSH keys.
Are we? True 2FA for ssh keeps getting easier. There’s FIDO2 support now for example. The gold standard includes 2FA and I don’t see why that shouldn’t continue filtering down to common practice, just as has already happened with ssh keys.
"An SSH key is basically a really long password, but also at the same time it's not a really long password, and you interact with it entirely differently." OK.
Modern password managers make long passwords vaguely "look like" SSH keys much in the same way a truck might vaguely "look like" a train. But they only achieve this by taking over the creation and use of the password entirely, even going so far as to tie them to origins in your browser, to prevent them from being inserted into a hostile webpage (phishing attacks still work just fine.)
So they're not really passwords anymore, just bearer tokens. But bearer tokens are not SSH keys, anymore than a password is an SSH key.
The SSH analogue to login passwords are SSH passwords, not SSH keys. And nobody uses SSH passwords anymore for the same reason people don't like web passwords, today (at least on the web 90% of the time you can email reset.) Even the follow up methods like credential stuffing are identical; typing in a password to a hostile SSH server will absolutely result in that username+password being spammed at every possible service as a brute force method. The reason this method isn't still popular today is because collectively ~everyone started using keys like 20 years ago for everything. But credential stuffing and phishing are still massive problems for the web.
[1]: https://www.rfc-editor.org/rfc/rfc6238#section-5
On a what can we do perspective. We actually need some higher level concepts in play than just the APIs. What you really care about is:
1. You can identify the user.
2. The identity used by the user doesn't have a single point of failure.
Passkeys solve only the first part. You want the browser to tell you that the user has synced the passkey to another place other than just the browser. Or you want some other way to remove the reliance on a single factor.
The problem you really have though is not everyone has the same ability to sync passkeys. For some apps giving you an email address is likely secure enough to satisfy requirement 2. I hate it being the primary option though - that's annoying AF.
I am anxious about the fact that if you lose your phone in the modern world, you are in for so much work and inconvenience. I don't carry my personal laptop everywhere you know. So throughout the day, for many hours my phone is basically 1FA, not 2FA, and I think that goes for lots of people.