The "email is authentication" pattern
rubenerd.com
rubenerd.com
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_.
Yes, this is why it is incompatible with widespread adoption. Most people do not want to do this, and in fact could not do so effectively without learning and thinking a good deal more about computers and risk scenarios, which they don’t want to do and will not do.
You are correct that it is a solution. However, it is not a solution that will ever be adopted on a wide scale.
yes, the advice about wallets is “make a backup”. the advice about passwords is “don’t reuse them”, yet the VAST majority of users use the same password for banking, email, and their phone provider. so what do you think the chances are that your average user makes a backup of their wallet AND remember where it is in three years?
pretty much zero.
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.
Even if you are referring to digital storage managed by the bank, presumably competently enough to avoid data loss, if that data is exfiltrated your wallet will be drained. It would be very difficult for a hacker to irreversibly drain your bank account (given the type and terms of the account, but will apply to most savings accounts), due to the protection and delay systems in place meant to catch fraudulent or unauthorized activity. Note that this definition of “unauthorized” actually means “not authorized by the human being who owns this account”, instead of the crypto definition of “not authorized by someone who knows the correct secret”.
Humans have been unable to recover from mistakes since day zero
Yes obviously if your money is completely burned then it's gone, but that is generally pretty unlikely to happen. Losing your digital key is many orders of magnitude more likely to happen in my opinion. And there is - by design - absolutely no way to get it back. That makes using blockchain for anything serious completely untenable in my opinion.
Digital things, not so much. I'm a professional in the field, yet I've lost digital data in the past few years. Normal users who work in other fields? Lost cause.
Which is (one reason) why most people use a bank account and don't hide their money in big bundle of cash under their pillow?
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.
What most bitcoin fans seem not to understand is that for the vast majority of people, transactions being reversible by authority figures is desirable.
Yeah, but if I lose the physical 100$ I am carrying, that doesn't prevent me from accessing the rest of my cash stored elsewhere.
I've never lost access to the rest of my cash stored elsewhere.
By geographically distributing your signing devices you improve both security and reliability. One of those keys can be hosted by a third party to be used for recovery, without providing them any ability to touch your funds without your involvement.
>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.
In reality I've found a lost wallet and helped return it to its owner. At least twice, actually. Both times because there was an identifying name in the wallet.
Then there's the time as a kid when we found $60 on the floor at a department store, and turned it over to lost&found. I remember it because the store had a policy that if cash hadn't been claimed for a month, then the person who turned it in got it. Which we did.
Maybe the issue is trying to force one solution for everyone.
Stuff like national ID, banks, ISP, job search websites, doctor appointments, etc, require[1] having an email address, and it feels wrong using gmail and similar providers for these use cases that are already tied to you having a physical presence in that location anyway.
Could be provided by any local company, really, but postal services are not going to disappear anytime soon and they already have a second way of getting in contact with you if there's any issue (registered mail[2]).
Debit cards are already delivered through postal mail anyway, and there's not many things that are more sensitive than that.
[1]: Well, maybe doctor appointments don't require and only strongly encourage, but that doesn't affect the point too much.
This has largely been replaced by videochat for ID card verification where some underpaid person walks you through holding your ID card in front of your smartphone cameras to verify that it's real, not CG, not tampered with and matches your claimed identity.
The critical aspect here is that you don't have to hand your ID card (or a picture of it) to the company that wants to know your identity. The post office or the videochat provider serves as a trusted source of truth.
Besides, the french administration is providing its own global scheme for online authentication.
Right now it works for all public services, but it is also open to all willing businesses.
It makes it also very easy to control tightly what kind of information is distributed to various services and businesses.
I personally sign up to all online services with a different email each. I would like to be sure that my identity is hidden behind an alias for all services, so that they cannot be linked together. And if i want multiple accounts (for better or worse), i should be able to achieve that end.
It’s a government in-person KYC.
Maybe we just ask for an open authentication system instead? Leave the email part to someone else… and maybe the open authentication can plug a crypto app/email/phone backend for recovery once it is setup. Heck, given that’s it’s the USPS, they will probably offer a snail-mail recovery option (for better or worse.)
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.
Quoting "Foreign citizens in Sweden blocked from BankID after several banks roll out new rules" https://www.thelocal.se/20220117/foreign-citizens-in-sweden-...
> “We have been working systematically for six months to get residence permit cards, then a personal number, then a Skatteverket national ID card, and finally bank accounts. To our shock, we were just told by ICA Banken that the Skatteverket National ID – the only one available to non-citizens – is not a valid source of identification for BankID.”
BankID causes problems because it isn't designed for the interests of the whole population. For example, it requires proprietary software which only runs on Microsoft Windows, macOS, iOS, or Android, with hardware verification and Google services.
This makes it unacceptable to free software advocates, and to privacy advocates, and to national data sovereignty advocates .. the total population of which is so small as to not affect the banks' commercial interests.
One thing I learned recently is how the US can, with its control over the SWIFT banking network, tell banks in other countries to shut down the account for a local citizen who the US has designated a terrorist. At least that's what I gather from the news I read after two leaders of the biggest neo-nazi group here in Sweden were designated as terrorists by the US.
If the goal is to keep power out of government hands, don't look to highly-regulated banks which are subject to the whims of multiple governments.
It’s been phased out for the government provided login system which is much better but not exactly simple for laypeople to set up. On top of this, integrating with it requires an extensive certification process, it’s not just an open API.
Oh man, that sounds like a terrible idea privacy wise. Every website would make use of it to track it's user.
How it works under the hood? No specific idea. I wonder if its sound.
A centralized authentication system like this wouldn't need to be a single consistent UUID per person which was then passed around. Presumably you'd have a central login to authenticate you to the system, and then the system could create separate 'id' tokens per web site or whatever that the user logs in to.
Not so much in the US though. They have no national registry of what citizens actually exist.
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.
> 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...
Sadly it's quite possible this will be a dramatized version of a real-world event. We've already seen quite a few messed up crimes to steal keys to steal crypto. Secret sharing just means you need to kidnap a few extra people.
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.
Enterprise TOTP apps like Okta and MS Authenticator have some enhancements. Push notifications are convenient when you have to access things many times a day. More importantly, push notifications with a number-matching confirmation reduces the chance of TOTP poaching, since the user themselves are interacting with the service requiring auth.
In enterprise environments, there should be a restore process for a lost phone or authenticator. Some kind of backup code with voice/manager approval, or coming into a physical office to reset credentials. This isn't available for regular people/regular retail services except maybe banks, but banks can't even do regular TOTP correctly.
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.
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.
Of course if someone is memorizing the TOTP seed and generating the proof on the fly every time, then there's no shift in factor, but no one is doing that. And if they're saving the password on the same device that stores the TOTP code, then we're back to one factor, but now it's just 2x "something you have" at that point.
That's reductionist way past the point of being a useful model of authentication factors.
By that logic, even biometric factors are "something you know", as you can always (with a lot of effort) physically replicate a fingerprint/retina/genome you have a sufficiently high fidelity recording of.
All the things around improving web authentication are just about people not having to memorize that something you know and protecting it against eavesdroppers.
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.
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.
SIMs and SIM burners can be purchased trivially on the open market, and cloned without too much difficulty. Although, a social engineering attack on the employee at the cellphone store is a superior method since it automatically gives you a "known good" SIM with the operator's keys, etc.
While there are weaknesses, every mobile phone standard since GSM (not sure about the equivalent for the CDMA world) uses cryptographic authentication, many of which have been subsequently broken, but it's just not true that simple knowledge of a bearer token, transmitted over the air interface, grants you sufficient access to receive somebody else's SMS.
Most practical attacks actually focus on either attacking the core network via SS7 (and making it deliver SMS to the attacker instead of the actual recipient) or on breaking the air interface encryption, which requires you to be physically close to the legitimate recipient while they receive the SMS over the air.
You can change your IMEI to mine right now, and absolutely nothing would happen (other than maybe our phone operator getting mildly confused, if we share one and they're tracking IMEIs for whatever reason).
SMS are as secure as a letter compared to a postcard.
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.
Personally, I appreciate getting an email with details and a link for tracking. It does get annoying when it turns into low-grade spam, though.
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.
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.
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.
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.
A) Go to website, click through a password manager to copy and paste an arbitrary string of characters, receive TOTP request sent to your email to confirm your identity.
Or
B) Go to website, click forgot my password. Receive link to login. Enter an arbitrary string of characters.
In many instances, login flow B is actually quicker and seldom slower.
Clicking the “remember me” checkbox has no effect.
Here’s my workflow, and I consider it superior to both of the above.
Go to site, Safari offers to autofill, give TouchID/FaceID, get asked for a 2 factor code.
Sent via SMS/email? Safari offers to autofill for me. TOTP style? Safari offers to autofill for me.
Easy peasy.
Passkeys are even easier as there is no second step and waiting for SMS/email.
> In many instances, login flow B is actually quicker and seldom slower.
And B) can be accessed whereever I have email and doesn't need either an app or my phone which may or may not be on my person.
Personally, I hate it. I don't trust my email, hate that it's a single point of failure for dozens of accounts (it's not "2FA" if the second factor is the only one I need), and I'd prefer to log in with a password without any option to reset it. But alas.
It will be 2FA again if you protect your email with 2FA
It’s more secure than a) reusing an existing password everywhere and b) setting a trivial password that _just_ passes the site’s password requirements.
You can’t expect me to memorize all passwords for all different logins, especially the ones for less important sites, and especially if these sites impose their ridiculous password restrictions on me.
Doesn’t this answer the question? I would have preferred to read and discuss what they believe to be better alternatives.
See, thoughts like that turn into billion dollar valuations at Series B for, among other things, a login button that emails you a login link, taking advantage of people's tendencies towards behavior like this:
https://stytch.com/products/email-magic-links
https://stytch.com/blog/announcing-series-b/
(Or maybe turn into Tell HN posts on common SaaS vulns, like https://news.ycombinator.com/item?id=33162854, but point is lots of companies offer this including most SaaS-y IdPs, search: passwordless email magic link, it's not new: https://auth0.com/blog/auth0-passwordless-email-authenticati... ...)
Is that a storytelling touch? Users aren’t dumb or unreflective, they know that they have nowhere to store their passwords, that’s why. Even if they aware of password managers, they can work on a shared cloud pc, so switching PM accounts would be a bigger hassle.
How do you decide that using “I forgot my password” as authentication makes sense to you?
A “trash caregory” site that didn’t bother to tag its username/password/etc elements as password-saveable, thus my PM didn’t ask to save the password. That is usually enough to not give af about saving it. Happens more often than you might think.
That sounds insane, is that actually happening in practice? What is the point?
An email ties a user to a domain, the domain issues a user for them. If too many users from a domain are malicious, the website can block the domain.
It's a matter of identity and accountability.
And then the unsubscribe, close account, or basic support is all locked behind the login, or it's an international phone call. As far as I know, even if it's my email it's not legally my account so signing in would be illegal.
Except when the service throws you back to the login page to authenticate with a fresh password you just typed in the reset form.
For the rest you can do weird stuff that doesn't work on nerds.
I hate when people suggest that there is something insecure about using the password reset feature. Whether I chose to use it to get into my account without a password has no impact on the security of the account. The mere presence of this feature is what’s determining the security of my account.
Similarly, some services I use prompt me to verify via SMS or Email after I input the password, but oddly imply that using SMS is more secure than email. Makes no sense to me since either way the OTP should only be usable on this one session, and even if one is a less secure channel, it’s the presence of the weaker option in the first place that’s the problem, not the choice made by the user.
You’re supposed to not reuse passwords, but then you don’t remember passwords.
So you use a password manager. Until more recently when phones and computers came with built-in password managers, no normal person was going to download a password manager.
But even when you use a password manager, sometimes it doesn’t recognize the form fields. Or it doesn’t show it because the domain is different. Sometimes it doesn’t save a new login. The website has no direct awareness of the password manager so it’s hit and miss.
So we created passkeys. Except it’s also hit and miss. Some sites only sometimes ask for them. No site explains what they are. Some sites ask for you to login with a passkey, which you wouldn’t have yet, but then don’t ask you to setup the passkey after logging in with a password, so you never set up a passkey.
Overall authentication is a disaster and my very fiery take is overly technical people who are out of touch with normal people design authentication.
That said, if folks are going to adopt this as a primary flow, perhaps email clients need to build in support. For OS providers like Apple, maybe this means less emphasis on the easy Passkey method and more on fixing the finicky email login flow that sites use instead?
What would a good email login flow look like? What is the "password manager" equivalent in a magic link world? On something like iOS or MacOS with Safari, could the browser/app & email client communicate to make the login seamless (after the email delay)?
Are new OS-level APIs needed for native apps such that they don't require switching apps to login? (This is a truly awful workflow.)
Should sites stop making people register with passwords at all? What is the point of passwords when auth is primarily handled through magic links?
I remember having seen this idea at other places before. I don't really like it, because for me, using a password manager makes everything already quite convenient.
How many people do you think use password managers? 1 in a 100? 1 in a thousand? Looking at the user counts for all the major password managers combined, the number looks more like 1 in a few dozen million.
We're a demographic that is smaller than the demographic of blind users. As a group, we're not even a rounding error. It makes no sense to optimise our group's workflow when the resources could be diverted towards making a better product.
After all, it's not like they lock out password-manager users completely.
The most annoying sites require you to confirm your throwaway password or log in again using it, and can't copy from the password field, so you can't just spam the keyboard and have to type it into notepad then copy and paste a few times before discarding it. This is stupidly inconvenient to do all the time but the alternative is more inconvenient to do once - researching which password manager is currently safe, finding it, installing it, writing down your master password somewhere really safe, etc. Then keeping on top of the news for the rest of your life to see if your password manager is going down the gurgler or been hacked. Also, will my passwords be available when I travel to a country with restricted internet? Who knows. Can I export my passwords to any other password manager or a text file if I need migrate? That's part of the research needed to even get started using a password manager.
I do this because I don't care enough about the particular account or use it frequently enough to manage put more effort into it.
My mother used to do that, until I teach her about bitwarden and it has completely changed her thought process. It's just that having to remember every password is impossible and they don't know about password manager.
First of all, 'real' people do not use password managers, and they feel a slight suspicion towards the browser 'remember password' dialog so rhey decline.
They also have some boomer uncle that told them 'never to write down passwords' for the days where people post-it them to the monitor in shared office spaces.
They also know 'not to reuse passwords' because if one site gets powned your password for everything is out there.
So they develop a heuristic for mutating their 'master' password depending on the site or app, only to get thwarted by insane (not an exaggeration) password requirement rules.
So they have to deviate from their heuristic, and will not remember the password they had to make up on the spot next time around, so a reset password email it is.
Bonus: they make up a new password, omly to be informed they can not reuse a previously used password. XD
Because of the developers of these apps assuming that E-mail guarantees instant delivery (it doesn't), I can't use greylisting, which reduced spam very significantly.
Quite silly, yes. At the same time, I do think this scenario can represent a possibility when people need to rely on only one way to authenticate their entry. That is really frustrating when you make dumb thing under this circumstance.
We do have a list of customer email addresses already linked to the information they can view - if they enter their email address and it's in the list they get a link that will log them in for 12 hours and can see their associated data. If their email address isn't registered they're told to speak with their sales rep.
This of course trusts that email accounts are the highest level of security a user has, which it should be because so much relies on it these days.
Isn't that what some services are doing already? There is no password in Notion, you just enter your email and the password is sent to your email address.
Login with Email is like a primitive "Login with Google" where the user himself transfer the authentication token. It's still better in one area: no lockdown to a particular cloud provider. However, it doesn't address security, it just concentrate it in one place. Lose your email and now you have a much bigger problem.
In fact, I just made a release last night, to try ensuring that we reduce the number of bad emails (I thought I could get away with eschewing the traditional “confirm email” thing —I was wrong. There’s a reason the classics are popular).
Since it is an iOS app, I can implement Sign in/up with Apple, which helps a lot.
It’s still a work in progress, though. I use the Keychain to store login info, with Face/Touch ID, to smooth the login process. Works fairly well.
There is a tiny link at the bottom that allows you to sign with a password, which I prefer.
From a perspective of one of these people, why even bother with trying to remembering a login or dealing with tools you don't have, like if you don't even have a password manager or know that they exist.
From a systems and security perspective, it could be worse. They could be reusing passwords.
Unless you're in Germany using a service provided by the Vogons, you might end up getting a letter containing an activation PIN via snail mail or worst having to visit the post office to show your passport.
Double factor improved a bit this, or at least made it harder to break into this to some of the players, and simplified the process for some others.
The point is that they are already tied together because most sites allow password reset (or account recovery) via email.
It doesn't matter how securely your sign-on is designed, what identification token you are using (username, biometrics), what authentication mechanism is in place (passwords, MFA, yubikey, etc) if all an attacker has to do is type in the targets email and click 'forgot password'.
If your site allows password resets or account recovery via email, then the users account is still only as secure as their email password anyway. Adding yubikeys, MFA, authenticator apps, etc into the mix doesn't move the security needle a single bit at all.
It's because that's simply the most convenient way of accessing the service. There are tens of services people use these days and passwords are seen as a nuisance. If there's an easier way of logging in, people will use it - no matter the security implications.
Basically something like this:
1. Website generates random string as challenge, sends to Browser, invokes API via JS on the client side.
2. Browser asks user to select the email to use, allows adding a new one.
3. Browser sends its auth token and challenge string to Browser Maker, Browser Maker verifies that the auth string is valid, signs email address and challenge with its public key, transmits signature back to Browser.
4. Browser sends data back to Website, Website verifies that the signature matches and that Vendor is trusted, lets user in.
As an extra precaution against Vendor being hacked, Email providers could implement support for the system. Compliant providers would handle the email verification flow themselves, informing Browser maker when done and sending an extra certificate. Websites would then refuse to accept any logins where Email Provider indicated support (via DNS records) but its certificate wasn't included.
This would also make the system usable in small (and therefore untrusted) browsers, as long as the email provider implemented support.
It would even improve privacy, Browser Maker and Email Provider would only ever see the random challenge string, which would make it impossible to track the websites you visit.
THe idea isn't hard to implement, we've had the tech to do it since the 90's (US restrictions on crypto notwithstanding). What we have instead is a mess of passwords that nobody can remember and proprietary authentication flows with horrible developer experience, terrible privacy issues and spotty website support.
1. Enter phone number to received a six digits code 2. Enter the code
Facebook supported this for years, not sure why they recently deprecated it.
its the go to pattern because its the most resilient and intuitive
we've been using emails for a long time and it makes sense that it became the go to authentication method
And if people really want to enable password recovery then they add their email into their profile and that data point is only used for that.
It might bother some, but I don't really want to require emails for privacy related services. My two cents.
As a user, I hate it.
Make Auth Gmail’s problem.
It’s not a horrible idea in theory.
Look at the physical world analogue. If you lose a house key, you can force the lock, break down the door, re-key the door, pick the lock, or any number of other means of re-gaining access, up to and including going through the wall / ceiling / floor.
If you lose an authentication key, you're S.O.L.
It cannot be more secure to store it in a password manager than not to store it at all. The email recovery path exists in either case, so that part is a wash.
I will share this great innovation of mine:
The location.hash is not send to the server. You can javascript it into a POST rather than a GET.
First, about using the "Lost password", saying “huh, I never thought about why” is an easy way out with not much of a research from the author (sorry). One of the main reason people do that is because websites are enforcing dumb rules for a password that user tend to repeat on every websites (Your password must be 16 chars long, with lower and upper case, numbers and special characters. No more than 2 identical characters in a row ... yes ... I'm looking at you Twilio.com). Of course in that scenario I'll hit my keyboard in a random way and never login using my password.
But this article leads to the alternative; login via email. Some HNers here have mentioned having implemented that on their website, either by sending a one-time login link, or a verification code by email. We did that too for ImprovMX.com initially, and it has a lot of advantages (no password, no password-lost flow, no security measures for storing the password, etc). But it turns out it also have quite a few downside that we haven't thought about:
1. Emails get lost. We had quite a few support request because users couldn't connect to our service because the login email never arrived. This is a major issue, mainly when user wanted to upgrade but couldn't because of that. If you decide to implement this, you must use a really good email provider (Postmark is really good. Mailgun, not so much) 2. Emails are async. When your user goes to your website, they want to connect now. Waiting for an email can take quite some time and they might loose focus 3. Security "measures" will tell you to not indicate if the email you entered is valid or not, to avoid listing your users (... I won't go in that); If you implement login by email, it means your user will enter their supposed email, you'll tell them something like "If your email is registered on our website, you'll receive a one time login link", wait what feels like an eternity to get the login email in their inbox, and at some point wonder if the email they entered was the right one. Will try another, wait, rince and repeat.
So yeah, relying on email move all the security issues and added workflow back to a trusted service (login/lost password/2FA/OTP/etc to services like Gmail) but it will definitely add friction too.
In the end, it depends on what service you offer.
(Prescribed Conditions)
- "Credential Recovery" complies with OWASP ASVS and is "adequately secure".
- "Credential Recovery" is the "weakest link" of authentication. (Other authentication methods require TOTP, etc.)
(Potential Problems)
- The financial cost of sending emails.
- my guess is that, since I could not find of news of this issue,
these users are only a small percentage (hopeful not yet)
- my guess is that users who choose "Credential Recovery"
authentication over other "happy-path" authentication are willing
to wait, or are use to waiting.
- If the above conditions are specified, authentication security is not compromised.
(Terms)
- "Credential Recovery" as in OWASP ASVS V2.5 Credential Recovery, or "Self-service password reset" as in Wikipedia, or "forgot password" flow.
https://en.wikipedia.org/w/index.php?title=Self-service_pass... https://owasp.org/www-project-application-security-verificat... https://github.com/OWASP/ASVS/raw/v4.0.3/4.0/OWASP%20Applica...
- "adequately secure" as in NIST SP 800-160 Vol. 1 Rev. 1, 3. System Security Concepts, 3.2. The Concept of an Adequately Secure System.
https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
Another great side effect is that your backend doesn’t have to store user passwords which means removal of a lot of compliance headaches.