> Often this will be combined with fallacious notions such as “remember this device”, the idea being you only have to go through all this the first time when logging in from a particular device. This idea is fallacious because the web has no notion of a “device”, and this is a very intentional design choice made for privacy purposes. We are literally living through the gradual phase-out of third-party cookies, amongst other functionality, specifically to try and prevent this sort of thing, so why do web developers persist in believing in this fiction of a “device”? My own browser erases all cookies from an origin immediately after the last tab from that origin is closed, so these sites are convinced I am logging in from a new “device” every single time, and then demand I respond to one of these challenge emails.<p>The phasing out of third-party cookies has nothing to do with the "remember this device" functionality, because those are almost always powered by first-party cookies, which are <i>not</i> being phased out.<p>The author has configured their browser to throw away cookies when the last tab closes, and that's their prerogative, but anyone who is savvy enough to configure that setting is also savvy enough to understand that that will break "remember this device". For everyone else, that phrasing is a perfectly reasonable abstraction on what is actually happening.
We probably will stop one day, but that day isn't yet for many services. There are people who would be unable to use those services if that can't set the password to either the same or a variant of one they always use.<p>In the tech wold we often forget that there is a wide disparity in people's ability to use tech. Take my father, there is no way he could use a password manager, or two factor, it's just never going to happen. He has a notebook of passwords, that's how he works and he won't change.<p>We cannot change everyones behaviour, no matter how much it would be better for them. That's a very well learnt lesson, over and over.<p>The world in 30 years time will be very different, the eldest generations will have grown up with passwords and the internet. Many will have been using password managers, 2 factor, other authentication systems and devices for much of their lives. It's going to be a slow, trickle down change, from "high tech" services down to everyday sites and systems.
I've said it before and I'll say it again (and yes let it rain downvotes):<p>I don't understand this whole discussion and maligning of passwords.<p>You cannot save all people. Some fixed %-age of people will always become victims - either by choosing a terrible password or by being shot in the foot by some terribly complex 5FA device-based passphrase scheme that attempts to protect them but ends up betraying the user once they replace their phone or it breaks or for any other mundane reason.<p>User picked passwords (1FA) are and will always be the single best solution that has ever existed for authentication, considering everything from security to usability and practicality, wholistically.<p>If I sign up for some crappy service that I'll barely even remember a week later I should be good to go setting my password to "asdf" and that's everything I need to log in.<p>Fuck everything else.
<a href="https://news.ycombinator.com/item?id=36717356">https://news.ycombinator.com/item?id=36717356</a>
> This step is commonly something like “enter the code in an email we just sent” when trying to login.<p>Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token <i>does</i> expire, right?<p>> We are literally living through the gradual phase-out of third-party cookie.<p>Yes, and a "remember this device" uses a first-party cookie, so it isn't affected.<p>> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed<p>So you are intentionally breaking the web and complaining that things are cumbersome? Gee, I wonder why.<p>> [..] yet that same website is happy to let me authenticate using an API key for API access as a single authentication step. No “2FA” here.<p>Yes, because that API key is often used to <i>sign</i> the request, contains enough entropy to make guessing impossible, and because the URL is hardcoded in the app phishing is impossible.<p>> guaranteed use of a high-entropy secret obviates the need for additional authentication<p>No, it does not. See: phishing.<p>Forcing the use of website-generated passwords is cute, but doing basic entropy checks on a user-provided password pretty much solves the issue anyways. Why bother alienating a significant fraction of your user base?<p>Authentication is pretty much a solved problem. Use a password locker encrypted using a single remembered key for the "something you know" part, and use a physical Webauthn token for the "something you have" part. Stop trying to reinvent the wheel, it'll only end up annoying your users.
There is an overwhelming amount of superfluous text in this article.<p>The author's solution:<p>> Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using the same process. The user cannot choose their password, but can get a new randomly generated one in the event of compromise. The password essentially becomes indistinguishable from an API key.
> <i>API keys are used to secure the highest-stakes APIs that exist today — all of AWS's services, for example. Yet while API keys seem to be considered an entirely reasonable and industry standard design approach,</i><p>This is not actually true. API keys are highly disfavored because they are easily stolen, and these days if you try to create an access key in AWS, you'll be shown a screen called "Access key best practices & alternatives" which tries to get you to use something else (such as temporary credentials from the EC2 metadata service). There's even federation between providers now, so for example if you need to access your AWS account from a GitHub Action, you don't need to use API keys (<a href="https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services" rel="nofollow noreferrer">https://docs.github.com/en/actions/deployment/security-harde...</a>)
> Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using the same process. The user cannot choose their password, but can get a new randomly generated one in the event of compromise. The password essentially becomes indistinguishable from an API key.<p>GitHub does this now. you cannot push with your normal password, only a Personal Access Token. I am fine with this, but perhaps the process of setting and getting the token could be streamlined. Currently, you have to:<p>1. click profile<p>2. click settings<p>3. click developer settings (the last item of 24 items)<p>4. click personal access tokens (again the last item in the list)<p>5. click tokens classic (again the last item)<p>6. click generate new token<p>7. click generate new token (classic)<p>8. enter password<p>9. click confirm<p>10. enter note<p>11. choose expiration<p>12. choose scope<p>13. click generate token<p>thats just way, way too many steps for the average user.
Because for the average user it is still significantly easier to download some app to use in combination with a password they have a mnemonic for rather than having to figure out their own system for storing and retrieving long tokens in a reliable way. Also, most users are not obsessively clearing out their cache, so device recognition based password flows work seamlessly a lot of the time.
The company I work for currently gave me my password, comprised of four space-separated words, on my first day. It has no expiry and can only be changed at request or if compromised.<p>My only gripe with this approach is that my specific password is a bit awkward to type. I tend to pick passwords at least partly based on "keyboard feel" and it's annoying that there's one word that has a lot of repetition of colocated letters.<p>Other than that it's a fantastic model and hugely preferred over routine password resets.
There is one incorrect statemement that really bothered me<p>TOTP and passwords are not the 'similar' because TOTP is a secret generated from the 'key' and is only valid for a short time period<p>this make usage of that secret vastly more challenging for attackers, especially at scale.<p>I've seen real attacks where passwords are stolen, it is impossible to keep track of that. However for TOTP since the attacker has to login NOW, you can very easily detect anomalies of a new IP addr with many successful logins for different accounts<p>Or to put it differently, when you capture a password it is always valid credential but for TOTP, it requires more advanced infrastructure(automatic logins, save tokens)<p>and even then the token will eventually expire, with password you can generate infinite tokens
If you want api keys to replace passwords then users need a built in mechanism on their device that stores it, since the majority of people are not going to be able to or want to copy some long obscure token and store it somewhere for later access. Some devices already have password managers and similar mechanisms built in, but it needs to be universally implemented and accepted before you could do something like this. Then there's still the question on do you share the api keys across devices?
The advice on passwords very much depends on the level of control that a system operator has on its userbase, and the threat model of the site.<p>In an end-user B2C style website, whilst passwords (and MFA) etc are needed for Authentication, the operator has limited control over users and if you annoy your users too much, with things like mandatory system generated "high entropy" passwords, they'll stop using your site (assuming there are other options available).<p>In a corporate style service it's different as the operator can mandate things like the use of MFA and the use of password managers.<p>I've seen systems that did the "system controlled password" thing in the past and, if done incorrectly, it just leads to users writing their passwords down somewhere (e.g. sticking them to a post-it note under their keyboards).
Usernames and passwords are effectively obsolete in China.<p>It's a combo of:<p>* All accounts need to be tied to an identity, generally in the form of a Mainland Chinese phone number which is linked in the backend to a Government ID/Foreign Passport<p>* Mobile first development where mobile is assumed to be the primary or only way to interact with most services.<p>* Overwhelming dominance of two 3rd party identity providers (WeChat and Alipay)<p>* WeChat mini-apps taking over most of the small use cases where authentication is baked in.<p>The usual flow is that you sign up with a phone number as your username and authenticate with SMS 2FA. Because it's a mobile app, it doesn't have to deal with web bullshit and actually remembers you across sessions spanning months. To reauthenticate on a different device, you just enter your phone number and use the same SMS 2FA to login.<p>The web flow for a lot of sites is that they require you to open the logged in mobile app and scan a QR code to login on the web.<p>A few legacy sites like Taobao still support password login but they're by far not the majority.
I like this article because it forces us to recognize what secure users are really doing already. I haven't created my own password for something in ~8 years, since I started using LastPass and 1Password. I have no idea what my password is on any site, never see it, can't even type it on a keyboard reliably.<p>Looking forward to them being replaced with passkeys.
Login PIN by email is a much better pattern along the same lines. Forcing a specific, impossible to remember string on the user is weirdly hostile.<p>If you want to avoid a password, just email the user a PIN every time they need to login. This works great for apps which don’t need high security.
I've often been struck by the fact that often login via password requires 2FA but password reset doesn't (unless of course it works via email that itself requires 2FA to log into). At least some authentication systems now never bother with persistent passwords at all and simply rely on you providing a code sent in each login to your email (or occasionally still via SMS - though that's rapidly falling out of favour, at least partly because in many countries SIM-swapping a significant problem, though the bigger problem I've observed is potential delays of several minutes for codes to arrive). But I certainly wouldn't want that for systems I have to log in into multiple times a day - a combination of browser-auto-filled password, plus use of basic browser fingerprinting techniques to avoid having to require 2FA every time seems to work okay though it seems ridiculous to me that just wanting to reply to a group chat message would require the same level of verification as downloading source/documentation etc.<p>A compromise between allowing users full control over their passwords and none at all would be generating a list of permitted alternatives and having them pick one. What I'd then like to see is that early on you are required to supply it quite frequently, giving you a chance to commit it to memory, but then allow having the browser store it or session cookies with longer lifetimes be used. But I've yet to come across a login system where ensuring the user learns their password and doesn't forget it was a priority at all.
There are better solutions perhaps, but this article (as many others here have pointed out) reads as if it were written by someone that just "graduated" from a security bootcamp and thinks that they have some earth-shattering revelation to share.
>The only discernible difference between TOTP and a site-generated password is in how knowledge of the secret is proven. With TOTP, knowledge of the secret is proven without sending it to the website. With a site-generated password, knowledge of the secret is proven by sending that secret to the website.<p>The whole point of a passphrase is that IT DOESNT CHANGE HANDS EVER.<p>The reality though is that computers subvert the system of passphrasing because the complexity required for passphrases within a computing systems is easy for computers to beat but hard for people to recall<p>So you have a perfect situation where the historical context is maintained (person will remember their self-generated passphrase) but the system also can probably guess any passphrase that a human could remember without any additional tools<p>So now, given that we REQUIRE more complexity than people can recall, we force people to use additional tools for creating/managing their passphrases which subvert the entire principle of a passphrase. Namely:<p>IT DOESNT CHANGE HANDS EVER<p>So the whole system is corrupted at it's root and there is no way to solve this problem with the current structure
I play a japanese gacha game and there is no password there for your account. If you want to login they send you a code to your email and then you use that (valid for 30 seconds). I'm not a security expert but I always liked that for some reason
A long time ago I wrote a variant of this - the signup page would generate a token, place it in a hidden password field, submit a hidden form, and instruct the user to click the "Save password" dialog in their browser. One advantage of this was e.g. Chrome would sync the password immediately across all your devices (in some ways this was a privacy violation, although one that the user had to explicitly opt themselves into). New sessions (e.g., if you reset or lost your browser's stored passwords) still happened via email verification, though.<p>Today I would just use passkeys.
Great post, I came to much the same conclusion when building my app - a secure token is generated on account creation and users are encouraged to save it in case the need to restore their account. I blogged about the implementation below together with how the UI looks (under the "Authentication" heading):
<a href="https://khromov.se/building-a-privacy-friendly-self-hosted-application-architecture-with-sveltekit/" rel="nofollow noreferrer">https://khromov.se/building-a-privacy-friendly-self-hosted-a...</a>
Lmao this guy deletes the cookies to log himself out every time he closes a tab and then has to do 2FA every time he uses any website and he thinks it is the system that is wrong.
I'm not going to use your service if I can't set my own password and be the one to decide if it needs more than just a password. The services I spend most of my time on and have vulnerable data on use 2FA, but the <i>majority</i> of my accounts do not. My accounts for downloading Super Mario 64 romhacks or posting comments about barbecue recipes aren't going to get entries on my Authenticator app nor do they deserve one.
I wonder if “true multi factor” security requires exclusivity between each factor. So, you cannot “know” anything about the “thing you have”. It should be more like a yubikey that you plug into your computer and which is secure enough that you cannot get the information out of it to “know” it. That’s a little harder to do for the “thing you are” factor because we can’t design a system to use a feature we can’t understand. And maybe we shouldn’t really “have” the thing we know, as in, it shouldn’t be recorded in something we have. Of course that makes it easier to forget. But then again, I don’t have my 1Password master password recorded anywhere. If I forget it, I’m pretty fucked.<p>I’ve often considered moving that master password to the frontier of email access and just never recording a password and using password reset for every login session.<p>Regarding API keys vs passwords, a difference is that API keys are something that are used on your behalf by automated systems, whereas passwords IME are always something you manually input at the time you need it.
The author has enough knowledge to be dangerous and shouldn't be allowed anywhere near an authentication system.<p>The first diatribe against 'nondeterminstic' logins demonstrates a naivety to both account takeover and botting mitigations.<p>Passwords have to be assumed to be low entropy long lived credentials which are horrible from nearly every standpoint.<p>API keys at least have a high entropy but are long lived and difficult to secure. (How many times do we need to see apikeys accidently leaked in a pull request?). They also do nothing from a phishing perspective.<p>OTP is a high entropy and the authenticated credential exchanged has a very short lifetime. The exchanged credential may also be much shorter. It is still susceptible to phishing mitm attacks.<p>Thankfully it's 2023 and webauthn is here for the browser. We can keep long lived secrets in a secured environment, be resistant to phishing and if the risk model includes physical loss of device utilize pins / passwords even if they are low entropy.
I had a very different idea of what this article was going to be about before I read it. Since the article is kind of an irrelevant rant, let me share what I thought the title was encapsulating:<p>Corp policies asking users to change their passwords every 60 days or whatever, combined with the ever-more-arcane password content requirements -- yes, why the HELL are you asking me to change my password? I'll just go to one of the online passgens, generate a string, and immediately save it in a text file in my local home directory, because there's no way I will remember it.<p>Might as well generate passwords for your users already. Don't email me asking to come up with my own, send me a link to a form where I can copy the new password from.
I'll ask, in the corporate world. Why even allow them to know their password. To login to their device a Yubi Key or Door key could be used (or similar) then once logged into their laptop they have an app the works like 1password or lastpass that inserts their passwords, updates their passowrds etc. for everything the company uses. (If they have a reddit account that is non corporate they could use their own pw manager.) This would also solve the "shared password" issue where a company that has a corporate Twitter account, they control access to the credentials and the credentials. Also gives you a paper trail in that you now know who used the credentials at the time of a post.
I guess the author doesn't know but setting password for users used to be more common. They would put it on a sticky under their keyboard or something(i did it myself too and I was in IT at the time, didn't give a shit, getting locked out every other day was affecting my perfrormance/metrics).<p>The latesr NIST guidline is goes further by eliminating password complexity and focusing memorable high-entropy passphrases. This is a "what you know" auth factor, even with password managers in play, the master password for that or for your high-impact sso password (work sso that can access everything) should ideally be stored only in your head.<p>But if the author insists, users should be given printed password books and enable MFA.
I think there are two approaches to the issue:<p>- You consider that the user getting their account pwnd is their problem. Let them set their password. That includes things like forums and other websites where an user losing their account is not critical and you can easily just tell them "too bad, use a better password next time" if something goes wrong.<p>- You consider that the user getting their account pwnd is going to be your problem. You're a bank, or some paid service for instance, and the user will ask for support if they lose access to their account. In this case it 100% makes sense to force a password on the user to prevent them from selecting something stupid IMO.
> A given website might obnoxiously refuse to trust in my ability to set a secure password, assume the 24-character randomly generated password I keep in my password safe is insecure, and demand I complete an email challenge every time I login<p>...because it's easier and cheaper to apply one rule for every user and you're an outlier. Most users don't have password safes - they have passwords like 'Messi123' that they use across multiple sites, and therefore benefit from a second factor since their first factor is more or less non-existent.
> There's not really a good reason for a user to be able to set their own password unless they want to set their password to something lower in entropy to make it memorable, or reuse it between sites, both of which are deviations from the “best practice” password safe usage model.<p>Yeah, but at the same time if you keep loosing access to your accounts because you can’t remember your password, you are just 1FA with your email or phone number. Might as well then skip passwords entirely and use sign in via phone or email.
There are some who claim that people will demand a way to set their own passwords. This has not been my experience. At work, we have been setting random secure passwords for e-mail and web site customers for more than 10 years (the practice was in place before I started, so I can’t give an exact time). Very occasionally, a customer asks to change a password and give them a new one, which we gladly do.
For a login situation with extreme rate limiting (say 3 tries a day) "high entropy" might not involve a lot of randomness. A random 8 character password handed out to a user is overkill. Two random words is overkill. Heck, a single diceware word would take 7 years to guess in that environment. For 100 years you only need something like 4 base32 characters.
I prefer so called “passwordless” systems that use a combo of magic links and 2 factor authentication. I do think passwords are an outdated modality for non local accounts, most of the time.<p>If anything they should only be used for resetting the account coupled with successful use of a 2nd factor, I suppose, but recovery keys aren’t a bad compromise depending on the user
This article is the very embodiment of how I think about authentication! I once tried explaining to a top-brass security professional at Microsoft why mandatory, SMS-based '2FA' wouldn't be an improvement over simple passwords - they just didn't get it. I wish I could have shown them this essay.<p>Legitimising 'Risk-Based Authentication' as a strategy is a big mistake in the software industry. It allows criminals to sit on compromised credentials, trying different combinations of accounts, user-agents and IP addresses until they get the jackpot: a website decides this time that there is 'low risk' to the login attempt, and the bad actors are in. When you make security-critical decisions with statistics (in this case, whether to permit a login attempt), you are essentially guaranteeing that there will be a certain proportion of breaches, because you set the risk threshold!<p>Our efforts as an industry should be in making sure that credentials are not stolen in the first place: better and more widespread encryption, phishing resistance (with UX that supports that) and low-level security audits of encryption software and hardware are just a few of the areas where research and development would be valuable.
This is the regular reminder that you <i>can</i> create your own password, provided it's created via a secret which only you would understand. Then you can store the secret safely.<p>It can't be your wife's name, or your birthday, your kids' names, car license, or anything which someone could research.<p>We've had this discussion before.
Hmm, do I set my own password?<p>From the web site’s POV I certainly do.<p>But my password manager generates the password and remembers it for me and I only ever see it if the generated one somehow violates the site’s arcane password rules and thus requires a bit of manual manipulation. Which rarely happens.
If you know what the user's password is, then you could potentially be liable for an improper access. This liability is is impossible if you have no way of knowing what that password might be, even if things you do know like 2FA codes are used with something only the user would know.
I am thinking loudly now.<p>Nowadays, websites and apps force users to follow a certain pattern when setting their password. Since users have to comply in order to successfully proceede with setting their password, does it still count? (Count as in letting users set their own password)
hm?<p>We let users set their own passwords because users are unable to remember secure passwords, which would create a lot of work for people running the service (and the user as well), even vulnerabilities because we'd be habituated to recovering lost passwords.<p>When the user can set their password they will set an insecure one that they can remember, eliminating most of the password reset work. Then when the user is compromised it's their fault. This compromise works because most users aren't particularly vulnerable-- no one is trying, or no one cares if they are compromised.<p>Why don't we just rely on the recovery security? well Mozilla's persona thing pretty much did.
I appreciate that there is at least one other person on earth who shares my skepticism of many popular MFA implementations. A lot of them add more inconvenience than security. "We sent a code to your email" is particularly heinous.
The problem with cookies (and “remember this device”) is that the same mechanism is used for remembering things that help the user (that we are logged in) and things that harm the user (ads, tracking).<p>Edit: I’m talking about first-party cookies.
Just use passkeys. Then we can get rid of 'passwords', 'Forgot passwords', 'SMS 2FA', etc for good and make password breaches (not data breaches) a thing of the past.
> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed<p>I like this idea, but what browser config does this?
In a corporate environment, it makes absolutely zero sense to let users pick their passwords.<p>They will simple use the same login as their tamagotchi pet.
this is effectively how nostr works. you generate a public/private keypair. the keys are bech32 encoded.<p><a href="https://github.com/nostr-protocol/nips/blob/master/19.md">https://github.com/nostr-protocol/nips/blob/master/19.md</a>
Honestly, unless you're a major cloud/OS provider like Google/FB/MS/Apple, you shouldn't be managing passwords at all. Let the pros do that. You just use an authentication standard via a 3rd party.<p>If you aren't big enough to maintain your own operating system and web browser, you shouldn't be storing passwords.