Email accounts are the highest common denominator in online authentication. Phones are competitive, but people lose phones. Phone numbers are more common and durable, but the security of phone numbers is leagues below that of a flagship provider email account. It makes sense that so many authentication flows work this way.
When designing a "fantasy football" alternate authentication system for the Internet, start with account recovery: what happens when a user loses your fancy authenticator? If the answer is "they just don't get access anymore" or "a panel of their peers attests to them", your fantasy authentication system also needs a fantasy species of sentient beings to serve as users, because it won't work for humans.
> If the answer is "they just don't get access anymore" or "a panel of their peers attests to them", your fantasy authentication system also needs a fantasy species of sentient beings to serve as users, because it won't work for humans.
This has been my single biggest argument against blockchain/cryptocurrency stuff for years: the "lose your key, lose your wallet" thing is fundamentally incompatible with real users.
Humans need to be able to recover from their mistakes.
> [...] the "lose your key, lose your wallet" thing is fundamentally incompatible with real users. Humans need to be able to recover from their mistakes.
Maybe it's my memory playing tricks, or I've only seen the good articles, but I believe nearly every single article about setting up a self-managed crypto wallet had stressed out the importance of having a backup. Serious ones had even explained the 3-2-1 rule. Then the hype came, with it came scams and pumps-and-dumps and NFTs and whatever, and crypto became a clusterfuck that a lot of people didn't want to touch. Yuck.
That's probably the one thing cryptocurrency communities undeniably got right. Quite unlike the Passkeys, where I've yet to see any official or semi-official demo site that even has a flow for adding a second token (some actual sites do, but not the demos).
We should start teaching basic backup strategies in schools. It's not some advanced rocket science, and it's a knowledge that's useful to anyone who deals with information (that is, literally anyone participating in the modern society).
Also, this user unfriendliness is extremely temporary, because computers and Internet are new (at the scale of societies), and there are plenty of folks who had only started to use them later in their lives. After you lose some file or account (ideally, as a kid, so it's not something serious) you start to understand the old adage about those whose do backups and those who don't do them _yet_.
> the "lose your key, lose your wallet" thing is fundamentally incompatible with real users.
You're allowed to store your key at the bank if this is an issue for you. It's less secure than memorizing it, but obviously equally as secure as your bank account is.
With current currencies you don't have an option, you HAVE to give your money to banks and accept its consequences, like losing privacy, risk of have it frozen, etc.
With cryptocurrencies at least you have an option, you can leave it at a custodial wallet that can manage some of the security for you or you can have a non-custodial wallet.
Maybe instead of a crypto brokerage holding your wallet, there can be a "key bank" which uses those more expensive methods of attestation and you can use it for recovery if you lose your key up to once per year or something. It would be like having your key written down in a safety deposit box at a local or regional bank.
>> If the answer is "they just don't get access anymore" or "a panel of their peers attests to them", your fantasy authentication system also needs a fantasy species of sentient beings to serve as users, because it won't work for humans.
>This has been my single biggest argument against fiat currency stuff for years: the "lose your money, lose your money" thing is fundamentally incompatible with real users. Humans need to be able to recover from their mistakes.
And yet, for the very longest time, it was the default position for humans.
> This has been my single biggest argument against blockchain/cryptocurrency stuff for years: the "lose your key, lose your wallet" thing is fundamentally incompatible with real users.
This would make currency fundamentally incompatible with real users. Reality says otherwise.
I've heard that a lot about cryptocurrency, but aren't there plenty of cryptocurrency users who have never lost their wallet and have good personal opsec?
Maybe the issue is trying to force one solution for everyone.
Government provided digital IDs would solve a lot of this. Yes, they may have their own problems, but outsourcing the action of identifying individuals to the government seems valuable and less prone to "lock outs" like Google and friends.
I think I've said it before, but I want USPS-provided email. To set one up you'd go to a post office, verify your identity in some way, and set up an email. If you forget your password and want to recover it, you'd have to go back into a post office and verify your identity again.
> Government provided digital IDs would solve a lot of this.
Over here in EU, we have something like it - you get an ID card that has two PIN codes that you can use with a card reader and some software to digitally sign documents and such: https://www.eparaksts.lv/en/ (of course, there's also a mobile version)
In addition, there now are services where you can log in to your bank account, confirm payments, or just log in to your government portal account with a two factor app, the account on which is based on your identity: https://www.smart-id.com/
So if I make a payment online with my card, I'll have to authenticate through either a code calculator (physical piece of hardware) or the phone app with codes that I've chosen, to confirm it. Same for logging into various sites, for example, for paying my utilities.
Works pretty well and if I lose my ID card, then I can get a new one, issue new certificates for the apps and continue where I left off (with the old ones being revoked). I might need a backup phone too, though, since not being able to confirm my payments if my phone breaks is pretty stupid (though I guess Revolut/PayPal/whatever still work as expected, unless I only have my OTP codes for those on said phone).
My wife works in a city clerk's office. They provide (among other things) vital records services for the city. Like getting birth certificates.
To get a birth certificate, you must provide government photo ID with a name matching that of one of the names on the certificate you're trying to get. So you can get your own, or your child's, but not some random other person's.
Lots of people were born before RealID driver's licenses. Some of them went by names other than the names on their birth certificates, and thus are unable to get new copies of their birth certificates using the government-issued photo ID they currently have. E.g. I've got a grandfather who went by Sam his entire life but was apparently named Harold. His driver's license had Sam as his first name. If he had lost his birth certificate, he would not have been able to obtain a new copy legally using that driver's license! This still happens to people. Also sometimes house fires or similar disasters happen, and people lack the ID needed to get new government-issued ID.
It certainly is an alternative we can at least think about.
On one hand, the certs you'd use to login to websites wouldn't even need to include any personal info at all, just a valid signature from a CA that the website knows how to verify. And the certificate wouldn't need to be the same for every website, it could be one you generate for a specific website.
On the other hand, a lot of thought would need to be put into how expiration/renewal and revocation would play into this.
Of course there should be an evaluation of the ways this could go wrong if someone from the gov misuses this CA, and how that compares to someone from your current email provider misusing their permissions.
But if nothing else, something I really want is to just be able to have an email address like `random_id@my_country.my_country_tld`, to at least have an email address where I don't have to worry about being locked out, so that I can give freely to ISP, bank, grocery delivery websites, other local companies, etc. Most of this stuff I wouldn't even mind receiving as postal mail anyway. And if shit hits the fan, I can recover access to this email account by walking to an office and identifying myself.
Finland tried to copy it, but the Finnish card (while based on the same technology) is used very little. Finnish banks already had their own OTP solutions, which they started offering for authentication on other web sites, so no-one wanted an extra authenticator on top of that. This of course means that you get phishing emails pretending to be from all sorts of government services, where the goal is to get your banking credentials and take your money.
Since then, mobile phone operators added their own authentication system based on credentials residing on your SIM card <https://mobiilivarmenne.fi/en/>. You prove your identity when getting a mobile phone contract and can then use that to log into many sites.
I haven't heard a compelling argument that anything needs to be fixed with email-based auth patterns. It is imperfect but not bad, and every proposed alternative seems to be worse.
The article seems to lean into security and usability concerns.
On the security front: the weak-point is still the human. If you hand over your credentials to someone nefarious, well.. you handed over your credentials to someone nefarious.
Usability isn't convincing me either. One of the great things about email is that it really is the lowest-common denominator, as another commenter mentioned above. (Almost) everyone, from kids to the most tech-inept luddite have some sort of email.
It has it's pros and cons, maybe more pros if you factor in that the biggest issue isn't authentication really, it's the fact that all of these private companies accrue everyone's sensitive info, which can be abused by any actor, private or public. If data were kept on the client side, and synced to other machines through P2P like WebRTC, then maybe this wouldn't be such a big deal.
> Government provided digital IDs would solve a lot of this
A lot of what? It seems like the worst of all worlds, given that ID would not only unlock some highly sensitive things, but also be difficult to change and tremendously revealing.
It does solve a lot of this. Some have gov’t issued IDs, others have a hybrid public/private system where banks issue the ids. But yes, a de facto standard electronic ID is almost unthinkable to not have. How else do you interact with authorities or healthcare? I used e-ID since long before smartphones, I can barely picture what it would be like to log in to handle taxes, benefits medicine recipes or doctors appointments if it worked any other way.
> Government provided digital IDs would solve a lot of this. Yes, they may have their own problems, but outsourcing the action of identifying individuals to the government seems valuable and less prone to "lock outs" like Google and friends.
Sadly, the US government goes the other way and contracts out verification (to government websites!) to an invasive private company.
How about a bank-provided digital id that you get when opening an account by walking into a physical bank location and providing your photo ID? It would tick the "less prone to lock out" problem without placing even more power in government hands.
Unfortunately, "they just don't get access anymore" is the usual pattern with major email providers like Google, as many people who have had a phone lost or stolen and then been locked out of their accounts forever can attest to.
>Phone numbers are more common and durable, but the security of phone numbers is leagues below that of a flagship provider email account.
With the - "we banned your account for no reason, and you have no way to appeal and we don't even tell you why we banned you" flagship provider email account caveat.
It's an interesting design problem to have panel of peers attest an individual's identity. It could be made fairly seamless if there was a common system in which a suitably distributed authentication secret could be recombined under instruction from the relevant party. Can it be made to work for normal humans? I daresay we have the ingenuity to design something...
Apple’s Recovery Contacts are a similar idea. The main difference is that just one can help you recover your account, but it doesn’t seem too hard from a UX perspective to make 3/5 recovery contacts required to unlock an account.
The Decentralized Recovery (DeRec) Alliance has recently launched to solve this very problem. Dr. Leemon Baird gave a talk last year on how this works at a higher level [0]. The alliance is comprised of members from the Algorand, Hedera, Ripple crypto communities but the application of proper DeRec would be certainly applicable anywhere you have any type of secret; in fact I believe you can be a DeRec 'helper' right now. There's a robust primer on the protocol published as well [1], here's a pull-quote:
> Decentralized recovery is a method of safeguarding a user's secret by distributing shares of that secret among multiple helpers, who store their individual share on their local device in order to help the user recover that secret in future. The shares are constructed under a threshold secret-sharing scheme (e.g. Shamir's secret sharing scheme), with a chosen threshold (defaults to half) -- at least three helpers must be present in order to use the protocol. Should the user lose access to their device, they can recover their secret data by retrieving the previously-distributed shares from at least half of their helpers. For successful recovery, the user only needs to recall the identities of half of their helpers and authenticate with them in-person.
Of course it works. I was aware of such mechanisms appearing in the Chinese social media app WeChat years ago. In fact I would say it's a great fit for any kind of social media app that involves interacting with peers.
However the utility is probably nil if there're no social features to begin with.
We could also leverage trusted third parties for this purpose, for example, banks or DMV or Walmart.
However, there needs to be a fiduciary interest by the third-party (eg liability for identity theft, etc) in order to incentivize them to avoid fraud. It is not clear that there would be enough profit involved to offset the liability.
Auth apps are crap - each one pretends to be unique and authoritative.
TOTP secrets are a string, not just a QR code that can only be seen once and never again - the QR code merely encodes that string! That string can be used in multiple places to generate codes. KeepassXC can do it and that can be shared. I've seen loads of organisations and sites with an elderly mobile phone that has the TOTP auth app on it. Normally MS Authenticator.
To add insult to injury, MS Auth can only have one account per email address (id@realm/whatever you want to call it).
PrivacyIdea can do email based TOTP with a PIN. That works well but does involve a two stage login with an email delivery in the middle.
I totally agree with you: the only useful delivery mechanism available is email. PGP was a nice idea and authenticator apps need to have their owner's heads bashed together to get proper interoperability sorted out. Trying to silo people in your "cloud" without interoperability with others is so sad and needy. If you don't have absolute confidence in your offering then you are shit!
A little off-topic from the matter of adoption and usability by the greater masses, but I personally prefer these RFC 6238 TOTPs that I have the choice to take into my own hands, as opposed to internet-required, server-side based like my banking app and Okta.
I have a copy of all my TOTP generators (minus my dev Okta account) in a common authenticator app and an offline copy stored in an offline password manager, further replicated with an encrypted backup service.
I was able to create my offline copy in the first place thanks to a rooted phone to export what I already had up to that point out of the authenticator app.
Of course, the discussion starts to morph when we bring in the "un-phishable" software passkeys.
> To add insult to injury, MS Auth can only have one account per email address (id@realm/whatever you want to call it)
When this was discussed [1] on HN a few weeks ago, I don't recall anyone reporting reproducing it. Several people, including me, reported having many accounts in MS Authenticator that have the same email address with no problem.
The otpauth URI that is encoded in a TOTP QR code looks like this:
otpauth://totp/LABEL?parameter_list
The LABEL is supposed to serve as a unique identifier for the account. It has the format "Issuer:Account". The "Account" part is required. The "Issuer" is optional (and the ":" omitted if the issuer is not present).
The parameter list is an & separated list of name=value pairs. It includes the "secret" parameter which gives the TOTP secret. An optional parameter is "issuer", which should match the "issuer" part of the label if that is present.
It sounds like what is happening is that there are some sites who do not include the "issuer" part the the label, and they let the user use a user provided email address as the account name.
If a given user uses two such sites and provides the same email address to both, then there will be a collision. If they also do not include an issuer parameter an authenticator app has no way to know just from the data in the codes that they are from different sites.
I'm increasingly coming around to the idea that in reality, there's only one factor, at least as far as the Internet is concerned: Something you know. There's different ways of knowing it and various difficulties involved in knowing it, but "something you are" is only every a fancy way of presenting something you know (because if you know it, you can generally forge it with reasonable effort) and "something you have", over the Internet, is just "something you know but is pretty difficult to directly extract".
TOTP was what really kicked me into thinking this way. They tried to make it "something you have". They tried to lock it behind apps and pretended really hard that it wasn't just a particular shared secret... but it is. It's just something you know.
The rule is, if it could be stuck in your password manager, it's a thing you know. That includes even things like Yubikeys, which are things that can be cloned and stuck in a password manager. They're just really, really hard to clone, and that's a valid step up from "a password". I'm not saying that the differences between all these "things you know" are irrelevant; they matter a lot. Having a password + a TOTP is a legitimate step up from having just either one alone. I'm just saying that analyzing things in terms of the other two factors isn't particularly relevant.
If the answer is "they just don't get access anymore" or "a panel of their peers attests to them", your fantasy authentication system also needs a fantasy species of sentient beings to serve as users, because it won't work for humans.
It won't work for 99.99% of services, but it can work if your service is huge. WeChat uses a mechanism like this, and it works well.
Everything is vulnerable. Lost my email when email provider (openmailbox.org) closed, with no chance of recovery. And with it lost a 28-years old domain.
People have lost Gmail accounts over some YouTube comment.
Lost my phone couple of times and was able to restore authy from backup ok.
Maybe we should support logging in with an OTP to email for many more systems than we do currently? Combined with conditional access and MFA its actually not bad.
No password to remember and supports this "pattern"
I've seen a couple of enterprise/corporate services switch to the "OTP via email" pattern (usually as mandatory 2FA), and I hate it, because there's no way for me to autofill that email OTP, unlike for e.g. WebAuthN or TOTP.
Can you expand what you mean when you say the security of phone numbers is leagues below email? If someone can gain access to someone's phone, it seems like they would gain access to their email as well.
Mobile phones identify themselves to the mobile network through a number called the IMEI. IMEI cloning is not particularly difficult nor does it require exotic equipment. This means that it is relatively easy for an attacker to be able to spoof your phone to a mobile network, for example, to receive SMS messages with one time passwords.
Cloning your IMEI has nothing to do with the data that is on your phone, so if someone clones your IMEI it does not mean that they have access to any of the apps or data that is on your phone.
We run a pretty unserious business. That is, our users use our accounts only out of convenience. The system we've settled on is this:
1. User enters email
2. We send a verification code to their email
3. User enters code, is signed in "indefinitely" (very, very long cookie)
Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multiple emails and sometimes creates a new account accidentally. This is an acceptable disadvantage as we've observed dramatic improvements in registration and sign in conversions.
There is some risk analysis to do here on the code lifetime and cardinality (better yet, use a lockout mechanism.) If your service isn't particularly important, I recommend this strategy.
Mail on iOS now supports this type of mechanism too (same as the Messages one-time code functionality) so it can be quite painless for some users as well.
This is also (from the data that I have seen) by far the best approach to maximise ecommerce revenue.
Don't force buyers into an account, just ask their details (the browser will autocomplete anyway). Send an email afterwards with a link to check their order status. Next order, ask for their email again.
Any extra friction costs more in lost revenue than the benefits of having "signed up" users.
I run a small B2C app. Users sign up with their email address only, a password field isn't even present. This creates the account and logs in the user "indefinitely" on this device. If they ever need to login on another device, they can request a new password. This way, this removes a) signup friction und b) weak passwords, because most people never need to login on another device anyways.
This is how I’ve implemented login several times now, and it comes from repeatedly having to undo a ton of assumptions about what a User Account is when attempting to modify a funnel to just actually work how people want it to on both sides of the equation.
Unless you’re operating in an anonymity preserving space, you can just do this and choose to integrate with passkey later.
The main disadvantage of this method is that you have to think about managing multiple users for an account sooner than you normally would, since sharing a password is no longer possible. I can’t think of a funnel or UX that isn’t ultimately improved by conscious effort here.
The other is of course that your security becomes limited by the weighted average of security of your users’ email providers, which will generally be better than you need. Passwords can then be your second factor here, when you finally need them, or you can use some other factor yet again. In B2B you can jump straight to SAML or OIDC connections.
In B2B or D2C contexts this has always just worked and the edge cases are generally worth solving for the benefits to acquisition.
Magic links make assumptions about how users are accessing your sign in. That the device opening the email is the device using the authorization. Or that the user is signing into a web page and not a native/mobile app.
Second this, used this approach on a tiny CRUD app that was essentially a single form. The amount of support requests (approx. zero) throughout the campaign was absolutely worth it.
I mean, it doesn’t really matter. Just do it as long as it works and when it stops working they can sign in again. The point is to quit hassling your users in the name of “security” if you’re not a security critical application. YMMV.
At this point why not just pass a one-time url link to your email address, and have it be a single click to login? Have it expire within 10 mins if not used, and be one-time use disposable. Still, anyone who has the link initially should be able to login with your account - but it's only accessible from your email.
Obliterates all sense of security beyond the email account itself, but that's where we're at anyway. Do the same pattern with a message to your phone "click to authenticate login: www.someurl.com?p=134234535" and you've got 2FA without any dumb "enter this code".
I do this for many of my web apps, it's confusing to users ("why do I already have an account here? I never signed up!"), expensive (email sending isn't free) and slow (sometimes the emails go to spam, sometimes they get greylisted and people can't log in for hours, sometimes it takes a minute to arrive and that's way too long to wait), etc. I don't know if I'd recommend it.
I hate when services only use SMS for 2FA. Sometimes I have to stare at my messages for a few dozen seconds to get the code, but with standard 2FA it takes me half a dozen seconds to unlock my phone and get the code.
Can you elaborate on „email sending isn’t free“? What are you using to host the webapp? Can’t you just set up your own mail server and send whatever you want?
Agreed. Do password login option too if you remember it - all work - but point being just make it a giant "LOGIN HERE" button that just does the thing as mindlessly as possible.
Yep, I really hate when I have to go to email to get a verification code or click link to verify. I have a password keeper and 2fa for a reason. I hate the wait.
Oh I dont mean do it instead of passwords (if you remember them), but just as an alternative to the Forget Password or Authenticate dialogs using security codes. Should just be a "LOGIN HERE" mashable button
I'm coding up a webapp with this exact login process - the issue I've found is on mobile phones - apps like gmail won't let you copy the link into a browser without a preview. The preview consumes the link. (next.js auth)
It's a bit annoying, since I don't want to login into the gmail in-app browser, I want to login on my regular browser.
Don’t forget some people have antivirus scanners that will load up every link when the email is opened, so you can’t have the link expire after 1 visit.
This is I think why unsubscribe links now have a single button saying “Unsubscribe” or similar when you press them. Likewise anything interesting should require a 2nd user action after loading the page.
Yes easy mistake to make. But this goes back to HTTP basics: a GET request shouldn’t mutate state. Either don’t consume the link (ie allow reuse), have a user confirm action with POST, send a code instead. There are many alternatives.
Personal favorite? Send a 6-digit code with ~1h expiry, exchange for a refresh token and keep the session for a long time. If you have really high value irreversible actions then you can just confirm with a new code.
Also works if mail client is on a different device.
A work around could be: login link token is good for 24hours unused, or 5mins after the first use. That way you don’t leave the user in a loop or risk them not clicking the link within a short amount of time. The token still expires after a reasonable duration too.
Pleas don’t force this login method. It is extremely annoying for anyone with a non-standard email setup (often for security reasons), and is slow as all hell.
At that point you might as well go all in on single sign on. 95% of all users are going to be on gmail, outlook or apple anyway. Better to have a "sign in with google" button rather than "send a link to your (g)mail". They can track you either way.
I hate this with a passion and many sites use it like anthropic and clipdrop, I stopped buying credits on Clipdrop because logging in was so annoying. My email is on my phone and I want to access the site on my laptop. This adds so much friction and turns a 5 second task with one to two clicks into a longer than a minute task with many clicks. I emailed anthropic about this and they did added a login with google option but just let us use an email and password please.
WELL FUCK YOU TOO! - jk, I agree. Password option should be there still for saving sessions and avoiding this crap beyond the first registration (if you remember password), but I just meant this should be the baseline expectation of login flow. Oneclick google/facebook/etc too, despite those being an extra level of corporate data hell
I use a web service which does this. It's mildly annoying having to switch apps/tabs just to login, but hey at least it's not another password to remember.
Hah this blew up. tbf I meant instead of any Forgot Password or Send Authentication Code or whatever mess - if you can remember your password, do that to save more time.
Still, the loop to hit up email is so fundamental now the rest are secondary options - these Magic Links should just be the primary base-level expectation. It's annoying when services don't even get this right though and return you to the site with either:
- a new form to enter the one-time code they just sent (just put it in the link)
- a new form to enter a new password (who cares, make that optional to the actual sign in, to save time next login)
- (worst offense): they don't even actually sign you in after those forms and you have to re-enter everything
Login should be "do you have an email address? Okay great you're in". Because there is nothing beyond that from a security perspective these days.
Please never do this short amount of time. Email isn't reliable time-wise for delivery. You have systems like Postgrey (one of the basic spam protections for email servers) and deliberately pretends the email server is offline for emails from new servers until they server retries a set number of times.
Not to mention if your email ends up in a corporate quarantine until you can request it released.
A lot of sites do this, annoyingly. I hate when my internet experience is degraded because the bottom pentile of users can't figure out how to do something.
Yes, why must the majority suffer because a few dumb dumbs can’t remember their passwords? We need to subsidizing stupidity or else we will get more stupidity.
I despise magic links. The rare few times I have to log back into Notion or Slack, I want to rip my hair out because of how annoying of a system it is.
Please, for the love of god, just let me use my username/email and password. Have the magic link for the dummies that don't use a password manager if you have to, just let me do the username + password way.
I'd argue at this point that magic links are more secure:
1. Nearly every online service needs some sort of "forgot password" flow, and often times that flows boils down to what is essentially a magic link like TFA is about.
2. The vast majority of users these days use either personal email accounts from one of the big providers (Google, Yahoo, MS), or they use corporate accounts often through a hosted solution. 9 times out of 10 I'd bet the email provider has better security than whatever rinky dink website you may be creating an account on.
Emailing magic links is essentially "poor man's SSO". It makes much more sense IMO to have super secure email accounts (e.g. ideally with passkeys) and then just use magic links for everything else.
Agreed with OP, the security is basically nonexistent anyway due to Forgot Password flow making email the authority regardless. Sure, add a user/pass flow in addition for convenience and added security (i.e. delay the 3 minutes it takes to do a reset), but any real security would have to remove Forgot Password altogether or seriously delay turnaround time.
The idea that someone is going to invent and remember a password for every dumb service is not real, and when you build another password based authentication system, you are doing a kind of LARP.
Passwords are used in one of two ways:
1. a password manager guarded by a single actual password
2. the same password repeated between services
Practically every service offers e-mail recovery, so, in practice, your e-mail is your authentication.
Personal e-mail accounts are rarely replaced, not shared, and aren't reused. You've probably had your personal e-mail longer than your phone number. I've had at least five phone numbers in the life time of my current e-mail address. Other people now have those numbers.
There are also derived passwords, which are kind of a hybrid. Either as a pattern the human remembers or a manager that does the calculation per domain.
I'd also add that forgot password features at least notify the address owner of every attempt. Password based logins don't always email on every login from a new location.
Apple has made the incredibly annoying “you can’t just enter your 1Password/keychain password, you have to dick around with email” process much nicer; at least when it can recognize the email/text and enter the code for you.
Apple is the worst about this. The only option is that they send a message to an Apple device. I only have an iPad and not an iPhone or Macbook, so I often simply cannot log into my Apple account because they refuse to do anything else besides send it to an Apple device.
There is always a simple answer to such question, and it's usually about some inconvenience the service provider decided to set-up for the user. In this particular case I think the answer is obvious: email provider usually have a session which never really ends, and just sits there logged in unless the browser cache is wiped.
Make your service auth token to live for the same time as Gmail's, and as an alternative give users an ability to just login with OTP every time, but stop these unholy 12 hrs time-to-live auth token practices - your users will never log-in via password restore again.
The real reason may be that the websites in question simply do not work.
I have had troubles with Epic and Spotify accounts in the past. I make an account, I use it for a week, after a week session expires - Spotify kicks me out of my account. I try to log in, it says my password is incorrect. This is impossible, because my password is saved in my password manager. So I have no choice but to reset through email. First several times I receive the email, reset the password, the pattern repeats, after 3 or 4 repeats I don't even receive the email anymore, so I am forced to make a new account.
Currently I am logged into Spotify through my Google account, where I have zero issues so far. But if I use plain email, their auth system simply does not work.
I think this is closer to hinting at the truth. GMail and Cloudflare (and many other "high security orgs) have very long auth sessions. Why? Because the chance of somebody getting onto the PC of someone who uses these systems and hasn't logged out is actually really low. Most hacks are remote and based on weak passwords.
Unfortunately, we lack the consistent language to measure risk and decide "do I really need 2FA on this site?" "Is 30 minutes a reasonable session time?". I think as long as someone has an up-to-date virus checker, most would rather stay logged in to stuff. Anyone ever been asked to delete all cookies to fix a problem on a site? My answer is always to "go fish".
I remember somebody saying before, "it's your account, if you want to stay logged in and risk a hack, it's your risk not the company running the service". I believe that more and more. If your laptop is logged in and someone deletes all your EC2 instances, that's on you, not AWS for not logging you out sooner. They could but why should they? Piss off 1M users to try and protect 1 person who is too careless?
I also hate password expiration rules. A true manager's "bright idea" which is horrible for security. Once I was registered on a service which required a password change every month, so every single month I had to change a letter or number in my password, because they also stored all my previous passwords and did not let me just swap 2 passwords around, forcing me to create a "new" one every time. BTW my password is 24 characters of solid gibberrish which I can only remember by chanting a long mnemotechnique in my head, obviously never leaking anywhere and unpickable. So changing it is not easy. At some point I was so mad when I could not change a password in a way it did not repeat any of my previous modifications and still remembered easily, so i just put qwerty123 in, needing to log-in into service desperately. It was bruteforced days after.
I’ve seen sites that cut out the forgotten password step, or passwords entirely… email is the authentication.
1. Type in email address
2. Get sent and email with code
3. Enter code to login
While I can understand why someone might do this, as someone with multiple emails I kind of hate it. I had to add it to my password manager with the email and a note, so I remember which one to use and it’s not missing a password.
I have stopped giving websites money because the friction of using magic links was too much and I found alternatives that didn’t involve such a dumb login system.
My theory is if you can’t make a proper login system you’re skills probably aren’t good enough to deliver on what you’re promising. Magic links have turned from an annoyance to a filter for me.
"My theory is if you can’t make a proper login system you’re skills probably aren’t good enough to deliver on what you’re promising."
Using that logic, I wouldn't trust most websites I visit. Even FAANG companies with their billions can't do certain things properly. Even something reallly basic like focus the 2FA box when you ask for the code, don't make me have to click on it! Don't stop people pasting passwords, don't limit how long the password can be (within reason) don't say they can't use arbitrary characters like a - because "SQL Injection" and don't invent riduculous hurdles like adding random digits from a secret word as well as your password. If you are going to do that, just ask for two passwords or tell people if you choose stupid passwords, you will be hacked!
I like the password strength meter that doesn't block passwords that it has mistakenly decided are weak (20 random alpnanumerics) but instead estimates how quickly it could be hacked. People don't understand entropy but might understand "hacked in 5 minutes", they also don't want to be told that your password has to be at least 100 characters long with uppers, lowers, numbers, specials, klingon etc. If your system is that susceptible you are doing it wrong.
> I’ve seen sites that cut out the forgotten password step, or passwords entirely… email is the authentication.
I do this with a B2B SaaS: an individual user would log in maybe once of twice every six months. Have passwordless logins means:
1. No added pressure on the user to remember a password for a service they use rarely.
2. Easier onboarding for companies, as they upload a CSV of all their users and their users can get to work immediately without being prompted to create a password, double-check it, confirm it, adhere to the rules, etc.
I don't like using links in emails, as they get 'clicked' by many phone apps when previewing, by corporate virus scanners, etc.
I would say a huge proportion of non-technical consumers do not use a password manager. By only offering password signup and not magic links/codes, I am probably making life harder for the vast majority of consumers.
Even if I offer both options, I would guess that I’d see more drop off during my signup flow by asking for a password as well as verifying their email. Not to mention the code is way simpler without dealing with passwords and multiple login flows for email.
We offered it on a site with a "guest login" where people redeem vouchers but might not want to make an account. So I think that's one valid use case. We need to associate the voucher with the email, so we need to ensure they own it by clicking the link, in case of support hassles down the line for lost vouchers. And if they make the account later they can see their old ones from before.
That’s the reason I can understand why they do it. It’s less information they are holding on to, and they effectively outsource authentication to the email provider.
I get this a lot because I use Mullvad 99%of the time. I hate it, but I put up with it because I don’t have much choice. I guess they’re flagging the “popular” ip address that I’m using.
Keepassxc (and its browser extension) can do this easily. You just have to one time define that the website only takes a username field. After that it will autofill the correct email in the field.
I hadn't realised until reading this, that I use this exact method for Best Buy.
Not intentionally though - I have my password stored in 1Password, so I know it's correct, yet every time I try to purchase something through bestbuy.com I trip some sort of ATO protection that falsely claims my password is invalid.
I'm entirely willing to believe it's something on my side (ad blocker, local DNS blacklisting, etc.) but after a certain number of occurrances, you get bored trying to debug the problem and just follow the path of least resistance.
> Not intentionally though - I have my password stored in 1Password, so I know it's correct, yet every time I try to purchase something through bestbuy.com I trip some sort of ATO protection that falsely claims my password is invalid.
Are you sure it's not a maxlength mismatch? It is very common to have the "change password" field to have a different (or no) maxlength and then have the login page have a different maxlength. So you change your password to some 60 character password, then you log in where the maxlength is only 40 characters... wrong password! I actually have a policy now of having the maxlength stored in application config so it propagates to all password fields in my apps.
Edit: Just checked and yes there is a length mismatch (form to set password has maxlength of 54, but login page has no maxlength set). So if your password length is > 54 and 1Password doesn't automatically cut the password it stores to 54 characters or fewer, you won't be able to log in.
I know a few sites, one of them being Spotify, that will lock your account based on "suspicious activity", lie that your password is invalid, and force you to reset your password.
For most people, doing stuff on computers is a matter of brute forcing it until kinda does what it's supposed to. Software is made by people who have an intricate understanding of how the underlying system works, but it's made for people who don't. When users get to a pattern that works, they stick with it. It's becoming even more common now that many schools are using tablets for education - they don't get a good feel for how a computer works. Most people don't think about it. It's just there, and they're used to things being broken, so what's a few extra clicks?
> Software is made by people who have an intricate understanding of how the underlying system works
Maybe 10% of software developers actually have an intricate understanding of what they do, in fact it is because developers don’t really understand what they are doing is why regular people brute force horrible software.
Readit News
When designing a "fantasy football" alternate authentication system for the Internet, start with account recovery: what happens when a user loses your fancy authenticator? If the answer is "they just don't get access anymore" or "a panel of their peers attests to them", your fantasy authentication system also needs a fantasy species of sentient beings to serve as users, because it won't work for humans.
This has been my single biggest argument against blockchain/cryptocurrency stuff for years: the "lose your key, lose your wallet" thing is fundamentally incompatible with real users.
Humans need to be able to recover from their mistakes.
Maybe it's my memory playing tricks, or I've only seen the good articles, but I believe nearly every single article about setting up a self-managed crypto wallet had stressed out the importance of having a backup. Serious ones had even explained the 3-2-1 rule. Then the hype came, with it came scams and pumps-and-dumps and NFTs and whatever, and crypto became a clusterfuck that a lot of people didn't want to touch. Yuck.
That's probably the one thing cryptocurrency communities undeniably got right. Quite unlike the Passkeys, where I've yet to see any official or semi-official demo site that even has a flow for adding a second token (some actual sites do, but not the demos).
We should start teaching basic backup strategies in schools. It's not some advanced rocket science, and it's a knowledge that's useful to anyone who deals with information (that is, literally anyone participating in the modern society).
Also, this user unfriendliness is extremely temporary, because computers and Internet are new (at the scale of societies), and there are plenty of folks who had only started to use them later in their lives. After you lose some file or account (ideally, as a kid, so it's not something serious) you start to understand the old adage about those whose do backups and those who don't do them _yet_.
You're allowed to store your key at the bank if this is an issue for you. It's less secure than memorizing it, but obviously equally as secure as your bank account is.
Humans have been unable to recover from mistakes since day zero
With cryptocurrencies at least you have an option, you can leave it at a custodial wallet that can manage some of the security for you or you can have a non-custodial wallet.
>This has been my single biggest argument against fiat currency stuff for years: the "lose your money, lose your money" thing is fundamentally incompatible with real users. Humans need to be able to recover from their mistakes.
And yet, for the very longest time, it was the default position for humans.
This would make currency fundamentally incompatible with real users. Reality says otherwise.
Maybe the issue is trying to force one solution for everyone.
Over here in EU, we have something like it - you get an ID card that has two PIN codes that you can use with a card reader and some software to digitally sign documents and such: https://www.eparaksts.lv/en/ (of course, there's also a mobile version)
In addition, there now are services where you can log in to your bank account, confirm payments, or just log in to your government portal account with a two factor app, the account on which is based on your identity: https://www.smart-id.com/
So if I make a payment online with my card, I'll have to authenticate through either a code calculator (physical piece of hardware) or the phone app with codes that I've chosen, to confirm it. Same for logging into various sites, for example, for paying my utilities.
Works pretty well and if I lose my ID card, then I can get a new one, issue new certificates for the apps and continue where I left off (with the old ones being revoked). I might need a backup phone too, though, since not being able to confirm my payments if my phone breaks is pretty stupid (though I guess Revolut/PayPal/whatever still work as expected, unless I only have my OTP codes for those on said phone).
To get a birth certificate, you must provide government photo ID with a name matching that of one of the names on the certificate you're trying to get. So you can get your own, or your child's, but not some random other person's.
Lots of people were born before RealID driver's licenses. Some of them went by names other than the names on their birth certificates, and thus are unable to get new copies of their birth certificates using the government-issued photo ID they currently have. E.g. I've got a grandfather who went by Sam his entire life but was apparently named Harold. His driver's license had Sam as his first name. If he had lost his birth certificate, he would not have been able to obtain a new copy legally using that driver's license! This still happens to people. Also sometimes house fires or similar disasters happen, and people lack the ID needed to get new government-issued ID.
On one hand, the certs you'd use to login to websites wouldn't even need to include any personal info at all, just a valid signature from a CA that the website knows how to verify. And the certificate wouldn't need to be the same for every website, it could be one you generate for a specific website.
On the other hand, a lot of thought would need to be put into how expiration/renewal and revocation would play into this.
Of course there should be an evaluation of the ways this could go wrong if someone from the gov misuses this CA, and how that compares to someone from your current email provider misusing their permissions.
But if nothing else, something I really want is to just be able to have an email address like `random_id@my_country.my_country_tld`, to at least have an email address where I don't have to worry about being locked out, so that I can give freely to ISP, bank, grocery delivery websites, other local companies, etc. Most of this stuff I wouldn't even mind receiving as postal mail anyway. And if shit hits the fan, I can recover access to this email account by walking to an office and identifying myself.
Finland tried to copy it, but the Finnish card (while based on the same technology) is used very little. Finnish banks already had their own OTP solutions, which they started offering for authentication on other web sites, so no-one wanted an extra authenticator on top of that. This of course means that you get phishing emails pretending to be from all sorts of government services, where the goal is to get your banking credentials and take your money.
Since then, mobile phone operators added their own authentication system based on credentials residing on your SIM card <https://mobiilivarmenne.fi/en/>. You prove your identity when getting a mobile phone contract and can then use that to log into many sites.
The article seems to lean into security and usability concerns.
On the security front: the weak-point is still the human. If you hand over your credentials to someone nefarious, well.. you handed over your credentials to someone nefarious.
Usability isn't convincing me either. One of the great things about email is that it really is the lowest-common denominator, as another commenter mentioned above. (Almost) everyone, from kids to the most tech-inept luddite have some sort of email.
It has it's pros and cons, maybe more pros if you factor in that the biggest issue isn't authentication really, it's the fact that all of these private companies accrue everyone's sensitive info, which can be abused by any actor, private or public. If data were kept on the client side, and synced to other machines through P2P like WebRTC, then maybe this wouldn't be such a big deal.
A lot of what? It seems like the worst of all worlds, given that ID would not only unlock some highly sensitive things, but also be difficult to change and tremendously revealing.
wanting a Yubikey or similar,
and/or being able to use basic tools to make a key,
would also help.
But I'll take the government-led method as a Plan B, if it works.
Sadly, the US government goes the other way and contracts out verification (to government websites!) to an invasive private company.
Identity is relatively solved, there are just lots of sacrifices made in security in the name of convenience.
Fingerprints as consent to login, Facial recognition as consent to login... seems more like a username, than a password, or a username+password.
It's not exactly a government service, but Clear is trusted by the government enough to allow their customers to bypass the airport screenings.
Oh man, that sounds like a terrible idea privacy wise. Every website would make use of it to track it's user.
Not so much in the US though. They have no national registry of what citizens actually exist.
Dead Comment
With the - "we banned your account for no reason, and you have no way to appeal and we don't even tell you why we banned you" flagship provider email account caveat.
https://support.apple.com/en-us/102641
> Decentralized recovery is a method of safeguarding a user's secret by distributing shares of that secret among multiple helpers, who store their individual share on their local device in order to help the user recover that secret in future. The shares are constructed under a threshold secret-sharing scheme (e.g. Shamir's secret sharing scheme), with a chosen threshold (defaults to half) -- at least three helpers must be present in order to use the protocol. Should the user lose access to their device, they can recover their secret data by retrieving the previously-distributed shares from at least half of their helpers. For successful recovery, the user only needs to recall the identities of half of their helpers and authenticate with them in-person.
[0]: https://www.youtube.com/watch?v=AcF4abPoveM
[1]: https://github.com/derecalliance/protocol/blob/main/protocol...
However the utility is probably nil if there're no social features to begin with.
However, there needs to be a fiduciary interest by the third-party (eg liability for identity theft, etc) in order to incentivize them to avoid fraud. It is not clear that there would be enough profit involved to offset the liability.
TOTP secrets are a string, not just a QR code that can only be seen once and never again - the QR code merely encodes that string! That string can be used in multiple places to generate codes. KeepassXC can do it and that can be shared. I've seen loads of organisations and sites with an elderly mobile phone that has the TOTP auth app on it. Normally MS Authenticator.
To add insult to injury, MS Auth can only have one account per email address (id@realm/whatever you want to call it).
PrivacyIdea can do email based TOTP with a PIN. That works well but does involve a two stage login with an email delivery in the middle.
I totally agree with you: the only useful delivery mechanism available is email. PGP was a nice idea and authenticator apps need to have their owner's heads bashed together to get proper interoperability sorted out. Trying to silo people in your "cloud" without interoperability with others is so sad and needy. If you don't have absolute confidence in your offering then you are shit!
I have a copy of all my TOTP generators (minus my dev Okta account) in a common authenticator app and an offline copy stored in an offline password manager, further replicated with an encrypted backup service.
I was able to create my offline copy in the first place thanks to a rooted phone to export what I already had up to that point out of the authenticator app.
Of course, the discussion starts to morph when we bring in the "un-phishable" software passkeys.
When this was discussed [1] on HN a few weeks ago, I don't recall anyone reporting reproducing it. Several people, including me, reported having many accounts in MS Authenticator that have the same email address with no problem.
The otpauth URI that is encoded in a TOTP QR code looks like this:
otpauth://totp/LABEL?parameter_list
The LABEL is supposed to serve as a unique identifier for the account. It has the format "Issuer:Account". The "Account" part is required. The "Issuer" is optional (and the ":" omitted if the issuer is not present).
The parameter list is an & separated list of name=value pairs. It includes the "secret" parameter which gives the TOTP secret. An optional parameter is "issuer", which should match the "issuer" part of the label if that is present.
It sounds like what is happening is that there are some sites who do not include the "issuer" part the the label, and they let the user use a user provided email address as the account name.
If a given user uses two such sites and provides the same email address to both, then there will be a collision. If they also do not include an issuer parameter an authenticator app has no way to know just from the data in the codes that they are from different sites.
[1] https://news.ycombinator.com/item?id=41275846
TOTP was what really kicked me into thinking this way. They tried to make it "something you have". They tried to lock it behind apps and pretended really hard that it wasn't just a particular shared secret... but it is. It's just something you know.
The rule is, if it could be stuck in your password manager, it's a thing you know. That includes even things like Yubikeys, which are things that can be cloned and stuck in a password manager. They're just really, really hard to clone, and that's a valid step up from "a password". I'm not saying that the differences between all these "things you know" are irrelevant; they matter a lot. Having a password + a TOTP is a legitimate step up from having just either one alone. I'm just saying that analyzing things in terms of the other two factors isn't particularly relevant.
People have lost Gmail accounts over some YouTube comment.
Lost my phone couple of times and was able to restore authy from backup ok.
No password to remember and supports this "pattern"
I've seen a couple of enterprise/corporate services switch to the "OTP via email" pattern (usually as mandatory 2FA), and I hate it, because there's no way for me to autofill that email OTP, unlike for e.g. WebAuthN or TOTP.
Cloning your IMEI has nothing to do with the data that is on your phone, so if someone clones your IMEI it does not mean that they have access to any of the apps or data that is on your phone.
SMS are as secure as a letter compared to a postcard.
Dead Comment
1. User enters email
2. We send a verification code to their email
3. User enters code, is signed in "indefinitely" (very, very long cookie)
Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multiple emails and sometimes creates a new account accidentally. This is an acceptable disadvantage as we've observed dramatic improvements in registration and sign in conversions.
There is some risk analysis to do here on the code lifetime and cardinality (better yet, use a lockout mechanism.) If your service isn't particularly important, I recommend this strategy.
Mail on iOS now supports this type of mechanism too (same as the Messages one-time code functionality) so it can be quite painless for some users as well.
Don't force buyers into an account, just ask their details (the browser will autocomplete anyway). Send an email afterwards with a link to check their order status. Next order, ask for their email again.
Any extra friction costs more in lost revenue than the benefits of having "signed up" users.
I already have a password manager. I rather just generate a password on one go.
Unless you’re operating in an anonymity preserving space, you can just do this and choose to integrate with passkey later.
The main disadvantage of this method is that you have to think about managing multiple users for an account sooner than you normally would, since sharing a password is no longer possible. I can’t think of a funnel or UX that isn’t ultimately improved by conscious effort here.
The other is of course that your security becomes limited by the weighted average of security of your users’ email providers, which will generally be better than you need. Passwords can then be your second factor here, when you finally need them, or you can use some other factor yet again. In B2B you can jump straight to SAML or OIDC connections.
In B2B or D2C contexts this has always just worked and the edge cases are generally worth solving for the benefits to acquisition.
I find it a hassle to copy the code, finding the right tab where I left the login page and pasting the code to login.
Obliterates all sense of security beyond the email account itself, but that's where we're at anyway. Do the same pattern with a message to your phone "click to authenticate login: www.someurl.com?p=134234535" and you've got 2FA without any dumb "enter this code".
a message to your phone "click to authenticate login
Should be both code and a link (enter 1234 or click <url>), because it’s not always the phone you’re loggin in on.
But it's slow compared to my PW manager just autofilling a user/PW combo, since I have to wait for the email and go click the link.
It's a bit annoying, since I don't want to login into the gmail in-app browser, I want to login on my regular browser.
This is I think why unsubscribe links now have a single button saying “Unsubscribe” or similar when you press them. Likewise anything interesting should require a 2nd user action after loading the page.
Personal favorite? Send a 6-digit code with ~1h expiry, exchange for a refresh token and keep the session for a long time. If you have really high value irreversible actions then you can just confirm with a new code.
Also works if mail client is on a different device.
Why make things worse for your users?
Still, the loop to hit up email is so fundamental now the rest are secondary options - these Magic Links should just be the primary base-level expectation. It's annoying when services don't even get this right though and return you to the site with either:
- a new form to enter the one-time code they just sent (just put it in the link)
- a new form to enter a new password (who cares, make that optional to the actual sign in, to save time next login)
- (worst offense): they don't even actually sign you in after those forms and you have to re-enter everything
Login should be "do you have an email address? Okay great you're in". Because there is nothing beyond that from a security perspective these days.
Please never do this short amount of time. Email isn't reliable time-wise for delivery. You have systems like Postgrey (one of the basic spam protections for email servers) and deliberately pretends the email server is offline for emails from new servers until they server retries a set number of times.
Not to mention if your email ends up in a corporate quarantine until you can request it released.
Please, for the love of god, just let me use my username/email and password. Have the magic link for the dummies that don't use a password manager if you have to, just let me do the username + password way.
Deleted Comment
Magic links can be more like convenience links, not secure, or security.
1. Nearly every online service needs some sort of "forgot password" flow, and often times that flows boils down to what is essentially a magic link like TFA is about.
2. The vast majority of users these days use either personal email accounts from one of the big providers (Google, Yahoo, MS), or they use corporate accounts often through a hosted solution. 9 times out of 10 I'd bet the email provider has better security than whatever rinky dink website you may be creating an account on.
Emailing magic links is essentially "poor man's SSO". It makes much more sense IMO to have super secure email accounts (e.g. ideally with passkeys) and then just use magic links for everything else.
Passwords are used in one of two ways:
1. a password manager guarded by a single actual password
2. the same password repeated between services
Practically every service offers e-mail recovery, so, in practice, your e-mail is your authentication.
Personal e-mail accounts are rarely replaced, not shared, and aren't reused. You've probably had your personal e-mail longer than your phone number. I've had at least five phone numbers in the life time of my current e-mail address. Other people now have those numbers.
I'd also add that forgot password features at least notify the address owner of every attempt. Password based logins don't always email on every login from a new location.
There is always a simple answer to such question, and it's usually about some inconvenience the service provider decided to set-up for the user. In this particular case I think the answer is obvious: email provider usually have a session which never really ends, and just sits there logged in unless the browser cache is wiped.
Make your service auth token to live for the same time as Gmail's, and as an alternative give users an ability to just login with OTP every time, but stop these unholy 12 hrs time-to-live auth token practices - your users will never log-in via password restore again.
I have had troubles with Epic and Spotify accounts in the past. I make an account, I use it for a week, after a week session expires - Spotify kicks me out of my account. I try to log in, it says my password is incorrect. This is impossible, because my password is saved in my password manager. So I have no choice but to reset through email. First several times I receive the email, reset the password, the pattern repeats, after 3 or 4 repeats I don't even receive the email anymore, so I am forced to make a new account.
Currently I am logged into Spotify through my Google account, where I have zero issues so far. But if I use plain email, their auth system simply does not work.
Unfortunately, we lack the consistent language to measure risk and decide "do I really need 2FA on this site?" "Is 30 minutes a reasonable session time?". I think as long as someone has an up-to-date virus checker, most would rather stay logged in to stuff. Anyone ever been asked to delete all cookies to fix a problem on a site? My answer is always to "go fish".
I remember somebody saying before, "it's your account, if you want to stay logged in and risk a hack, it's your risk not the company running the service". I believe that more and more. If your laptop is logged in and someone deletes all your EC2 instances, that's on you, not AWS for not logging you out sooner. They could but why should they? Piss off 1M users to try and protect 1 person who is too careless?
1. Type in email address
2. Get sent and email with code
3. Enter code to login
While I can understand why someone might do this, as someone with multiple emails I kind of hate it. I had to add it to my password manager with the email and a note, so I remember which one to use and it’s not missing a password.
My theory is if you can’t make a proper login system you’re skills probably aren’t good enough to deliver on what you’re promising. Magic links have turned from an annoyance to a filter for me.
Using that logic, I wouldn't trust most websites I visit. Even FAANG companies with their billions can't do certain things properly. Even something reallly basic like focus the 2FA box when you ask for the code, don't make me have to click on it! Don't stop people pasting passwords, don't limit how long the password can be (within reason) don't say they can't use arbitrary characters like a - because "SQL Injection" and don't invent riduculous hurdles like adding random digits from a secret word as well as your password. If you are going to do that, just ask for two passwords or tell people if you choose stupid passwords, you will be hacked!
I like the password strength meter that doesn't block passwords that it has mistakenly decided are weak (20 random alpnanumerics) but instead estimates how quickly it could be hacked. People don't understand entropy but might understand "hacked in 5 minutes", they also don't want to be told that your password has to be at least 100 characters long with uppers, lowers, numbers, specials, klingon etc. If your system is that susceptible you are doing it wrong.
I do this with a B2B SaaS: an individual user would log in maybe once of twice every six months. Have passwordless logins means:
1. No added pressure on the user to remember a password for a service they use rarely.
2. Easier onboarding for companies, as they upload a CSV of all their users and their users can get to work immediately without being prompted to create a password, double-check it, confirm it, adhere to the rules, etc.
I don't like using links in emails, as they get 'clicked' by many phone apps when previewing, by corporate virus scanners, etc.
Even if I offer both options, I would guess that I’d see more drop off during my signup flow by asking for a password as well as verifying their email. Not to mention the code is way simpler without dealing with passwords and multiple login flows for email.
This isn’t where you put in a username and password, then get an email code prompt because something looks off.
In the case I’m talking about, the user has no password. This is just the way it is, VPN or not.
Why email then? Why not some other, better protocol?
Why not just use a TOTP at that point?
Not intentionally though - I have my password stored in 1Password, so I know it's correct, yet every time I try to purchase something through bestbuy.com I trip some sort of ATO protection that falsely claims my password is invalid.
I'm entirely willing to believe it's something on my side (ad blocker, local DNS blacklisting, etc.) but after a certain number of occurrances, you get bored trying to debug the problem and just follow the path of least resistance.
Are you sure it's not a maxlength mismatch? It is very common to have the "change password" field to have a different (or no) maxlength and then have the login page have a different maxlength. So you change your password to some 60 character password, then you log in where the maxlength is only 40 characters... wrong password! I actually have a policy now of having the maxlength stored in application config so it propagates to all password fields in my apps.
Edit: Just checked and yes there is a length mismatch (form to set password has maxlength of 54, but login page has no maxlength set). So if your password length is > 54 and 1Password doesn't automatically cut the password it stores to 54 characters or fewer, you won't be able to log in.
Maybe 10% of software developers actually have an intricate understanding of what they do, in fact it is because developers don’t really understand what they are doing is why regular people brute force horrible software.