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_.
> 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.
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, and I think that's not because they don't want to do it but because:
1) they don't know that they should do this;
2) they don't know why should they do this;
2) they don't know how to do this;
3) because even the systems marketed as current state-of-art (Passkeys) are poorly designed and don't even allow to have proper 3-2-1 backups conveniently (can't enroll a device sitting in a safe, it must be physically brought online which beats the whole point of offsite backups).
Design it to make backups and failover secure yet easy, available out-of-box, and explicitly recommending best practices to follow - and everyone will do it as a no-brainer, at least for anything they care about.
Until recently no one told people to not reuse passwords. Even today most password-based signup forms just ask for password and maybe tell the requirements (length, characters) but extremely rarely they explain anything about uniqueness, randomness or anything else. No surprise it sucks hard in practice, when nearly everyone ignores the education aspect.
People aren't stupid. At least in general. They're just blissfully unaware about a lot of things, especially the older generations. What is impossible in real world is designing a fantasy football nanny authentication system to "safeguard" them, without making a lot of undesirable sacrifices. We manage to explain people to not poke with scissors into electrical outlets (and make it hard to do so accidentally) - we can manage similar stuff with computers too.
> We manage to explain people to not poke with scissors into electrical outlets (and make it hard to do so accidentally) - we can manage similar stuff with computers too.
I don't think this is a good analogy, because the example is simply warning people of a thing not to do. It takes no effort. Maintaining backups does take effort. This is more like getting people to pick up a new chore, just like how many people see interacting with their bank and financial services as a chore.
Many people who work in IT (or are into computers as a hobby) discount the effort it takes, because there is a lot less friction between them and computers than for the average person.
> even the systems marketed as current state-of-art (Passkeys) are poorly designed and don't even allow to have proper 3-2-1 backups conveniently (can't enroll a device sitting in a safe, it must be physically brought online which beats the whole point of offsite backups).
Design it to make backups and failover secure yet easy, available out-of-box, and explicitly recommending best practices to follow - and everyone will do it as a no-brainer, at least for anything they care about.
People have been saying this for a long time. "We just need a better system!" The system doesn't exist because people don't want a system that requires effort. It requires effort to protect a secret that, if leaked or lost, would irreversibly result in your financial ruin. It requires a lot less ongoing effort (to a non computer savvy person) to use financial institutions to store their money securely.
People will choose the system that safeguards them and makes sacrifices that many computer security and freedom oriented people will find undesirable. This is demonstrated by the choices that people have repeatedly made.
People's bank accounts are irreversibly hacked, emptied, frozen, seized, blocked, impounded, garnished on a daily basis. That you haven't encountered it yet, doesn't mean it's not happening.
People should have a choice which system suits them more.
I strongly disagree, but I feel that the conversation would be pointless fight of beliefs, unless I actually design and showcase a solution that would be simple yet secure (and I don't want anything that takes effort) - but that will take me a while to work on.
The idea is that user shouldn't have any friction, besides meeting minimal requirements: 1) being capable of reading (or otherwise accessing the text) and comprehending simple instructions; and 2) having certain minimally required hardware or software installed.
I'm sure this is doable and every primitive to build this already exists and vetted by competent people. I'm sure it's possible for a layman non-technical person with normal cognitive capabilities to have a safe authentication solution (which is very different from data backups) with full ownership of their identities and credentials.
Sure there are people that cannot read or cannot comprehend things. A lot of people. I've seen way too many folks who had simple and clear ELI5-grade instructions with zero technical jargon - and nonetheless had failed to follow them because "computers hard". In some case it's the fault of UI or UX, but I strongly believe in most cases it's just learned helplessness - "computers are not my thing and they're hard" and brain shuts off instead of even trying to read. The only solutions are to 1) make them actually interested in achieving their goals (worked for my dad - man went from "I don't know and don't understand [and 'I don't want to' in the tone], order this for me" to suddenly figuring it all out and placing online orders in just a few minutes as soon as he actually needed something when I wasn't around to help), and 2) make sure they have all materials accessible, well structured and covering as many possible scenarios as possible so it's all there the moment they snap out of their learned helplessness. Nothing else works as it is fundamentally impossible to design anything that would work even if people don't read and don't think.
I have some sketches in my mind, specifically focusing on use by laypeople without making compromises about fundamentals (like what is identity - a lot of modern auth perverts this concept badly). I'll give it a try someday, actually drawing it all and writing notes on the inner workings. Wish there'd be a ten of me and we'd have 240 hours a day... Sorry.
> This is demonstrated by the choices that people have repeatedly made.
I'm afraid this is a very bad attitude to follow. The choices people had repeatedly made got us in quite a bad place. Just look at the poster child - IoT - it's a complete disaster. Online auth is in a very similar poor and messed up state, it just less visible.
I think we may be passing as ships in the night a little bit - that is, I thought we were talking about cryptocurrency wallets, and the merits of a system with authentication relying entirely on cryptographic secrets.
I wish you luck in your development of such a system. I don't disagree with anything you said about learned helplessness, and I think it can be fruitful to push individuals or groups to overcome it, but I think trying to do that to the general populace is like trying to change the wind.
Not reusing passwords at all is pretty impractical. If you really want to depend on a single password manager then you have some other issues. Usually I have settled for rotating, compartmentalized password modules which allows me to somewhat rather than fully contain a compromised password. And if your modular password has three slots (term taken from linguistics) then you can compose passwords which reuse parts, are memorizable, and not automatically reusable on other services.
The problem though is that since one has a number of passwords which may be different but closely related, a human may be able to infer a few possible passwords from a few compromised ones. In other words it still dramatically shrinks the key space an attacker might want to try to brute force. Preventing re-use is then a problem for 2fa regimes.
For my part I won't use passwords I cannot memorize and keep memorized in relation to the web site.
i think you’re sidestepping the parent’s point: if it depends on users doing the right thing every time, it’s not compatible with the real world.
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?
How many forms of backup survive "the government threw you in prison for years?" Even Gmail will refuse to authenticate a correct password with "we couldn't verify it was you" if you never binded your account to a phone and just got out of prison 3 years later.
Uh, well, in context of crypto - your (self-owned) crypto wallet totally would work.
As for email... Sure, I guess it depends on the service and their policies. But here's an anecdote. A few years ago, I've managed to log in in to a completely forgotten 10+ years old email account, finding its password in an old backup. It worked. ¯\(ツ)/¯
If an user cannot log in with a valid credentials, without brute-forcing them, after some years of absence, it's absolutely the service's fault. Of course, in the modern world, customer issues mean nothing so anything goes. But -quoting GP post - when designing a "fantasy football" alternate authentication system for the Internet, this probably shouldn't be a thing.
> 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.
Are you referring to a physical lockbox? Because if so, that is certainly not as secure as your bank account, because criminals could not drain your bank account by breaking into a bank, nor could your account’s funds be lost if the physical location were destroyed by a flood or other disaster.
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”.
"Mom, I already told you: you have to generate a key pair, split the private key into three parts using Shamir' secret sharing algorithm, then give each part to three banks. Whenever you want to use it, you have to go collect it from each of those banks---but DON'T write it down anywhere---and perform your transaction"
And to think the conversation started with an observation that people can't even remember one password.
I agree, there's miles of runway remaining for improving the UX. I actually think it'd be neat if a crypto had this (and a few other things) as a baked-in feature. i.e. In order to create a wallet in the first place, you need to identify e.g. 5 trusted friends who'll serve as recovery partners. Maybe it's initially tied to the same invite mechanic used to join the ecosystem. Could be done in a privacy-preserving (and to some degree anonymity-preserving) fashion. The right UI could make this even simpler than recovering a Gmail account. Everyone would just have it set up, and these conversations about losing your keys would be a relic of the past.
I don't understand why this was downvoted. In case it's not clear: (S)he's saying to split the key into multiple shares that can be used to reconstruct the key if you have a large enough quorum. Then store each share in a different place. As long as you don't lose too many of the shares, you'll be fine. And one baddie is NOT enough to get the key.
Either shuffling those keys stored in N different deposit boxes is overly complicated for a normal person, or it is not overly complicated for a moderately dedicated baddie either
Unless the "baddie" in this case is the government, why would it be easy for anyone to obtain access to multiple secrets stored in multiple boxes/banks?
Multisig is a pretty common setup for crypto and there is software that makes it easier.
"soerxpso" said "store your key at the bank", but you are saying "two or N places". So it sounds like 1 bank is less secure for your key then 1 bank is for your money, because you need two or more banks for your key, while 1 bank for your money is sufficient. Correct?
I stay away from everything crypto but I don't see the difference. In both cases if they didn't make it right you'd go to the courts and make your case that they are at fault and owe you compensation.
They're just different things. The FDIC insurance is for if the bank itself goes insolvent and they literally don't have enough money to cover their depositors' balances anymore. There's no reason a safe deposit box would be affected.
Yes, they are different things. A safe deposit box wouldn't be affected by the banks insolvency.
A safe deposit box may be affected by other things and if those things happen they don't have to "make it right", if you go to the courts and make your case you may find that they are not at fault and you are not owed any compensation.
Probably varies from bank to bank, but in my experience you have to specifically buy separate insurance if you want the content of your deposit box insured. The big problem from the bank's point of view is that, unlike your bank account, the bank doesn't know what you have in the box and thus has no idea what to insure it for and no way to verify any claim.
More importantly the bank doesn't profit more from something more valuable being in your safety deposit box so it doesn't make economic sense for them to be the one insuring it.
I might be mistaken, but are not several "traditional" banks offering crypto wallets for customers? Is there a realistic chance this kind of bank is going to steal their customers' crypto and going (at least, next to criminal investigations) bankrupt over it?
Sure, they could. Would that be any different from how a bank could steal funds from a traditional deposit account?
By making a bank the custodian of your crypto wallet, you're placing your trust in them and should have similar legal recourse you would have had with a fiat deposit.
I am not sure if you are objecting. Definitely you need to trust your bank if you are going store your crypto with them. I just do not see any large traditional bank stealing their customers' crypto and hoping to get away with it.
As far as I know all the cases of stolen crypto have been newly founded companies with their only business being your crypto. That is quite unlike the other kind of bank.
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.
It doesn't need to be completely burned to be gone:
"No redemption will be made when (...) Fragments and remnants presented which represent 50% or less of a note are identifiable as United States currency but the method of destruction and supporting evidence do not satisfy the Treasury that the missing portion has been totally destroyed"
For at least 12,000 years, humans have been getting very good at holding on to physical things.
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.
Accidentally burning money is a very low probably event. Forgetting passwords or any type of memorized secret is the most likely default outcome, and chance only increases with time passing.
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.
Yes and people quickly realized that there is an amount they don’t want to carry around. No one carries their life savings and few would even keep it in a safe in their house.
Yes, by evolving banks to solve some of the problems of lugging around lots of cash and/or stuffing it in a trunk in your house. And assuming you are known at your bank and/or can (eventually) prove your identity there, you don't have the same "lost wallet" problem being discussed here.
Money occupies physical space, so for most of history there was a pretty low cap on how much you could bring with you at once, which placed a cap on how much a single mistake could cost you.
Currency was traditionally made of precious metals which often gave them a rather high starting point of value. It also made them inflation resistant meaning the real value only grew over time. For instance in the Roman Empire an aureus [1] was worth 25 denarii (prior to inflation) and was about 2cm in size, so roughly the same size as a dime, made of pure gold. And a denarius was worth about a day's wages. So you could comfortably hold decades of wages in a small coin purse. And as inflation ravaged the Empire a single aureus gradually came to be worth thousands of denarii.
This is what transit payment cards in Japan at least do, you can tap to pay most places but there’s a cap of 20k yen you can add to your card, so there’s a cap to how much you can lose.
I love how these cards work in Japan. There’s a bunch of different operators but they all work across the country – for example, if you buy a KITACA in Sapporo, you can use it in Tokyo and Osaka and anywhere else. And of course you can use them in a bunch of places, from all the transit options to vending machines and coin lockers on stations to konbini everywhere and even some restaurants.
At which point I gained the problem of having to keep track of all of my microwallets securely, hopefully in a way that survives my phone being lost, a house fire, or my untimely death, leaving the wealth to inheritors. All while, at the same time, not ending up behind a single key that has access to all the information to those micro wallets.
Quickly you end up in a situation that either starts to look like how financial companies keep their most high risk keys, or end up outsourcing the whole thing to something that quickly starts to resemble your bank.
So ultimately it's just like cash: Fine for small amounts. Risky, but maybe livable for somewhat larger accounts, or a giant headache that will probably bite you when you start looking at lifetime savings.
For the system yes, a dropped coin eventually reenters the market and a burned bill can be reprinted again. Can't say the same about a crypto wallet. For an individual though, in both cases, a lost wallet is a lost wallet.
While an interesting difference to study, the average person is not going to care about the former case. They just don't want to keep their life savings in an asset as easy to loose as their pocket money.
If you drop your wallet in a bar, there's a chance you can recover it by returning to the bar and searching for it, by the bartender or a patron returning it to you based on the address or a number in your wallet, etc. Physical money really is not the same, even for the individual.
A $1 note being a macro scale physical object enjoys a variety of benefits such as object permanence which provide a baseline level of recoverability. Whereas a wallet key l, being a number, enjoys no such protections.
Of course you may choose to encode your wallet key on paper, metal, or stone granting it properties not unlike a note. However you have now compromised the security of your wallet as well it becomes no mere $1 note, rather it is a note that represents all or a significant fraction of your net worth.
There's no fundamental property of the monetary system that prevents transfers of arbitrary value across international borders. There's just a large number of financial regulators, border guards, etc. who will throw you in jail if you carry a big block of gold across the border or accept a large wire transfer without filling out the necessary forms. In many countries, the laws governing those forms don't yet apply to cryptocurrencies, but I'm skeptical it will remain that way forever.
That's true, and the AML laws for crypto are already becoming more strict, especially in Europe. But in practice, it will be much easier to evade those laws than it is with fiat transfers or moving physical cash/gold.
And the notion of credit has been a thing even longer than both money and banks. You don't need to carry money around for every little transaction if people know you're good for it someday in the the future.
Don't you need an idea of credit for money to work at all? You need to be able to trust that the shiny rock you give me today for my wheat will be worth anything tomorrow when I want some of your meat.
Yeah and it sucked which is why we invented better solutions.
What most bitcoin fans seem not to understand is that for the vast majority of people, transactions being reversible by authority figures is desirable.
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.
Maybe the key bank could hold your digital money as well. Then we wouldn’t need a blockchain and your transactions could be instant, free, private and reversible.
This is the same problem that you run into with secret zero and commonly discussed in context of HashiCorp Vault. At some point you need to store the unlock keys then you need another repository under RBAC to protect that repository. They say to print out the keys and store them offline on paper but how many own a Class 5 safe ?
> These safes are certified for classified use and they are safe.
The website says "10 minutes against forced entry". That's not safe.
No safe is safe against a state level actor. No safe is safe against "hit you with a crowbar until you open the safe".
Whatever secrets you have, it's better to hide them than to put them in such a conspicuous place. The only reason one should use a safe is as a plausible decoy...
Yea but you have multiple pieces of the secret to restart your Vault instance. Now you need to go to everyone’s office or home to get this secret to restore it.
I am referring to Shamir algorithm that Vault uses
Collaborative custody multisig providers have been in business for years. Recently even Block (CashApp etc) has introduced a product with this feature.
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.
>> 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.
Currency in the real world has many, many backups. For example, if I forgot the PIN number to a very old bank account that I later find a long lost relative recently put hundreds of thousands of dollars into when they passed away, I have other avenues to recover access. They might be annoying or require work (getting an affidavit, multiple forms of ID, etc) but it's not irrevocable in the way that a strict definition of bitcoin is.
It's a lot harder for the average person to lose 1 million dollars in cash than in Bitcoin because humans naturally understand the exchange of physical objects.
If I have a duffel bag of money, it is obvious that physical possession of the bills means I can access its value. Anything negating that possession would cost me my money. I should probably keep it away from open flames and water; but it's not going to spontaneously combust. A thief would need to physically take the money in the duffel bag for me to lose the value.
Meanwhile if I store Bitcoin on a USB drive the drive might randomly fail and I lose all my money (because I'm actually storing a key to access it) even though I still have the USB stick. The solution is to back up my key in multiple places simultaneously, which doesn't make sense to most people (how can money be in two places at once?)
If I plug the USB stick into the wrong computer, someone can steal all my money (because they can find out what the key is) without me ever losing the USB stick.
Virtually every human on Earth understands the notions of object permanence and that objects can be exchanged for other objects. This is intuitive from evolution and actual monkeys can comprehend physical currency.[1] I don't see how cryptocurrency can be on that level.
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.
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.
The issue in not trying to force one solution for everyone becomes a blocker when you intend on making some technology useful and essential to everyone, hence, no one seriously gives a damn about crypto anymore.
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.
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.
Germany has PostIdent: you are issued a code, take it to the closest post office, hand them the code (originally this involved printouts) and your ID card and they scan your ID card and enter it into their system where the issuer of the code can then request that info to verify your identity.
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.
Initially when I moved to Germany I thought it was a bit of a hassle to have to go to the post office for PostIdent; now I actually miss the elegance and privacy of that system in other countries.
The french postal services does that and includes a digital wallet and cloud repository.for instance, my paycheck certificates are delivered on this wallet.
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 don't want a semi-gov't authorized service like this. Because its existence means services would want to mandate it (even if they don't truly need it), and force users to identify themselves directly - may be even across services (by matching their email address, which now must be unique as it is identity-linked).
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.
Australia is working on zero knowledge proof. The end service only knows that you are legit/of age/etc (only what it needs) because gov service confirmed it, but does not know who you are
No, thank you. I don't want anybody with a fake ID of me to be able to take control of my email. I want to use my password, I want it strongly encrypted at rest, and I want to be able to reset it remotely any time of day, without waiting for the USPS office to open.
Is a fake ID going to fly at the post office, where they can scan them? Also, I was imagining they'd want more than just an ID.
edit: Also also, they have to go into a physical post office and be observed trying to steal your account.
Given how it's quite possible to steal accounts via social engineering, this seems like an improvement in security, not a reduction.
I don't want a government entity, or really any entity I'm not paying directly for their services, to be the gatekeeper between me and my accounts.
The social engineering attack surface of my account currently consists of a handful of support contacts at my ISP, who have been trained to deal with computer security. If you allow any USPS employee to access your account, you've suddenly increased the potential attack surface by several orders of magnitude.
(1) Your USPS-provided email should neither be mandatory nor the only acceptable email. It could be an extra convenience, and a low-friction way to get a reasonably secure email for first-time / technically unsavvy users.
(2) An entity you're directly paying to may go out of business, sometimes due to circumstances beyond their control. At least state-sponsored entities don't do it so abruptly in most of the "civilized world".
The account recovery process for commercial email providers usually involves you photographing your ID. Presumably the post office, in person, would be far less likely to be fooled.
Everyone should experience this at least once - it’s eye opening.
I did it involuntarily because I forgot my wallet once, and decided “well, I’ll either get through and in my way, or I’m too late to drive home anyway and will miss” - and it worked fine.
Even crossed back into the USA without my passport a few times. Just additional screening and bitching is all (at least if you’re a US citizen; membership in the Empire has its perks!).
I might have been being more simplistic than I needed to be, because there are other travel methods, but I was more meaning, "Not everyone lives next door to an international hub" (so might need a connecting domestic flight).
I’m not sure I trust USPS to get all of the ins/outs of email spam/security/ux right. Google has spent a lot of resources to get Gmail to where it is today, starting from scratch (or OSS) seems like a big ask.
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.)
> 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.
These things can be solved too, but in a more complicated process. Typically some lawyers and a judge need to get involved, get some people to testify that you are this same person, and you will be issued new 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.
What I had in mind was more like randomly generated addresses as needed, all of them linked to your (one) mailbox. Like Apple's "Hide My Email", but without needing a "main"/"canonical" email address because it would be unnecessary anyway (because you would be logging in to your mailbox with your own certificate).
But even if that single-address limitation were the case, the kind of places I would give it to already require knowing my national ID number anyway, so the two particular things you mention are already the status quo.
In other words, stuff that is already tied to having a verifiable citizenship.
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.
One flaw is I'm pretty sure a lot gmail account is lost forever. Contacting Google to retrieve access would not go well. Related is that if you try to self host email your messages are unlikely to reach anyone.
Self-hosting inbound email is trivial. Anybody will send email to any random domain, they're just not willing to accept it from random sources.
And the latter is what is relevant for password recovery.
I self-host inbound but use established servers for outbound through my ISP and have had no trouble with that setup for a while. Forwarding to people through my domain has gotten a bit more challenging lately but I've got it working well enough to satisfy gmail so far. (The advantage with forwarding is you only have to convince one server to accept it, not everyone in the world, and there's some crypto stuff involved now that involves trusting some keys, not just a domain or IP, which also helps a lot.)
>Self-hosting inbound email is trivial. Anybody will send email to any random domain, they're just not willing to accept it from random sources.
That is simply not true. I have self-hosted email service and starting about 1.5 yr ago some big email services don't deliver emails to my server anymore. And there are many similar cases reported...
So one can say that even if an independent email service is willing to accept email traffic from any sender it does not guarantee that customers of all other services can have delivered their emails to addresses at the service.
That seems a great compromise. I hadn't registered the distinction in direction. Even without organising the forwarding part there are plenty of organisations that email me password resets that I don't need to send email out to.
> Self-hosting inbound email is trivial. Anybody will send email to any random domain, they're just not willing to accept it from random sources.
In terms of authentication, this is not entirely true. It's less common these days, but I used to have a lot of trouble with sites rejecting my attempts to create accounts with e-mail addresses from my disposable-e-mail-generator of choice.
Just yesterday I tried to register for a service using one of my own domain names with self hosted email. The confirmation mail arrived, but as soon as I clickes the link I was told that my email address wasn't allowed.....
Not sure what kind of crap some folks are smoking, really.
I'm not saying there aren't flaws, I'm saying none of them happen at a rate significant enough to be worth switching to another system (with an entirely new set of flaws).
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.
Also login.gov isn't a government issued digital ID. It's just a centralised authentication platform for government use, much like using google or apple for authentication.
It supports the usual options for multifactor (TOTP, text, yubikey/other hardware auth/PIV cards) but for most users it probably ends up being SMS. At best TOTP.
> 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.
Nah the government could just give a website a unique id per real user per website, without revealing who the user is. Merely verifying that they are the same person as last time.
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.
> “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.
We have this in Belgium and it’s really not that good. It created a pattern of companies relying on people having an account at certain banks; which when you’re either immigrant or unbanked is unlikely and shuts you out of certain businesses.
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.
Banking credentials are used a lot in Finland to sign into other services. This means you get phishing emails saying "your medical test results are available" or "you're getting a tax return" where the actual goal is to get into your bank account.
The german gov ids actually have a way to issue pseudonymous tokens where websites can only see that you are the same person as last time.
You can't make 2 accounts on the same site if sich things are unwanted.
You can't link accounts across providers.
How it works under the hood?
No specific idea. I wonder if its sound.
How does the government know which token a ID card generated? The ID card itself generates (for each service a different one) and encrypts it. Not even the card reader can read it. It is a encrypted channel between the card and the ID-server for the site/service. The pseudonym function does not identify a person but a card.
The government doesn't know which card a token from a "pseudonym function" belongs to. The government can identify a person when the ID function was used, of course.
Again, it is a random token the card generates internally for each service. It is non transferable! If you get a new ID card, you can't use it login to whatever you used your old card for. (You would need something else... say an email :-) to tie the knot back to the old identity or whatever.) Which makes this function, the pseudonym function, very bad for random accounts (Edit: meaning longer lasting online identities like forums or whatever). I guess eaglemfo didn't knew.
It's more for like "yes, yes, I'm an adult, now give me this pr0n movie which I pay for with my anonym prepaid card" kind of deals.
I read this as tongue-in-cheek at first (since most web sites do their darnedest to track their users, and having a log-on kind of requires this anyway).
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.
Login.gov is the US Government’s homegrown solution, which also does it. It’s not one account <-> one citizen though, which you’d probably want in a real government id system.
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.
Some day someone is going to produce a fantastic heist movie about breaking this kind of scheme - five different characters, each of which need to be scammed in different ways to obtain their piece of a shared secret.
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.
But in fact, in order to kidnap these people you'd also need to know these people, and know they are assigned to be part of the derec network. With DeRec all the helpers don't need to know about each other at all. And you may not know how many helpers a given helper has behind them. It's actually much much more difficult to do the heist-and-interrogate-with-a-pipe-wrench approach if you don't know who to beat up, nor how many of them need to authenticate.
Edit: OT but while I have a glimpse of your attention, kudos in order!! I love datasette and basically everything you write is highly useful to me!
I came up with a similar general approach about 10 years ago, but lacked the time or inclination (and probably knowledge, frankly) so I'm very pleased this is being pursued.
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.
I thought the Authenticator apps were great until I upgraded my iPhone and the apps lost all of my Authenticator setups. Good thing it wasn’t super critical.
I agree, for personal use cases, RFC standard TOTP that can be backed up and managed by the user is the ideal balance of security and availability.
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.
> 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.
I don't think this is right. If there's a shared secret like a TOTP seed, that's in theory a "something you know", but if I don't know it, then who does? The point of "something you have" is that you own a device that "knows" it for you, and you never even need to see or expose the underlying secret, you just copy a token proving that the device you have knows the secret. I think that does count as an additional factor.
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 in theory a "something you know", but if I don't know it, then who does"
An attacker. Your knowledge is much less interesting that the knowledge the server has, which is what the attacker can obtain. Grabbing a TOTP key out of a database is not materially different than a password.
TOTP's different characteristics mean it's harder to intercept, but passwords tend to be stolen nowadays moreso than intercepted, if only because you can intercept only one at a time but can steal the entire database.
The different characteristics mean it can add a bit of utility to a normal password, but I think it's less night-and-day than it was presented as.
> 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".
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.
"By that logic, even biometric factors are "something you know","
You clearly mean that as a reduction to absurdity, but, yes, I mean exactly that. Pretty much said so.
It is "reductionist" if you insist the only valid framework is "what have have/know/are", and you view what I'm saying as the intersection of what I'm actually saying and that model. I am claiming the have/know/are is reductionist, and to a large degree outright wrong, because it is focusing on the wrong thing. Look at it the way I'm looking at it and the authentication questions become richer and easier to understand.
Unfortunately, it also means that there's more things that are either hard or impossible than the have/know/are methodology promises, because two of the things that methodology promises effectively don't exist. (Unless you are controlling physical access, and willing to spend a lot of money on hardware and human verification of the correct use of the hardware.) But since I believe that is an accurate reflection of reality, blame reality, not the model.
While the "something you x" model has many limitations (and I practically disagree with some regulatory bodies on what does and does not constitute a "true" expression of one of these factors), I don't think that these limitations refute it in the abstract.
Yes, if you don't control the hardware at the user's end, the only factor you can get is "something you know".
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.
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.
IMEI or IMSI? I think it is the subscriber identity that is on the SIM that needs to be cloned, not the hardware identifier of the device (ie its the IMSI that matters, not the IMEI).
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.
Neither the IMEI nor the IMSI is used for authentication. The IMSI is slightly closer to the truth (while still missing by a mile), but without the per-IMSI authentication key (which is never transmitted over the air interface, whether in plaintext or encrypted), it's useless as well.
That's completely wrong. The IMEI doesn't play any role in GSM/UMTS/LTE/5G authentication (if it's recorded, that's usually for debugging or tracking purposes).
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).
As others have mentioned, SIM Swap attacks are very common where the attacker impersonates the victim and convinces the mobile operator to transfer the victim’s phone number (known as MSISDN in telecom parlance) to the attacker’s SIM. If you Google SIM Swap, you will find many instances of it.
From that moment onwards, all the 2nd factor SMS OTP go to the attacker.
There are APIs that are provided by mobile operators via aggregators such as Telesign, Prove, Vonage, Twilio etc. that can be used to check if a SIM Swap has happened recently on that phone number. That API is used by fintech companies and others e.g. when they want to check if a fund transfer is to be allowed or flagged up.
bribe, coerce, and social engineer a phone company employee into transferring the victims phone number to you, or a technical attack to get the system to send the sms messages to a device you control, without ever touching the victim.
And they're rather irritating to boot. TOTP authentication in something like keypass or 1password is very low friction, working automatically in ideal circumstances. Sms based ones are kludgy
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 would imagine that plenty of users these days wouldn't bother to save their order details on the grounds that "oh, I'll get a notification with those".
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 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.
It's "temporary". You can set a password later and use it to login with email + password and store it in your password manager. Only the initial signup and the first login on a new device will require the "reset password" workflow. Imho, that's the best of both worlds.
I agree it's inferior to a password manager but I think passkeys will usurp the role of password managers in the long term, and for everyone else who won't use either, a simple email is an easy ask -- better than having them go through password reset every time they use the site.
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?
I worked on email delivery systems. Your comment makes me realize that something that was free and trivial in the 90s is now painfully complex and expensive, because of monopolistic practices and spammers. We ruined something great.
A lot of email reputation at this point, in fact I'd say most of it, is FUD. Here is a current example I am a hostage of:
Sys4 (an ESP) uses Abusix as a reputation service. Because this is poorly thought out (I've been a member of the mailing list for many years) I can't unsubscribe from the postfix-users@ mailing list (can't post either). Ok that's weird and funny in a way. We could talk about Sys4's procedural failures which go into it but we would be here all day.
I did Abusix's PYLM and they unblocked me, only to eventually block me again; that's when I found out I couldn't unsubscribe. I could PYLM again but I don't care. But that gave them an email address in the domain that they block. Do you see where this is going yet? I promise you there will be a twist at the end!
Funny thing is, I can send email to support@. Well, ok, so I think it's probably good that they don't subject their support channel to their dog food, because third parties reporting vulnerabilities is a trope in cybersecurity.
Aaand, here we go. So last week they sent UCE to that email address. That's right: they sent a marketing email to a domain that they block. I did not check any boxes "please, I'm a hostage, send me your marketing info and saaaave meeeee!" when I was talking to their support about what I could provide to my ISP. No boxes are checked now either, I verified this.
So, I responded to that email and said I'd be delighted to learn more about their product, please have Sales contact me. The marketing SPAM came from support@, the reply from Sales came from a person's email. Now we're no longer talking about that hypothetically exempt support@ channel, we're talking about corporate infrastructure. If their dog food is so good:
* Why is corp accepting email from a domain they block?
* Why is Sales sending email to a domain they block?
Here's the twist I promised you:
Do a DNS lookup for their MX: it's Google! They don't eat their own dog food, at all! Google has no problem with my domain; that's a general observation. If Google doesn't use their reputation service, why should you?
So had the call, none of the essential facts were disputed. The person I spoke with doesn't think Sys4 is using the feed in the way intended and they're going to check on that. I connected with them on LinkedIn so we might not be on the same side of this issue but we're on speaking terms.
Generally, no, unless you don’t care whether it’s delivered or not
Too many people and companies abused this to the point that running your own mail server means much of the generic mail you send will end up in junk/spam folders.
What would prevent delivery? I do some work for a small organization and we send out registration confirmations with a self-hosted webserver. I am not aware of any delivery problems there. Thats why I was surprised. Are we just lucky?
For a login link, I wouldnt really care if its in the spam folder. The person is actively looking for the mail, surely they will find it? It's different for marketing or similar content, but for expected mail, I wouldn't care.
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
Beyond the valid reasons in the sibling comment (e.g. not accessing personal email on a work device), it is also a security risk. Access to your email is typically sufficient to gain access to everything else. I use an email for accounts that syncs with my phone only, and I lock it down tight.
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.
You'll be surprised how many diceware passwords you're able to remember.
It can go two ways depending on your preferences: use a shorter passphrase generated from a large dictionary; a good one can be obtained from 1password:
Base password plus company name or initials. One password mutated into infinite variations that are easy to remember. This has been working fine for me for at least 15 years.
I think their point is that no matter how secure your base password is, once one site leaks it, the bad guy basically knows your password to every site.
I have been using the internet since the 90s, my Hotmail account is 23 years old and I have never lost any of my accounts. I think it’s working quite well in my experience.
or it just continues working for another 23 years. Do you have a password system that has worked successfully for as long? Just because you “feel” that it’s not good doesn’t mean your feelings are correct.
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.
Learning how to password effectively is something that comes up in B2B in many non trivial software.
Magic link is effectively passwordless login, behind a facade outsourced to a third party provider.
Passwords are much more actual consent, than clicking on a link in an email account that might be open on a screen or device... not always.
SSO is technically easier than poor man's sso, it's just one click once logged in. Magic links make me switch a screen to make it easier for the developers of Magic Link to not implement SSO.
Fingerprints are a username, not a username+password. It's super convenient, but well established not secure.
Face-ID logins are more a username, should not be a username+password - selling it as secure is not ideal, but it is super convenient.
SMS verifications too, are a little weak, since SMS' generally are like post cards. But they are very convenient. Until someone does something to get malware into your phone, or your phone number itself which seems to happen so often.
Now, magic links are very convenient. And definitely can remove friction to you know, get a user onboarding to the point of adoption.
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.
Yes, it is true. There are indeed cases where you are not presented with SMS options.
And I'm not going to purchase and carry around a hardware key just for the privilege of periodically logging into my Apple accounts.
Maybe Apple shouldn't force you to own an Apple device to login to your accounts? They've been sued about this before and lost. If Microsoft did this, people would lose their minds.
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.
Friction. When the username is an email address, 100% of people logging in have an email address. Telling someone they need to setup TOTP, especially if they have never done so before, is going to be a bridge too far for something they may only use once or twice.
One site I remember using this email code login was a small online store. If I was prompted to setup TOTP to buy something, I would have probably not bought anything. If my mom was prompted for that, she’d end up calling me, and I’d have to try to walk her through the whole thing… then I’d keep getting calls the next 5 times she’s had to login.
If the site gives directions on what to do, they will probably only be written targeting a single authenticator app. For people who don’t yet know that the apps are generic (in most cases), this can lead to a user having 3 sites setup in 3 different apps. It can become a mess very quickly.
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.
I’ll be hyperbolic and say the login flow is identical.
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.
People who don't use something which integrates with the browser. People who run into the (uncommon but noticeable) edge cases where the password manager decides to not auto fill the password.
When it doesn’t work I get. I run into that from time to time.
But I don’t think normal users want ones that don’t sync or integrate with the browser. I believe you can turn both off for Safari but that defeats the whole purpose in my mind.
I do! And way more than I would like, because for some reason it's "modern" to have a login flow that first requests your email, and then you have to click next for it to request your password...
Not even gonna go into detail about all the other cases like websites that have such bad field identification that the password manager has no clue where to put the username/email or 99% of sites that don't have autocomplete="one-time-code" on the 2FA field so now you have to copy paste the 2fa.
Plus all the android buggyness where the auto-complete from the password manager just doesn't show up at all so you have to switch apps and copy/paste the credentials manually... when it works (and doesn't clear the fields as you swap between apps... I swear built-in chrome windows is a mistake).
> And way more than I would like, because for some reason it's "modern" to have a login flow that first requests your email, and then you have to click next for it to request your password...
There's a reason for that, and it's not because of 'trendy', it's because the backend will examine the email address and decide which password authentication mechanism the user chose: FB/Google/etc, or authenticator app, or plain old password, or some third-party SSO provider, etc.
Keepassxc's desktop browser extension allows you to specify the username and password boxes. Even if they are on separate pages. It's really a painless 15 second process.
I have to do it on my bank's website every few months.
I suppose the reason is because the Bitwarden option is cross platform and I don't want to sync two password managers.
However when using Bitwarden the recent guidance is to turn off autofill[1] but even with it enabled it sometimes breaks hence my “seldom” caveat.
I am heavily biased to prefer passkeys but as with magiclinks before them saw the rollout was badly botched. Specifically with regards to supporting multiple keys and revocation[2][3]. The standard supports correct implementation but don't require it; meaning most current rollouts are half baked and will remain that way.
Ctrl-C and Ctrl-V work consistently on Windows + Linux. For Android, almost same experience with KeePassDroid that shows notifications to Ctrl-C the user and the password.
I’d prefer my passwords, foundational identity documents, and other sensitive information are as separate as possible from the place where I execute untrusted remote code a bazillion times a day. Making it programmatically available is the opposite of separate.
Me, every time another site annoyingly breaks autofill, sometimes even intentionally ("Password managers not allowed! Make sure to memorize your password, but still use at least 5 special characters and include at least 3 titles of ABBA songs!!").
TOTP is not really something that would be sent to your email. The entire point of TOTP is that you can generate the auth code yourself, from the current time and a pre-shared secret.
my wife chooses not to let chrome remember her passwords because she thinks it's lazy and insecure: everyone uses chrome, how will chrome know not to give her password to someone else?
Their motivation is immediately clear to me. If you use "I forgot my password" you don't have to remember a password. And it doesn't even make your account less secure, since that pathway was going to be available to attackers regardless. I've seen websites that make that their default flow, arguing (implicitly) that having passwords at all is pointless when you can just email someone a login button, skipping a step.
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.
I used to follow this process for many of my logins (the less critical ones) before password managers were mainstream, and it was a conscious decision to do so.
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.
When I ask people why they do this, they either don’t have an answer, or respond with “huh, I never thought about why”. And that’s interesting to me.
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.
> whether we can take advantage of people’s tendencies towards learned behaviour like this
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:
Too many don't actually verify the identity. I often get emails lying in the footer with something like "you are receiving these emails because you signed up" - no I didn't, someone else did, and you didn't check. But fast onboarding is king, right?
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.
I agree, but I strongly prefer the ones that allow both. I use a password manager, and a mandatory OTP email flow often annoys me enough that I think twice about logging in if it's not that urgent.
With email being the source of identity on the internet, it's really unfortunate that the standards have largely lagged heavily behind when it comes to stronger authentication algorithms. Why is SMTP still plaintext on port 25 for MTA<->MTA? Why is STARTTLS really the best we can do? Why do we not support 2FA or mTLS or passkeys or any one of the other modern authentication mechanisms or IMAP4, SMTP, etc.. ProtonMail is ok but the hoops they have to jump through to get their stuff working is obnoxious.
And why, in 2024, is requiring any encryption at all a violation of RFC 5321, thus making any MITM literally a trivial and impossible to defeat downgrade attack?
I wish sites would acknowledge the need for a nerd mode that gets rid of all the stuff that annoys nerds and is essentially password or lockout, no resets. Enable reset methods or 2fa at your own whim.
For the rest you can do weird stuff that doesn't work on nerds.
> What if we could somehow design systems so that the people who use them evolve to use them in better ways?
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.
I swear the McDonald’s app for the U.S. works like this on purpose. I’m prompted for my email then thus send me a link. They never ask me to set up a password.
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.
This is why I've been relying on magic links via email as a sign-in/up method for my applications. Users will either default to oAuth OR they will use some generic email/password combo. The magic-link works for both sets of users and ensures that they always have instant access without having to manage yet another password.
Disclaimer: I loathe this pattern & hope something like WebAuthn prevails instead.
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?
Interestingly enough, that is the login flow Figma is using with my account. I provide my email address, and get an email that contains a linkt to log me in.
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.
> 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.
Wow, that's awful. So they abuse "forgot your password" as a login method, with the added obstacle of having to come up with a random password every time. And they don't see any problem with it. My hunch is that all these people are very non-technical users.
I do that for some sites. It's the initial effort required to set everything up that's the obstacle. This kind of behavior is taking the easiest route at every step instead of investing time into making the future easier. I stopped using a password manager after it got hacked and haven't bothered setting up a new one.
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 can save you some of that research. The KeePass family of password managers are open source and based around a shared file format. They save your passwords in an encrypted file on your computer or phone’s local drive. An ecosystem of apps by different people can parse that file format (after you enter your master password), and at least one app can export as CSV or HTML, so migration is not a problem.
Since your passwords are in a local file, there is no online password manager that can be hacked. If you worry that your local password manager software will have malicious updates posted, you only have to read news at the time you download an update, which can be as infrequent as you like.
If you need to share passwords among your devices, you can store the encrypted file in a generic file syncing service such as Google Drive or Dropbox. Those services are less of a target for hackers than dedicated password managers, and even if someone obtains that file, your passwords will be safe as long as your master password is strong.
> 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.
These are pretty much the exact reasons I created https://github.com/conradkleinespel/rooster. It's a simple password manager for the command line. It's offline. It's open source. It's stable. It can export passwords to plain text in different formats.
And its feature-set is intentionally limited, so I can maintain it with little work, to avoid it going down the gurgler. It's been available and maintained since 2015.
> When I ask people why they do this, they either don’t have an answer, or respond with “huh, I never thought about why”. And that’s interesting to me.
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.
Exactly, that should be obvious but it's just that they don't care enough.
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
Recently I have a harsh experience with my AWS account. I made a dumb thing, my email inbox is registered under a domain, and somehow my domain's MX record is gone and I can not receive email from AWS to authenticate to the right account to fix that MX record. So I am permanently banned away from that account due to the policy of AWS
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.
Some apps enforce this flow, e.g. there is no way to log in with a password. I hate this.
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.
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.
As long as the email account is secure, and the throw-away one-time passwords are good, you have the frequent-rotation passwords security advocates dream about. Indeed, hand them a secure password they have to use (and forget).
I just made it an option in the "I don't have a password" form that instead of setting a password it just logs them in. So they don't even see / have a password to remember.
> and whether we can take advantage of people’s tendencies towards learned behaviour like this.
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.
Login and authentication are a really big deal, and represent some of the most complex code, in one of my apps.
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.
You posit a good question but it would be interesting to take a step further and discuss some potential alternatives, or expand on why "email is authentication" is/isn't the best option there is.
For seldom used (or cared about) accounts, this is pretty low friction, and most of those will keep you logged in for an extended period of time.
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.
Identity is tricky. Proving who you are depends on a certain level of trust. Whether it's through email, devices, phones, or, in more advanced settings, some sort of digital certificate; you won't have much options.
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.
Sometimes email is the best way. Like if you are constantly posting files to third-party file hosting services (Box, Dropbox, etc.) that are not tied to AD of the recipient you have to have a way to ensure that only people currently working at the company can access the content. SMS and TOTP do not solve this problem in the same way that email does.
The problem is just that despite all the advantages it would bring, people won't pay for auth as a service, where your identity is tied to accounts outside of an email address, and you (say) get a browser/phone notification to log in when you log in with MyAuthProvider and it's quick. They'd rather go through the email route, which is the same thing but slower and goes via Google.
booking.com natively supports this "email is authentication" pattern, so you even don't have to change your password and come up with a throw-away password. They just send you a link by email, you click the link, and you are logged in.
The second component of this, for people that doesn’t care to do good track of their passwords, is that their email passwords are usually memorable in the wrong way. So both your mail and all the dependent services are all held together with the same weak clip.
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 second component of this, for people that doesn’t care to do good track of their passwords, is that their email passwords are usually memorable in the wrong way. So both your mail and all the dependent services are all held together with the same weak clip.
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.
Email passwords is interesting one. As my feeling with something like gmail is that you insert it approximately once or twice per device... Which leads to weird dynamic that you have to recall it way too rarely for actually to remember it properly...
> I think people can’t answer why they do this because it’s not a concious decision
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.
Any strong 2 factor authentication without the kind of high touch processes that a bank can afford is a corporate suicide pact. 10% or so of your users will be permanently locked out each year and once you get past the early explosive early growth phase that turns into a near steady state instead you get radioactive decay.
I'm surprised we don't have a standardized, cross-browser, simple, email-based authentication system.
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.
The thing is, the moment some service allows you to recover your password through email, this becomes a legitimate pattern. As long as the throwaway password is reasonably complex, the service becomes as secure as email can be (which is, imperfect)
This is actually a really good use-case for PGP. Opt-in use to upload the pubkey and, if provided, encrypt automated e-mails like auth links and password reset.
Facebook supported this for years, not sure why they recently deprecated it.
User researchers are great at making these kinds of discoveries. The basic idea is that you've got to actually watch a user when they use your site, ask some questions about what they are seeing and thinking.
How do you deal with the situation that you lost access to an email address (e.g. change of employer) and years later you want access to an account that turns out to be tied to that email address?
In general, I really am disturbed that so many websites use my email and phone number for authentication. I use authenticator and password manager apps for a reason. Using my email and phone number is both unsafe and was never approved by me. They just started doing it. Further, there's no way to turn it off.
People have already been building auth flows that take this password amnesia into consideration. Look at Anthropic. It's just one way of doing auth and I personally hate it.
Personally, I don’t care to share the username to any account, password protected or not.
On a related note I think it is terrible security to have display name be the same as user login name.
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.
That is true, there is no silver bullet. For the people like me that know and have multiple keys in multiple secure locations are probably mostly fine, other solutions on government och bank websites is that they need somekind of formal verification before giving you a new key. There are always tradeoffs regardless of solution, depends on what you value.
I am one of those people who always clicks "forgot password", and sorry but it's actually fine. I type a long, completely nonsense sequence of words and characters for my new password, then ctrl-c to copy, then log in with that password, and then promptly forget it.
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.
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.
What are the other potential problems of the "email is authentication"
pattern, under the following prescribed conditions? Maybe just these
two?
(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)
- End-to-end response time for the "Credential Recovery"
authentication process
- my guess is that users who choose "Credential Recovery"
authentication over other "happy-path" authentication are willing
to wait, or are use to waiting.
(Non-problems)
- 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.
Well, yeah, “magic link” is a thing and one of the easiest form of authentication supported by many providers, like Supabase, Vercel and libraries like Next Auth.
Another great side effect is that your backend doesn’t have to store user passwords which means removal of a lot of compliance headaches.
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_.
> 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.
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.
> Most people do not want to do this
Yes, and I think that's not because they don't want to do it but because:
1) they don't know that they should do this; 2) they don't know why should they do this; 2) they don't know how to do this; 3) because even the systems marketed as current state-of-art (Passkeys) are poorly designed and don't even allow to have proper 3-2-1 backups conveniently (can't enroll a device sitting in a safe, it must be physically brought online which beats the whole point of offsite backups).
Design it to make backups and failover secure yet easy, available out-of-box, and explicitly recommending best practices to follow - and everyone will do it as a no-brainer, at least for anything they care about.
Until recently no one told people to not reuse passwords. Even today most password-based signup forms just ask for password and maybe tell the requirements (length, characters) but extremely rarely they explain anything about uniqueness, randomness or anything else. No surprise it sucks hard in practice, when nearly everyone ignores the education aspect.
People aren't stupid. At least in general. They're just blissfully unaware about a lot of things, especially the older generations. What is impossible in real world is designing a fantasy football nanny authentication system to "safeguard" them, without making a lot of undesirable sacrifices. We manage to explain people to not poke with scissors into electrical outlets (and make it hard to do so accidentally) - we can manage similar stuff with computers too.
> We manage to explain people to not poke with scissors into electrical outlets (and make it hard to do so accidentally) - we can manage similar stuff with computers too.
I don't think this is a good analogy, because the example is simply warning people of a thing not to do. It takes no effort. Maintaining backups does take effort. This is more like getting people to pick up a new chore, just like how many people see interacting with their bank and financial services as a chore.
Many people who work in IT (or are into computers as a hobby) discount the effort it takes, because there is a lot less friction between them and computers than for the average person.
> even the systems marketed as current state-of-art (Passkeys) are poorly designed and don't even allow to have proper 3-2-1 backups conveniently (can't enroll a device sitting in a safe, it must be physically brought online which beats the whole point of offsite backups). Design it to make backups and failover secure yet easy, available out-of-box, and explicitly recommending best practices to follow - and everyone will do it as a no-brainer, at least for anything they care about.
People have been saying this for a long time. "We just need a better system!" The system doesn't exist because people don't want a system that requires effort. It requires effort to protect a secret that, if leaked or lost, would irreversibly result in your financial ruin. It requires a lot less ongoing effort (to a non computer savvy person) to use financial institutions to store their money securely.
People will choose the system that safeguards them and makes sacrifices that many computer security and freedom oriented people will find undesirable. This is demonstrated by the choices that people have repeatedly made.
People's bank accounts are irreversibly hacked, emptied, frozen, seized, blocked, impounded, garnished on a daily basis. That you haven't encountered it yet, doesn't mean it's not happening.
People should have a choice which system suits them more.
Is there not a choice? What is stopping you from converting all your fiat into crypto?
This is simply about what choice the majority of people have made, and likely will continue to make.
>> What is stopping you
Possible disapproval by fine HN community.
Highly relevant (self-advertisement):
https://news.ycombinator.com/item?id=41173227
I strongly disagree, but I feel that the conversation would be pointless fight of beliefs, unless I actually design and showcase a solution that would be simple yet secure (and I don't want anything that takes effort) - but that will take me a while to work on.
The idea is that user shouldn't have any friction, besides meeting minimal requirements: 1) being capable of reading (or otherwise accessing the text) and comprehending simple instructions; and 2) having certain minimally required hardware or software installed.
I'm sure this is doable and every primitive to build this already exists and vetted by competent people. I'm sure it's possible for a layman non-technical person with normal cognitive capabilities to have a safe authentication solution (which is very different from data backups) with full ownership of their identities and credentials.
Sure there are people that cannot read or cannot comprehend things. A lot of people. I've seen way too many folks who had simple and clear ELI5-grade instructions with zero technical jargon - and nonetheless had failed to follow them because "computers hard". In some case it's the fault of UI or UX, but I strongly believe in most cases it's just learned helplessness - "computers are not my thing and they're hard" and brain shuts off instead of even trying to read. The only solutions are to 1) make them actually interested in achieving their goals (worked for my dad - man went from "I don't know and don't understand [and 'I don't want to' in the tone], order this for me" to suddenly figuring it all out and placing online orders in just a few minutes as soon as he actually needed something when I wasn't around to help), and 2) make sure they have all materials accessible, well structured and covering as many possible scenarios as possible so it's all there the moment they snap out of their learned helplessness. Nothing else works as it is fundamentally impossible to design anything that would work even if people don't read and don't think.
I have some sketches in my mind, specifically focusing on use by laypeople without making compromises about fundamentals (like what is identity - a lot of modern auth perverts this concept badly). I'll give it a try someday, actually drawing it all and writing notes on the inner workings. Wish there'd be a ten of me and we'd have 240 hours a day... Sorry.
> This is demonstrated by the choices that people have repeatedly made.
I'm afraid this is a very bad attitude to follow. The choices people had repeatedly made got us in quite a bad place. Just look at the poster child - IoT - it's a complete disaster. Online auth is in a very similar poor and messed up state, it just less visible.
I think we may be passing as ships in the night a little bit - that is, I thought we were talking about cryptocurrency wallets, and the merits of a system with authentication relying entirely on cryptographic secrets.
I wish you luck in your development of such a system. I don't disagree with anything you said about learned helplessness, and I think it can be fruitful to push individuals or groups to overcome it, but I think trying to do that to the general populace is like trying to change the wind.
Not reusing passwords at all is pretty impractical. If you really want to depend on a single password manager then you have some other issues. Usually I have settled for rotating, compartmentalized password modules which allows me to somewhat rather than fully contain a compromised password. And if your modular password has three slots (term taken from linguistics) then you can compose passwords which reuse parts, are memorizable, and not automatically reusable on other services.
The problem though is that since one has a number of passwords which may be different but closely related, a human may be able to infer a few possible passwords from a few compromised ones. In other words it still dramatically shrinks the key space an attacker might want to try to brute force. Preventing re-use is then a problem for 2fa regimes.
For my part I won't use passwords I cannot memorize and keep memorized in relation to the web site.
i think you’re sidestepping the parent’s point: if it depends on users doing the right thing every time, it’s not compatible with the real world.
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.
How many forms of backup survive "the government threw you in prison for years?" Even Gmail will refuse to authenticate a correct password with "we couldn't verify it was you" if you never binded your account to a phone and just got out of prison 3 years later.
Uh, well, in context of crypto - your (self-owned) crypto wallet totally would work.
As for email... Sure, I guess it depends on the service and their policies. But here's an anecdote. A few years ago, I've managed to log in in to a completely forgotten 10+ years old email account, finding its password in an old backup. It worked. ¯\(ツ)/¯
If an user cannot log in with a valid credentials, without brute-forcing them, after some years of absence, it's absolutely the service's fault. Of course, in the modern world, customer issues mean nothing so anything goes. But -quoting GP post - when designing a "fantasy football" alternate authentication system for the Internet, this probably shouldn't be a thing.
> 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.
Are you referring to a physical lockbox? Because if so, that is certainly not as secure as your bank account, because criminals could not drain your bank account by breaking into a bank, nor could your account’s funds be lost if the physical location were destroyed by a flood or other disaster.
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”.
It is not equally secure, if bank loses you money you have recourse, if bank loses your key (a fire, a flood) it's gone.
You can store it in two or N places. Or bank can do this for you.
"Mom, I already told you: you have to generate a key pair, split the private key into three parts using Shamir' secret sharing algorithm, then give each part to three banks. Whenever you want to use it, you have to go collect it from each of those banks---but DON'T write it down anywhere---and perform your transaction"
And to think the conversation started with an observation that people can't even remember one password.
I agree, there's miles of runway remaining for improving the UX. I actually think it'd be neat if a crypto had this (and a few other things) as a baked-in feature. i.e. In order to create a wallet in the first place, you need to identify e.g. 5 trusted friends who'll serve as recovery partners. Maybe it's initially tied to the same invite mechanic used to join the ecosystem. Could be done in a privacy-preserving (and to some degree anonymity-preserving) fashion. The right UI could make this even simpler than recovering a Gmail account. Everyone would just have it set up, and these conversations about losing your keys would be a relic of the past.
More places is more opportunities for the baddies to get it.
Shamir it.
please wrap the whole thing as a trustworthy product
I don't understand why this was downvoted. In case it's not clear: (S)he's saying to split the key into multiple shares that can be used to reconstruct the key if you have a large enough quorum. Then store each share in a different place. As long as you don't lose too many of the shares, you'll be fine. And one baddie is NOT enough to get the key.
Either shuffling those keys stored in N different deposit boxes is overly complicated for a normal person, or it is not overly complicated for a moderately dedicated baddie either
Unless the "baddie" in this case is the government, why would it be easy for anyone to obtain access to multiple secrets stored in multiple boxes/banks?
Multisig is a pretty common setup for crypto and there is software that makes it easier.
Can you show how it can be easy to use in normal life for a regular person and at the same time really difficult for the attacker?:)
"soerxpso" said "store your key at the bank", but you are saying "two or N places". So it sounds like 1 bank is less secure for your key then 1 bank is for your money, because you need two or more banks for your key, while 1 bank for your money is sufficient. Correct?
I stay away from everything crypto but I don't see the difference. In both cases if they didn't make it right you'd go to the courts and make your case that they are at fault and owe you compensation.
In the first case, bank deposits are insured. In the second case, safe deposit boxes are not insured.
They're just different things. The FDIC insurance is for if the bank itself goes insolvent and they literally don't have enough money to cover their depositors' balances anymore. There's no reason a safe deposit box would be affected.
Yes, they are different things. A safe deposit box wouldn't be affected by the banks insolvency.
A safe deposit box may be affected by other things and if those things happen they don't have to "make it right", if you go to the courts and make your case you may find that they are not at fault and you are not owed any compensation.
A fire, a flood, a robbery...
Is a bank deposit box not insured against those things? I've never really thought about it but always assumed they would be
Probably varies from bank to bank, but in my experience you have to specifically buy separate insurance if you want the content of your deposit box insured. The big problem from the bank's point of view is that, unlike your bank account, the bank doesn't know what you have in the box and thus has no idea what to insure it for and no way to verify any claim.
More importantly the bank doesn't profit more from something more valuable being in your safety deposit box so it doesn't make economic sense for them to be the one insuring it.
The history of crypto says, "Good luck!"
There is a long history here of once trusted institutions turning out to be fraudulent.
I might be mistaken, but are not several "traditional" banks offering crypto wallets for customers? Is there a realistic chance this kind of bank is going to steal their customers' crypto and going (at least, next to criminal investigations) bankrupt over it?
Sure, they could. Would that be any different from how a bank could steal funds from a traditional deposit account?
By making a bank the custodian of your crypto wallet, you're placing your trust in them and should have similar legal recourse you would have had with a fiat deposit.
I am not sure if you are objecting. Definitely you need to trust your bank if you are going store your crypto with them. I just do not see any large traditional bank stealing their customers' crypto and hoping to get away with it.
As far as I know all the cases of stolen crypto have been newly founded companies with their only business being your crypto. That is quite unlike the other kind of bank.
If you accidentally burn cash you cannot recover it. The paper in your hand isn't replicated in another place.
Humans have been unable to recover from mistakes since day zero
That is a funny example to use because the US Government has a service specifically designed to help you in that situation: https://www.bep.gov/services/mutilated-currency-redemption
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.
It doesn't need to be completely burned to be gone:
"No redemption will be made when (...) Fragments and remnants presented which represent 50% or less of a note are identifiable as United States currency but the method of destruction and supporting evidence do not satisfy the Treasury that the missing portion has been totally destroyed"
Not that unlikely, in my opinion.
For at least 12,000 years, humans have been getting very good at holding on to physical things.
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.
Accidentally burning money is a very low probably event. Forgetting passwords or any type of memorized secret is the most likely default outcome, and chance only increases with time passing.
> If you accidentally burn cash you cannot recover it. The paper in your hand isn't replicated in another place.
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 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.
I don't know, we carried physical money for millenia. Humans managed that.
Yes and people quickly realized that there is an amount they don’t want to carry around. No one carries their life savings and few would even keep it in a safe in their house.
Yes, by evolving banks to solve some of the problems of lugging around lots of cash and/or stuffing it in a trunk in your house. And assuming you are known at your bank and/or can (eventually) prove your identity there, you don't have the same "lost wallet" problem being discussed here.
Money occupies physical space, so for most of history there was a pretty low cap on how much you could bring with you at once, which placed a cap on how much a single mistake could cost you.
Currency was traditionally made of precious metals which often gave them a rather high starting point of value. It also made them inflation resistant meaning the real value only grew over time. For instance in the Roman Empire an aureus [1] was worth 25 denarii (prior to inflation) and was about 2cm in size, so roughly the same size as a dime, made of pure gold. And a denarius was worth about a day's wages. So you could comfortably hold decades of wages in a small coin purse. And as inflation ravaged the Empire a single aureus gradually came to be worth thousands of denarii.
[1] - https://en.wikipedia.org/wiki/Aureus
This is what transit payment cards in Japan at least do, you can tap to pay most places but there’s a cap of 20k yen you can add to your card, so there’s a cap to how much you can lose.
I love how these cards work in Japan. There’s a bunch of different operators but they all work across the country – for example, if you buy a KITACA in Sapporo, you can use it in Tokyo and Osaka and anywhere else. And of course you can use them in a bunch of places, from all the transit options to vending machines and coin lockers on stations to konbini everywhere and even some restaurants.
(Of course it’s a bit more complicated: https://commons.wikimedia.org/wiki/File:ICCard_Connection_en... – but still impressive nonetheless!)
> cap on how much you could bring
Bring to where ? Are you mapping the crypto wallet concept to the physical wallet concept as a mobile storage concept ?
All your money is the limit, however you store it.
That cap has always and still does exceed the median worth.
> there was a pretty low cap on how much you could bring with you at once,
you didnt need to bring a case of cash to buy anything before the 20th century
You didn't lose your entire savings if you lost your wallet, usually.
Perhaps micro wallets should be a thing where your wealth is distributed across many keys mitigating some loss.
At which point I gained the problem of having to keep track of all of my microwallets securely, hopefully in a way that survives my phone being lost, a house fire, or my untimely death, leaving the wealth to inheritors. All while, at the same time, not ending up behind a single key that has access to all the information to those micro wallets.
Quickly you end up in a situation that either starts to look like how financial companies keep their most high risk keys, or end up outsourcing the whole thing to something that quickly starts to resemble your bank.
So ultimately it's just like cash: Fine for small amounts. Risky, but maybe livable for somewhat larger accounts, or a giant headache that will probably bite you when you start looking at lifetime savings.
If I’m having trouble juggling a single ball, why would it help to add more balls into the mix?
Physical money is physically recoverable after lost
For the system yes, a dropped coin eventually reenters the market and a burned bill can be reprinted again. Can't say the same about a crypto wallet. For an individual though, in both cases, a lost wallet is a lost wallet.
While an interesting difference to study, the average person is not going to care about the former case. They just don't want to keep their life savings in an asset as easy to loose as their pocket money.
If you drop your wallet in a bar, there's a chance you can recover it by returning to the bar and searching for it, by the bartender or a patron returning it to you based on the address or a number in your wallet, etc. Physical money really is not the same, even for the individual.
A burned bill can be replaced because its value is backed by an institution--the absence of such an institution is the premise of crypto.
No it isn’t. No more than a wallet key.
If I lose $1 note. It’s gone. If I recover it, then it’s no longer lost.
A $1 note being a macro scale physical object enjoys a variety of benefits such as object permanence which provide a baseline level of recoverability. Whereas a wallet key l, being a number, enjoys no such protections.
Of course you may choose to encode your wallet key on paper, metal, or stone granting it properties not unlike a note. However you have now compromised the security of your wallet as well it becomes no mere $1 note, rather it is a note that represents all or a significant fraction of your net worth.
You can encode your bitcoin in wallets of predetermined size, spreading your risk.
But you’re reinventing money with extra steps.
> But you’re reinventing money with extra steps.
But you gain some desirable properties over traditional money.
Without crypto, you don't have frictionless and permissionless transfers of arbitrary value across international borders.
There's no fundamental property of the monetary system that prevents transfers of arbitrary value across international borders. There's just a large number of financial regulators, border guards, etc. who will throw you in jail if you carry a big block of gold across the border or accept a large wire transfer without filling out the necessary forms. In many countries, the laws governing those forms don't yet apply to cryptocurrencies, but I'm skeptical it will remain that way forever.
That's true, and the AML laws for crypto are already becoming more strict, especially in Europe. But in practice, it will be much easier to evade those laws than it is with fiat transfers or moving physical cash/gold.
There’s also some weird technicalities:
Eg, if you shard a key into three pieces and each person carries one through security, did anyone actually transport the money through?
Banks have been a thing almost as long as money.
And the notion of credit has been a thing even longer than both money and banks. You don't need to carry money around for every little transaction if people know you're good for it someday in the the future.
Don't you need an idea of credit for money to work at all? You need to be able to trust that the shiny rock you give me today for my wheat will be worth anything tomorrow when I want some of your meat.
Yeah and it sucked which is why we invented better solutions.
What most bitcoin fans seem not to understand is that for the vast majority of people, transactions being reversible by authority figures is desirable.
> I don't know, we carried physical money for millenia. Humans managed that.
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.
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.
Maybe the key bank could hold your digital money as well. Then we wouldn’t need a blockchain and your transactions could be instant, free, private and reversible.
This is the same problem that you run into with secret zero and commonly discussed in context of HashiCorp Vault. At some point you need to store the unlock keys then you need another repository under RBAC to protect that repository. They say to print out the keys and store them offline on paper but how many own a Class 5 safe ?
How many own a lot of books? Just... pick one.
Not following? Do you know what I meant by a Class 5 safe?
https://www.norfolksafe.com/
I don't. And frankly I don't think a safe is a good place to store secrets. It is too conspicuous.
These safes are certified for all kinds of sensitive (GSA recommends them for Classified use from what I have read) use and they are safe.
Ideally, you connect Vault to a HSM if you need that kind of security that’s being described. HSMs are electronic safes
> These safes are certified for classified use and they are safe.
The website says "10 minutes against forced entry". That's not safe.
No safe is safe against a state level actor. No safe is safe against "hit you with a crowbar until you open the safe".
Whatever secrets you have, it's better to hide them than to put them in such a conspicuous place. The only reason one should use a safe is as a plausible decoy...
This isn’t the safe to rule all safes. You have other mitigating factors like access control.
If you have state level actors physically breaking into your facilities then we might be at war
If you have enough books (which doesn't even have to be that many), it's much better to store your secrets in one or more of the books.
Yea but you have multiple pieces of the secret to restart your Vault instance. Now you need to go to everyone’s office or home to get this secret to restore it.
I am referring to Shamir algorithm that Vault uses
Collaborative custody multisig providers have been in business for years. Recently even Block (CashApp etc) has introduced a product with this feature.
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.
>> 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.
Currency in the real world has many, many backups. For example, if I forgot the PIN number to a very old bank account that I later find a long lost relative recently put hundreds of thousands of dollars into when they passed away, I have other avenues to recover access. They might be annoying or require work (getting an affidavit, multiple forms of ID, etc) but it's not irrevocable in the way that a strict definition of bitcoin is.
A bank account is not currency. Cash is. You can still put cryptocurrency in a bank if you so choose.
It's a lot harder for the average person to lose 1 million dollars in cash than in Bitcoin because humans naturally understand the exchange of physical objects.
If I have a duffel bag of money, it is obvious that physical possession of the bills means I can access its value. Anything negating that possession would cost me my money. I should probably keep it away from open flames and water; but it's not going to spontaneously combust. A thief would need to physically take the money in the duffel bag for me to lose the value.
Meanwhile if I store Bitcoin on a USB drive the drive might randomly fail and I lose all my money (because I'm actually storing a key to access it) even though I still have the USB stick. The solution is to back up my key in multiple places simultaneously, which doesn't make sense to most people (how can money be in two places at once?)
If I plug the USB stick into the wrong computer, someone can steal all my money (because they can find out what the key is) without me ever losing the USB stick.
Virtually every human on Earth understands the notions of object permanence and that objects can be exchanged for other objects. This is intuitive from evolution and actual monkeys can comprehend physical currency.[1] I don't see how cryptocurrency can be on that level.
[1]. https://www.zmescience.com/research/how-scientists-tught-mon...
The concept that this file is the password to the money isn't too complicated. The money isn't in two places at once, the file's the password to it.
It’s impossible to comprehend to most people.
Except reality isn't so ... digital.
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.
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.
Even Bitcoin core developers, which should be well above average in understanding crypto and good opsec, have had their Bitcoin stolen.
The issue in not trying to force one solution for everyone becomes a blocker when you intend on making some technology useful and essential to everyone, hence, no one seriously gives a damn about crypto anymore.
The claim that most humans are prone to losing keys isn't negated by the existence of some humans that have (so far) been able to keep their keys.
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.
Yes!
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.
[2]: https://en.wikipedia.org/wiki/Registered_mail
Germany has PostIdent: you are issued a code, take it to the closest post office, hand them the code (originally this involved printouts) and your ID card and they scan your ID card and enter it into their system where the issuer of the code can then request that info to verify your identity.
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.
Or you hold our ID card to your phone and do it on the spot.
https://www.deutschepost.de/en/p/postident/geschaeftskunden/...
Initially when I moved to Germany I thought it was a bit of a hassle to have to go to the post office for PostIdent; now I actually miss the elegance and privacy of that system in other countries.
https://en.wikipedia.org/wiki/De-Mail also was an attempt
The french postal services does that and includes a digital wallet and cloud repository.for instance, my paycheck certificates are delivered on this wallet.
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.
What are the names of these services, to see how they work, their recovery process and abuse prevention?
https://www.laPoste.fr/digiposte (digital safe) & https://laPoste.net/accueil (e-mail); offered by the postal services.
https://FranceConnect.gouv.fr/ is the online auth provided by the administration.
I don't want a semi-gov't authorized service like this. Because its existence means services would want to mandate it (even if they don't truly need it), and force users to identify themselves directly - may be even across services (by matching their email address, which now must be unique as it is identity-linked).
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.
Australia is working on zero knowledge proof. The end service only knows that you are legit/of age/etc (only what it needs) because gov service confirmed it, but does not know who you are
And what does the Australian government know? Could it collect who you identified with?
No, thank you. I don't want anybody with a fake ID of me to be able to take control of my email. I want to use my password, I want it strongly encrypted at rest, and I want to be able to reset it remotely any time of day, without waiting for the USPS office to open.
Is a fake ID going to fly at the post office, where they can scan them? Also, I was imagining they'd want more than just an ID.
edit: Also also, they have to go into a physical post office and be observed trying to steal your account. Given how it's quite possible to steal accounts via social engineering, this seems like an improvement in security, not a reduction.
I don't want a government entity, or really any entity I'm not paying directly for their services, to be the gatekeeper between me and my accounts.
The social engineering attack surface of my account currently consists of a handful of support contacts at my ISP, who have been trained to deal with computer security. If you allow any USPS employee to access your account, you've suddenly increased the potential attack surface by several orders of magnitude.
(1) Your USPS-provided email should neither be mandatory nor the only acceptable email. It could be an extra convenience, and a low-friction way to get a reasonably secure email for first-time / technically unsavvy users.
(2) An entity you're directly paying to may go out of business, sometimes due to circumstances beyond their control. At least state-sponsored entities don't do it so abruptly in most of the "civilized world".
The account recovery process for commercial email providers usually involves you photographing your ID. Presumably the post office, in person, would be far less likely to be fooled.
To get a RealID drivers license in the US, which will be required to board a plane soon, requires all of the above and more.
It’s a government in-person KYC.
> which will be required to board a plane soon
Assuming that this time the deadline doesn't get pushed back at the last minute again like has kept happening so far.
RealID requirement for domestic flights (still) isn't happening, just like it hasn't happened since it was first announced for requirement in 2008.
Not 100% required, even for adults.
Those without acceptable identification may complete an identity verification process and face additional screening. https://www.tsa.gov/travel/security-screening/identification
Everyone should experience this at least once - it’s eye opening.
I did it involuntarily because I forgot my wallet once, and decided “well, I’ll either get through and in my way, or I’m too late to drive home anyway and will miss” - and it worked fine.
Even crossed back into the USA without my passport a few times. Just additional screening and bitching is all (at least if you’re a US citizen; membership in the Empire has its perks!).
The irony with that is that if someone undocumented wanted to leave the country, this requirement could potentially hinder that.
I also don't really want to have to carry my green card around everywhere. Just one more thing that can be lost.
How would it?
To travel internationally, a passport is required (not drivers licenses).
I might have been being more simplistic than I needed to be, because there are other travel methods, but I was more meaning, "Not everyone lives next door to an international hub" (so might need a connecting domestic flight).
Passport will also work
I’m not sure I trust USPS to get all of the ins/outs of email spam/security/ux right. Google has spent a lot of resources to get Gmail to where it is today, starting from scratch (or OSS) seems like a big ask.
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.)
That takes mail spamming to the next level. (I'll show myself out...)
Now you lock out the rest of the world until they can implement this and federate identities between countries.
That's not a problem. Many systems and services have launched geolocked to certain countries before later expanding (Google Voice, for one).
> 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.
These things can be solved too, but in a more complicated process. Typically some lawyers and a judge need to get involved, get some people to testify that you are this same person, and you will be issued new ID.
How did he get a driver's licence with the name "Sam"? Don't you need some form of judicial process to change your name on this kind of thing?
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.
Having only a single such address also means you can be blacklisted forever, in addition to being tracked across services.
What I had in mind was more like randomly generated addresses as needed, all of them linked to your (one) mailbox. Like Apple's "Hide My Email", but without needing a "main"/"canonical" email address because it would be unnecessary anyway (because you would be logging in to your mailbox with your own certificate).
But even if that single-address limitation were the case, the kind of places I would give it to already require knowing my national ID number anyway, so the two particular things you mention are already the status quo.
In other words, stuff that is already tied to having a verifiable citizenship.
Estonia has this: <https://e-estonia.com/solutions/estonian-e-identity/id-card/>
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.
Yes. I would very much like to tie certain accounts to my government issued digital identity and allow that as the only recovery method.
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.
One flaw is I'm pretty sure a lot gmail account is lost forever. Contacting Google to retrieve access would not go well. Related is that if you try to self host email your messages are unlikely to reach anyone.
Self-hosting outbound email is hard.
Self-hosting inbound email is trivial. Anybody will send email to any random domain, they're just not willing to accept it from random sources.
And the latter is what is relevant for password recovery.
I self-host inbound but use established servers for outbound through my ISP and have had no trouble with that setup for a while. Forwarding to people through my domain has gotten a bit more challenging lately but I've got it working well enough to satisfy gmail so far. (The advantage with forwarding is you only have to convince one server to accept it, not everyone in the world, and there's some crypto stuff involved now that involves trusting some keys, not just a domain or IP, which also helps a lot.)
>Self-hosting inbound email is trivial. Anybody will send email to any random domain, they're just not willing to accept it from random sources.
That is simply not true. I have self-hosted email service and starting about 1.5 yr ago some big email services don't deliver emails to my server anymore. And there are many similar cases reported...
So one can say that even if an independent email service is willing to accept email traffic from any sender it does not guarantee that customers of all other services can have delivered their emails to addresses at the service.
That seems a great compromise. I hadn't registered the distinction in direction. Even without organising the forwarding part there are plenty of organisations that email me password resets that I don't need to send email out to.
> Self-hosting inbound email is trivial. Anybody will send email to any random domain, they're just not willing to accept it from random sources.
In terms of authentication, this is not entirely true. It's less common these days, but I used to have a lot of trouble with sites rejecting my attempts to create accounts with e-mail addresses from my disposable-e-mail-generator of choice.
Just yesterday I tried to register for a service using one of my own domain names with self hosted email. The confirmation mail arrived, but as soon as I clickes the link I was told that my email address wasn't allowed.....
Not sure what kind of crap some folks are smoking, really.
> from my disposable-e-mail-generator
Well, I suspect those are more specifically blacklisted.
I'm not saying there aren't flaws, I'm saying none of them happen at a rate significant enough to be worth switching to another system (with an entirely new set of flaws).
It exists for US citizens at least: login.gov (https://developers.login.gov/oidc/getting-started/)
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.
Unfortunately login.gov is only available for use by companies doing business with the US government.
Also login.gov isn't a government issued digital ID. It's just a centralised authentication platform for government use, much like using google or apple for authentication.
It supports the usual options for multifactor (TOTP, text, yubikey/other hardware auth/PIV cards) but for most users it probably ends up being SMS. At best TOTP.
> 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.
Nah the government could just give a website a unique id per real user per website, without revealing who the user is. Merely verifying that they are the same person as last time.
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.
Humans understanding the basic concept of public/private keys,
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.
> 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.
I'm not so sure how many ppl would leave a key to their house, or a pin to their bank account with the government. Or a bank.
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.
Clear in the US can do that: https://www.clearme.com/for-your-business
It's not exactly a government service, but Clear is trusted by the government enough to allow their customers to bypass the airport screenings.
Screw Clear and screw the US government for allowing more privatization of public infrastructure.
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.
Bank provided causes problems with people who don't have bank accounts. Here in Sweden most people use bank-provided electronic ID called "BankID".
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.
We have this in Belgium and it’s really not that good. It created a pattern of companies relying on people having an account at certain banks; which when you’re either immigrant or unbanked is unlikely and shuts you out of certain businesses.
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.
Banking credentials are used a lot in Finland to sign into other services. This means you get phishing emails saying "your medical test results are available" or "you're getting a tax return" where the actual goal is to get into your bank account.
> Government provided digital IDs
Oh man, that sounds like a terrible idea privacy wise. Every website would make use of it to track it's user.
The german gov ids actually have a way to issue pseudonymous tokens where websites can only see that you are the same person as last time. You can't make 2 accounts on the same site if sich things are unwanted. You can't link accounts across providers.
How it works under the hood? No specific idea. I wonder if its sound.
The problem is the government can then definitively associate all your accounts with your real identity
How does the government know which token a ID card generated? The ID card itself generates (for each service a different one) and encrypts it. Not even the card reader can read it. It is a encrypted channel between the card and the ID-server for the site/service. The pseudonym function does not identify a person but a card.
If it identifies the card and the govt can identify you by your card then isn't it by definition identifying the person?
The government doesn't know which card a token from a "pseudonym function" belongs to. The government can identify a person when the ID function was used, of course.
Again, it is a random token the card generates internally for each service. It is non transferable! If you get a new ID card, you can't use it login to whatever you used your old card for. (You would need something else... say an email :-) to tie the knot back to the old identity or whatever.) Which makes this function, the pseudonym function, very bad for random accounts (Edit: meaning longer lasting online identities like forums or whatever). I guess eaglemfo didn't knew.
It's more for like "yes, yes, I'm an adult, now give me this pr0n movie which I pay for with my anonym prepaid card" kind of deals.
I read this as tongue-in-cheek at first (since most web sites do their darnedest to track their users, and having a log-on kind of requires this anyway).
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.
I think it makes sense as the master recovery account. Then you use a secondary account for everything else.
Wasn't there a recent sidechannel attack on Infineon cryptography chips? The EU passports likely use the Infineon chips.
ID.me kinda already does this. They integrate with IRS, SSA and bunch of local government stuff
Login.gov is the US Government’s homegrown solution, which also does it. It’s not one account <-> one citizen though, which you’d probably want in a real government id system.
identification is different from authentication. But authentication at least as a backstop, can generally be decently outsourced to government.
Not so much in the US though. They have no national registry of what citizens actually exist.
[flagged]
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.
https://support.apple.com/en-us/102641
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.
[0]: https://www.youtube.com/watch?v=AcF4abPoveM
[1]: https://github.com/derecalliance/protocol/blob/main/protocol...
Some day someone is going to produce a fantastic heist movie about breaking this kind of scheme - five different characters, each of which need to be scammed in different ways to obtain their piece of a shared secret.
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.
But in fact, in order to kidnap these people you'd also need to know these people, and know they are assigned to be part of the derec network. With DeRec all the helpers don't need to know about each other at all. And you may not know how many helpers a given helper has behind them. It's actually much much more difficult to do the heist-and-interrogate-with-a-pipe-wrench approach if you don't know who to beat up, nor how many of them need to authenticate.
Edit: OT but while I have a glimpse of your attention, kudos in order!! I love datasette and basically everything you write is highly useful to me!
I came up with a similar general approach about 10 years ago, but lacked the time or inclination (and probably knowledge, frankly) so I'm very pleased this is being pursued.
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.
except that those instructions will be handed out by phishers
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.
I thought the Authenticator apps were great until I upgraded my iPhone and the apps lost all of my Authenticator setups. Good thing it wasn’t super critical.
I agree, for personal use cases, RFC standard TOTP that can be backed up and managed by the user is the ideal balance of security and availability.
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.
> 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.
[1] https://news.ycombinator.com/item?id=41275846
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.
I don't think this is right. If there's a shared secret like a TOTP seed, that's in theory a "something you know", but if I don't know it, then who does? The point of "something you have" is that you own a device that "knows" it for you, and you never even need to see or expose the underlying secret, you just copy a token proving that the device you have knows the secret. I think that does count as an additional factor.
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 in theory a "something you know", but if I don't know it, then who does"
An attacker. Your knowledge is much less interesting that the knowledge the server has, which is what the attacker can obtain. Grabbing a TOTP key out of a database is not materially different than a password.
TOTP's different characteristics mean it's harder to intercept, but passwords tend to be stolen nowadays moreso than intercepted, if only because you can intercept only one at a time but can steal the entire database.
The different characteristics mean it can add a bit of utility to a normal password, but I think it's less night-and-day than it was presented as.
> 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".
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.
"By that logic, even biometric factors are "something you know","
You clearly mean that as a reduction to absurdity, but, yes, I mean exactly that. Pretty much said so.
It is "reductionist" if you insist the only valid framework is "what have have/know/are", and you view what I'm saying as the intersection of what I'm actually saying and that model. I am claiming the have/know/are is reductionist, and to a large degree outright wrong, because it is focusing on the wrong thing. Look at it the way I'm looking at it and the authentication questions become richer and easier to understand.
Unfortunately, it also means that there's more things that are either hard or impossible than the have/know/are methodology promises, because two of the things that methodology promises effectively don't exist. (Unless you are controlling physical access, and willing to spend a lot of money on hardware and human verification of the correct use of the hardware.) But since I believe that is an accurate reflection of reality, blame reality, not the model.
I suppose then we have to agree to disagree.
While the "something you x" model has many limitations (and I practically disagree with some regulatory bodies on what does and does not constitute a "true" expression of one of these factors), I don't think that these limitations refute it in the abstract.
The way I see it, the main security benefit of TOTP is it's a very long, high-entropy password that is guaranteed to never be re-used.
Yes, if you don't control the hardware at the user's end, the only factor you can get is "something you know".
All the things around improving web authentication are just about people not having to memorize that something you know and protecting it against eavesdroppers.
I'm not familiar, which part of the comment does WeChat implement?
A panel of peers.
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"
Sure, but please make it optional.
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.
This is my gripe with 2 factor authentication: it increases security and as a second factor also increases the risk of you losing your account.
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.
IMEI or IMSI? I think it is the subscriber identity that is on the SIM that needs to be cloned, not the hardware identifier of the device (ie its the IMSI that matters, not the IMEI).
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.
Neither the IMEI nor the IMSI is used for authentication. The IMSI is slightly closer to the truth (while still missing by a mile), but without the per-IMSI authentication key (which is never transmitted over the air interface, whether in plaintext or encrypted), it's useless as well.
That's completely wrong. The IMEI doesn't play any role in GSM/UMTS/LTE/5G authentication (if it's recorded, that's usually for debugging or tracking purposes).
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).
Thanks for the clarification!
Phone companied have customer support. This is a weak point, because attacker can use social engineering to gain access to your number.
Phone number, not phone.
How does an attacker gain access to a phone number without having the phone? Like physically stealing the sim card or something else?
As others have mentioned, SIM Swap attacks are very common where the attacker impersonates the victim and convinces the mobile operator to transfer the victim’s phone number (known as MSISDN in telecom parlance) to the attacker’s SIM. If you Google SIM Swap, you will find many instances of it.
From that moment onwards, all the 2nd factor SMS OTP go to the attacker.
There are APIs that are provided by mobile operators via aggregators such as Telesign, Prove, Vonage, Twilio etc. that can be used to check if a SIM Swap has happened recently on that phone number. That API is used by fintech companies and others e.g. when they want to check if a fund transfer is to be allowed or flagged up.
Sim swap via pretending to be a clueless customer who lost their physical phone, banking on lax checks at customer service.
The attacker just needs to convince/compromise a single carrier employee to get a new SIM for your number.
bribe, coerce, and social engineer a phone company employee into transferring the victims phone number to you, or a technical attack to get the system to send the sms messages to a device you control, without ever touching the victim.
SMS codes for anything are not secure. Convenience over security, maybe.
SMS are as secure as a letter compared to a postcard.
And they're rather irritating to boot. TOTP authentication in something like keypass or 1password is very low friction, working automatically in ideal circumstances. Sms based ones are kludgy
Passwords are consent, clicking on a link in an email account that might be open... not always.
[flagged]
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.
Wouldn't the best approach be not to ask for an email at all (or only optionally for receipt)?
I would imagine that plenty of users these days wouldn't bother to save their order details on the grounds that "oh, I'll get a notification with those".
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 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.
I like the concept but at the same time I hate having to open my email to login to a site.
I already have a password manager. I rather just generate a password on one go.
It's "temporary". You can set a password later and use it to login with email + password and store it in your password manager. Only the initial signup and the first login on a new device will require the "reset password" workflow. Imho, that's the best of both worlds.
When do you ask for a password? Do users have to seek it out themselves?
Can users still login using only email after setting a password?
I agree it's inferior to a password manager but I think passkeys will usurp the role of password managers in the long term, and for everyone else who won't use either, a simple email is an easy ask -- better than having them go through password reset every time they use the site.
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.
I have seen some logins like this, can't you just send a link in the email that sends you to the app home and you're logged in already?
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.
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.
I’ve seen projects do the same, but also issue passkeys. That lets them seamlessly sign in across ecosystem devices.
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.
How do you do very long cookie? I thought safari deletes them anyway after a certain time.
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?
I worked on email delivery systems. Your comment makes me realize that something that was free and trivial in the 90s is now painfully complex and expensive, because of monopolistic practices and spammers. We ruined something great.
A lot of email reputation at this point, in fact I'd say most of it, is FUD. Here is a current example I am a hostage of:
Sys4 (an ESP) uses Abusix as a reputation service. Because this is poorly thought out (I've been a member of the mailing list for many years) I can't unsubscribe from the postfix-users@ mailing list (can't post either). Ok that's weird and funny in a way. We could talk about Sys4's procedural failures which go into it but we would be here all day.
I did Abusix's PYLM and they unblocked me, only to eventually block me again; that's when I found out I couldn't unsubscribe. I could PYLM again but I don't care. But that gave them an email address in the domain that they block. Do you see where this is going yet? I promise you there will be a twist at the end!
Funny thing is, I can send email to support@. Well, ok, so I think it's probably good that they don't subject their support channel to their dog food, because third parties reporting vulnerabilities is a trope in cybersecurity.
Aaand, here we go. So last week they sent UCE to that email address. That's right: they sent a marketing email to a domain that they block. I did not check any boxes "please, I'm a hostage, send me your marketing info and saaaave meeeee!" when I was talking to their support about what I could provide to my ISP. No boxes are checked now either, I verified this.
So, I responded to that email and said I'd be delighted to learn more about their product, please have Sales contact me. The marketing SPAM came from support@, the reply from Sales came from a person's email. Now we're no longer talking about that hypothetically exempt support@ channel, we're talking about corporate infrastructure. If their dog food is so good:
* Why is corp accepting email from a domain they block?
* Why is Sales sending email to a domain they block?
Here's the twist I promised you:
Do a DNS lookup for their MX: it's Google! They don't eat their own dog food, at all! Google has no problem with my domain; that's a general observation. If Google doesn't use their reputation service, why should you?
For the skeptical: http://athena.m3047.net/pub/soe/abusix-spam-backstory.html
My call with their Sales department is tomorrow morning; should be good times.
So had the call, none of the essential facts were disputed. The person I spoke with doesn't think Sys4 is using the feed in the way intended and they're going to check on that. I connected with them on LinkedIn so we might not be on the same side of this issue but we're on speaking terms.
Generally, no, unless you don’t care whether it’s delivered or not
Too many people and companies abused this to the point that running your own mail server means much of the generic mail you send will end up in junk/spam folders.
It won’t even be delivered in most cases.
What would prevent delivery? I do some work for a small organization and we send out registration confirmations with a self-hosted webserver. I am not aware of any delivery problems there. Thats why I was surprised. Are we just lucky?
You are just lucky. You can contact me if you want to discuss further, I would strongly recommend you don't do it here.
For a login link, I wouldnt really care if its in the spam folder. The person is actively looking for the mail, surely they will find it? It's different for marketing or similar content, but for expected mail, I wouldn't care.
You'd be surprised at how many messages I've gotten about expected emails not arriving, only for them to say "oh yeah, it was in spam, thanks!".
[flagged]
I love when sites do only that and then fail to deliver an email within 30 seconds.
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.
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.
Some sites do that, like Netdata.
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.
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.
Send that code autofilled into the destination url form so it's a second POST click to login and sounds good.
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.
Why make things worse for your users?
I will be sure not never use your webapp just because of the email login system.
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.
Please have both. We don't need more forced centralization when it comes to authentication.
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.
Christ, login with Google? I don’t have a Google account either. Why can’t they just have a username/password like the rest of the world?
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 don’t have access to my email on the computer in which I am trying to login to your web service.
Why not?
Beyond the valid reasons in the sibling comment (e.g. not accessing personal email on a work device), it is also a security risk. Access to your email is typically sufficient to gain access to everything else. I use an email for accounts that syncs with my phone only, and I lock it down tight.
Using someone else’s computer?
Using a work computer that you don’t want your personal email downloaded on?
Using a computer you don’t use often and don’t feel like setting your mail client up?
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.
Remembering passwords is easy this is just just convoluted and stupid.
Since you wouldn't want to reuse passwords how is it to remember them?
You'll be surprised how many diceware passwords you're able to remember.
It can go two ways depending on your preferences: use a shorter passphrase generated from a large dictionary; a good one can be obtained from 1password:
https://1password.com/txt/agwordlist.txt
https://1password.com/password-generator
or a longer passphrase from a short dictionary including only the most common words, like the EFF one:
https://www.eff.org/dice
https://secure.research.vt.edu/diceware/#eff
I don't use either generator, preferring a local command:
wrapped in a small helper script with desktop notifications and copy-to-clipboard.Let the machine do the work, sit back, and relax You have to remember 0 passwords and can still have a unique one for every account
Base password plus company name or initials. One password mutated into infinite variations that are easy to remember. This has been working fine for me for at least 15 years.
What do you use for the base password? The website name?
So if someone finds out your password for a certain site is `Facebook1234ABCD` they have a fair guess at every other password?
Same applies for `MyPasswordFB` using the reverse method.
My base password is secret but it is an alpha numeric string with mixed caps. An example would be “p45Sw0rD-Apple+” something in that vain.
So in the end the password contains numbers, letters both capped and lower case and special characters.
I think their point is that no matter how secure your base password is, once one site leaks it, the bad guy basically knows your password to every site.
I have been using the internet since the 90s, my Hotmail account is 23 years old and I have never lost any of my accounts. I think it’s working quite well in my experience.
It will, right up until the day it doesn't.
You just need one little website to leak passwords in plaintext and all your passwords are up for grabs.
I used to do the same thing and I stopped for that reason.
It should work for another 23 years. I’ll keep using my system that works.
This is one of those things that works until it doesn't, though.
or it just continues working for another 23 years. Do you have a password system that has worked successfully for as long? Just because you “feel” that it’s not good doesn’t mean your feelings are correct.
Surely a Venn diagram of HN users and password manager users is essentially one circle, no?
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.
Because it’s still quicker or more convenient to use a password if you remember it or use a password manager.
> Have it expire within 10 mins if not used
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 agree though the magic links should be the baseline default expectation of minimal registration/forgot-password effort
There are a number of sites that do exactly that.
A pattern to make signups faster doesn't make them secure.
Magic links can be more like convenience links, not secure, or security.
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.
Learning how to password effectively is something that comes up in B2B in many non trivial software.
Magic link is effectively passwordless login, behind a facade outsourced to a third party provider.
Passwords are much more actual consent, than clicking on a link in an email account that might be open on a screen or device... not always.
SSO is technically easier than poor man's sso, it's just one click once logged in. Magic links make me switch a screen to make it easier for the developers of Magic Link to not implement SSO.
Fingerprints are a username, not a username+password. It's super convenient, but well established not secure.
Face-ID logins are more a username, should not be a username+password - selling it as secure is not ideal, but it is super convenient.
SMS verifications too, are a little weak, since SMS' generally are like post cards. But they are very convenient. Until someone does something to get malware into your phone, or your phone number itself which seems to happen so often.
Now, magic links are very convenient. And definitely can remove friction to you know, get a user onboarding to the point of adoption.
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.
I agree this is a great way but don’t forget not everyone is signed into email on their device.
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.
Not true, you can use FIDO2 keys. You can even use SMS (but you shouldn't).
Yes, it is true. There are indeed cases where you are not presented with SMS options.
And I'm not going to purchase and carry around a hardware key just for the privilege of periodically logging into my Apple accounts.
Maybe Apple shouldn't force you to own an Apple device to login to your accounts? They've been sued about this before and lost. If Microsoft did this, people would lose their minds.
>why they do this
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.
Preach. I'm tired of platforms nannying me with session limits and forced 2fa. Just have toggles in the settings
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.
Don’t look at FAANG as examples, they are usually the leaders in modern day bad UX.
> 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.
It means the site doesn't store your password, so you have less to worry about.
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.
If it’s only doing it because of your VPN, I think I’m talking about something else.
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.
Or maybe password managers need to catch up with this newly forming flow
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.
Or this stupid flow needs to die.
Perhaps, a password manager managed email address used solely for these stupid links and codes.
Why email then? Why not some other, better protocol?
Why not just use a TOTP at that point?
> Why not just use a TOTP at that point?
Friction. When the username is an email address, 100% of people logging in have an email address. Telling someone they need to setup TOTP, especially if they have never done so before, is going to be a bridge too far for something they may only use once or twice.
One site I remember using this email code login was a small online store. If I was prompted to setup TOTP to buy something, I would have probably not bought anything. If my mom was prompted for that, she’d end up calling me, and I’d have to try to walk her through the whole thing… then I’d keep getting calls the next 5 times she’s had to login.
If the site gives directions on what to do, they will probably only be written targeting a single authenticator app. For people who don’t yet know that the apps are generic (in most cases), this can lead to a user having 3 sites setup in 3 different apps. It can become a mess very quickly.
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.
I’ll be hyperbolic and say the login flow is identical.
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.
Who copy and pastes from a password manager?
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.
> Who copy and pastes from a password manager?
People who don't use something which integrates with the browser. People who run into the (uncommon but noticeable) edge cases where the password manager decides to not auto fill the password.
When it doesn’t work I get. I run into that from time to time.
But I don’t think normal users want ones that don’t sync or integrate with the browser. I believe you can turn both off for Safari but that defeats the whole purpose in my mind.
> Who copy and pastes from a password manager?
I do! And way more than I would like, because for some reason it's "modern" to have a login flow that first requests your email, and then you have to click next for it to request your password...
Not even gonna go into detail about all the other cases like websites that have such bad field identification that the password manager has no clue where to put the username/email or 99% of sites that don't have autocomplete="one-time-code" on the 2FA field so now you have to copy paste the 2fa.
Plus all the android buggyness where the auto-complete from the password manager just doesn't show up at all so you have to switch apps and copy/paste the credentials manually... when it works (and doesn't clear the fields as you swap between apps... I swear built-in chrome windows is a mistake).
> And way more than I would like, because for some reason it's "modern" to have a login flow that first requests your email, and then you have to click next for it to request your password...
There's a reason for that, and it's not because of 'trendy', it's because the backend will examine the email address and decide which password authentication mechanism the user chose: FB/Google/etc, or authenticator app, or plain old password, or some third-party SSO provider, etc.
Keepassxc's desktop browser extension allows you to specify the username and password boxes. Even if they are on separate pages. It's really a painless 15 second process.
I have to do it on my bank's website every few months.
Yes, that is a nice solution.
I suppose the reason is because the Bitwarden option is cross platform and I don't want to sync two password managers.
However when using Bitwarden the recent guidance is to turn off autofill[1] but even with it enabled it sometimes breaks hence my “seldom” caveat.
I am heavily biased to prefer passkeys but as with magiclinks before them saw the rollout was badly botched. Specifically with regards to supporting multiple keys and revocation[2][3]. The standard supports correct implementation but don't require it; meaning most current rollouts are half baked and will remain that way.
[1] https://flashpoint.io/blog/bitwarden-password-pilfering/
[2] ie: https://www.reddit.com/r/yubikey/comments/14h0d7y/single_key...
[3] https://news.ycombinator.com/item?id=40165998
> Who copy and pastes from a password manager?
Me. I don't know of any other LAN-only method that works consistently across my various desktop and mobile devices.
okay, but you're using xclip/pbpaste/equivalent, yeah?
Ctrl-C and Ctrl-V work consistently on Windows + Linux. For Android, almost same experience with KeePassDroid that shows notifications to Ctrl-C the user and the password.
> Who copy and pastes from a password manager?
I do.
I’d prefer my passwords, foundational identity documents, and other sensitive information are as separate as possible from the place where I execute untrusted remote code a bazillion times a day. Making it programmatically available is the opposite of separate.
Me, every time another site annoyingly breaks autofill, sometimes even intentionally ("Password managers not allowed! Make sure to memorize your password, but still use at least 5 special characters and include at least 3 titles of ABBA songs!!").
TOTP is not really something that would be sent to your email. The entire point of TOTP is that you can generate the auth code yourself, from the current time and a pre-shared secret.
I think the OP meant OTP. The general concept of one time passcodes, not TOTP as per RFC 6238
With greylisting, the flow B could take like 10 minutes.
> 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.
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.
Doesn't your browser remember your passwords?
my wife chooses not to let chrome remember her passwords because she thinks it's lazy and insecure: everyone uses chrome, how will chrome know not to give her password to someone else?
But she is right, unlike your password manager the browser has to store it unencrypted because nobody bothers with setting the master password.
This flow is made shorter if you have the TOTP stored and filled out by the password manager.
Their motivation is immediately clear to me. If you use "I forgot my password" you don't have to remember a password. And it doesn't even make your account less secure, since that pathway was going to be available to attackers regardless. I've seen websites that make that their default flow, arguing (implicitly) that having passwords at all is pointless when you can just email someone a login button, skipping a step.
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's not "2FA" if the second factor is the only one I need
It will be 2FA again if you protect your email with 2FA
I used to follow this process for many of my logins (the less critical ones) before password managers were mainstream, and it was a conscious decision to do so.
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.
When I ask people why they do this, they either don’t have an answer, or respond with “huh, I never thought about why”. And that’s interesting to me.
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.
> work on a shared cloud pc
That sounds insane, is that actually happening in practice? What is the point?
“It offers a guaranteed, repeatable, low-effort solution”
Doesn’t this answer the question? I would have preferred to read and discuss what they believe to be better alternatives.
> whether we can take advantage of people’s tendencies towards learned behaviour like this
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... ...)
Because websites used emails as an identity, strictly in order to stop malicious use.
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.
Too many don't actually verify the identity. I often get emails lying in the footer with something like "you are receiving these emails because you signed up" - no I didn't, someone else did, and you didn't check. But fast onboarding is king, right?
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.
A few services are just bypassing passwords and emailing you one time codes these days and it isnt the worst idea for exactly this reason.
I agree, but I strongly prefer the ones that allow both. I use a password manager, and a mandatory OTP email flow often annoys me enough that I think twice about logging in if it's not that urgent.
With email being the source of identity on the internet, it's really unfortunate that the standards have largely lagged heavily behind when it comes to stronger authentication algorithms. Why is SMTP still plaintext on port 25 for MTA<->MTA? Why is STARTTLS really the best we can do? Why do we not support 2FA or mTLS or passkeys or any one of the other modern authentication mechanisms or IMAP4, SMTP, etc.. ProtonMail is ok but the hoops they have to jump through to get their stuff working is obnoxious.
And why, in 2024, is requiring any encryption at all a violation of RFC 5321, thus making any MITM literally a trivial and impossible to defeat downgrade attack?
Worth looking at MTA-STS. I think DANE is on the way out, but it looked promising for a while.
I never thought of using password reset as a permanent authentication method. Ingenious!
Except when the service throws you back to the login page to authenticate with a fresh password you just typed in the reset form.
Plenty of services do this already, right? It's called "Magic link" login. Am I missing a subtlety?
In my recent experience it's 50/50.
I wish sites would acknowledge the need for a nerd mode that gets rid of all the stuff that annoys nerds and is essentially password or lockout, no resets. Enable reset methods or 2fa at your own whim.
For the rest you can do weird stuff that doesn't work on nerds.
> What if we could somehow design systems so that the people who use them evolve to use them in better ways?
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.
I swear the McDonald’s app for the U.S. works like this on purpose. I’m prompted for my email then thus send me a link. They never ask me to set up a password.
I don’t see any business who wants to stay in business blocking gmail or outlook.com or yahoo or proton mail
Somewhat related discussion from yesterday: https://news.ycombinator.com/item?id=41468486
It’s because password sucks.
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.
This is why I've been relying on magic links via email as a sign-in/up method for my applications. Users will either default to oAuth OR they will use some generic email/password combo. The magic-link works for both sets of users and ensures that they always have instant access without having to manage yet another password.
Disclaimer: I loathe this pattern & hope something like WebAuthn prevails instead.
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?
A good email login flow is where I put my email and then my password then click login. Anything else is pure wankery
Interestingly enough, that is the login flow Figma is using with my account. I provide my email address, and get an email that contains a linkt to log me in.
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.
> 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.
Wow, that's awful. So they abuse "forgot your password" as a login method, with the added obstacle of having to come up with a random password every time. And they don't see any problem with it. My hunch is that all these people are very non-technical users.
I do that for some sites. It's the initial effort required to set everything up that's the obstacle. This kind of behavior is taking the easiest route at every step instead of investing time into making the future easier. I stopped using a password manager after it got hacked and haven't bothered setting up a new one.
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 can save you some of that research. The KeePass family of password managers are open source and based around a shared file format. They save your passwords in an encrypted file on your computer or phone’s local drive. An ecosystem of apps by different people can parse that file format (after you enter your master password), and at least one app can export as CSV or HTML, so migration is not a problem.
Since your passwords are in a local file, there is no online password manager that can be hacked. If you worry that your local password manager software will have malicious updates posted, you only have to read news at the time you download an update, which can be as infrequent as you like.
If you need to share passwords among your devices, you can store the encrypted file in a generic file syncing service such as Google Drive or Dropbox. Those services are less of a target for hackers than dedicated password managers, and even if someone obtains that file, your passwords will be safe as long as your master password is strong.
Specific KeePass clients I recommend: https://keepassxc.org/ on desktop, https://github.com/PhilippC/keepass2android on Android.
> 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.
These are pretty much the exact reasons I created https://github.com/conradkleinespel/rooster. It's a simple password manager for the command line. It's offline. It's open source. It's stable. It can export passwords to plain text in different formats.
And its feature-set is intentionally limited, so I can maintain it with little work, to avoid it going down the gurgler. It's been available and maintained since 2015.
> When I ask people why they do this, they either don’t have an answer, or respond with “huh, I never thought about why”. And that’s interesting to me.
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.
Exactly, that should be obvious but it's just that they don't care enough.
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.
This one is easy:
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
Recently I have a harsh experience with my AWS account. I made a dumb thing, my email inbox is registered under a domain, and somehow my domain's MX record is gone and I can not receive email from AWS to authenticate to the right account to fix that MX record. So I am permanently banned away from that account due to the policy of AWS
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.
Some apps enforce this flow, e.g. there is no way to log in with a password. I hate this.
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.
Amen, yes. Greylister here too, and password reset/magic links sometimes end up being painfully slow.
Your greylist setup really should learn good senders quicker; this shouldn't be an ongoing problem.
This is why I skip the password step altogether.
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.
As long as the email account is secure, and the throw-away one-time passwords are good, you have the frequent-rotation passwords security advocates dream about. Indeed, hand them a secure password they have to use (and forget).
I just made it an option in the "I don't have a password" form that instead of setting a password it just logs them in. So they don't even see / have a password to remember.
> and whether we can take advantage of people’s tendencies towards learned behaviour like this.
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.
Login and authentication are a really big deal, and represent some of the most complex code, in one of my apps.
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.
You posit a good question but it would be interesting to take a step further and discuss some potential alternatives, or expand on why "email is authentication" is/isn't the best option there is.
When you sign in at Home Depot, it defaults to sending you an email that you can click to sign in. And I absolutely hate it.
There is a tiny link at the bottom that allows you to sign with a password, which I prefer.
medium.com too... I hate it
For seldom used (or cared about) accounts, this is pretty low friction, and most of those will keep you logged in for an extended period of time.
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.
Identity is tricky. Proving who you are depends on a certain level of trust. Whether it's through email, devices, phones, or, in more advanced settings, some sort of digital certificate; you won't have much options.
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.
Sometimes email is the best way. Like if you are constantly posting files to third-party file hosting services (Box, Dropbox, etc.) that are not tied to AD of the recipient you have to have a way to ensure that only people currently working at the company can access the content. SMS and TOTP do not solve this problem in the same way that email does.
The problem is just that despite all the advantages it would bring, people won't pay for auth as a service, where your identity is tied to accounts outside of an email address, and you (say) get a browser/phone notification to log in when you log in with MyAuthProvider and it's quick. They'd rather go through the email route, which is the same thing but slower and goes via Google.
booking.com natively supports this "email is authentication" pattern, so you even don't have to change your password and come up with a throw-away password. They just send you a link by email, you click the link, and you are logged in.
The second component of this, for people that doesn’t care to do good track of their passwords, is that their email passwords are usually memorable in the wrong way. So both your mail and all the dependent services are all held together with the same weak clip.
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 second component of this, for people that doesn’t care to do good track of their passwords, is that their email passwords are usually memorable in the wrong way. So both your mail and all the dependent services are all held together with the same weak clip.
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.
Email passwords is interesting one. As my feeling with something like gmail is that you insert it approximately once or twice per device... Which leads to weird dynamic that you have to recall it way too rarely for actually to remember it properly...
> I think people can’t answer why they do this because it’s not a concious decision
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.
Any strong 2 factor authentication without the kind of high touch processes that a bank can afford is a corporate suicide pact. 10% or so of your users will be permanently locked out each year and once you get past the early explosive early growth phase that turns into a near steady state instead you get radioactive decay.
I use this for webpages that have weird requirements for passwords. I can never remember what I enter on those so …
If passwordless sign in is good enough for Booking.com, it’s certainly good enough for any app that I ship.
I'm surprised we don't have a standardized, cross-browser, simple, email-based authentication system.
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.
Well you kinda reinvented passkeys.
And then you are blocked by google.
The most common login process in China:
1. Enter phone number to received a six digits code 2. Enter the code
The thing is, the moment some service allows you to recover your password through email, this becomes a legitimate pattern. As long as the throwaway password is reasonably complex, the service becomes as secure as email can be (which is, imperfect)
This is actually a really good use-case for PGP. Opt-in use to upload the pubkey and, if provided, encrypt automated e-mails like auth links and password reset.
Facebook supported this for years, not sure why they recently deprecated it.
At this point, wouldn't "email authentication" simply be OpenID?
User researchers are great at making these kinds of discoveries. The basic idea is that you've got to actually watch a user when they use your site, ask some questions about what they are seeing and thinking.
How do you deal with the situation that you lost access to an email address (e.g. change of employer) and years later you want access to an account that turns out to be tied to that email address?
not sure i get what this article's point is
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
This is essentially the same as "sign in with Google / Facebook / etc." with added pain for the user.
at least for my privacy conscious web apps I don't even expect email for login, just a username and password.
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.
If I launched a startup I would absolutely use magic links for auth. Minimum friction for users.
As a user, I hate it.
In general, I really am disturbed that so many websites use my email and phone number for authentication. I use authenticator and password manager apps for a reason. Using my email and phone number is both unsafe and was never approved by me. They just started doing it. Further, there's no way to turn it off.
A lot of sites are moving to OTP instead of passwords now.
Make Auth Gmail’s problem.
It’s not a horrible idea in theory.
People have already been building auth flows that take this password amnesia into consideration. Look at Anthropic. It's just one way of doing auth and I personally hate it.
Anthropic and others do this to inconvenience account sharing. It’s not really about auth, it’s about licenses…
There are much smarter ways of doing this.
I use a password manager. I don't like flipping back to my email, I already have a secure password.
The most secure password is no password
Totally agreed. The account though, that's another question. Would you mind sharing the username of your favorite passwordless account?
Personally, I don’t care to share the username to any account, password protected or not. On a related note I think it is terrible security to have display name be the same as user login name.
Same here! But for most apps we are probably in the 0,1% or so.
A physical key you have put in your computer and store on your keychain.
And if you lose / damage that physical key?
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.
That is true, there is no silver bullet. For the people like me that know and have multiple keys in multiple secure locations are probably mostly fine, other solutions on government och bank websites is that they need somekind of formal verification before giving you a new key. There are always tradeoffs regardless of solution, depends on what you value.
I am one of those people who always clicks "forgot password", and sorry but it's actually fine. I type a long, completely nonsense sequence of words and characters for my new password, then ctrl-c to copy, then log in with that password, and then promptly forget it.
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.
you may lose the email
I only do this on websites where I don't care if I lose the account. I use a password manager for anything that is critical.
you could make a password optional and just login from email.
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.
I think it should be entirely oauth. no password needed
There are two (deep) thoughts about this article.
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.
What are the other potential problems of the "email is authentication" pattern, under the following prescribed conditions? Maybe just these two?
(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.
- End-to-end response time for the "Credential Recovery" authentication process (Non-problems)- 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...
Well, yeah, “magic link” is a thing and one of the easiest form of authentication supported by many providers, like Supabase, Vercel and libraries like Next Auth.
Another great side effect is that your backend doesn’t have to store user passwords which means removal of a lot of compliance headaches.
You should never store passwords in any case. Hash + Salt.
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]
[flagged]