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.
Average users are also unlikely to enter passwords often enough for them to remember or develop mnemonics. For them forgot password emails are the defacto login method.
The system they will choose will be to get a new token by logining in with their email.
It will effectively be the same as those places that send you a login email after you have entered your password for security or harrashment (looking at you, Zoom).
Can you specify what in practice could be an issue with a "forced" password? Are some characters harder to input than others or is it a different problem?
For the non-American aspect, it's extremely common for websites to force ASCII today (either explicitly, or because using anything else breaks in various unexpected ways) anyway, I doubt that any internet user around the globe will have an issue with that. That boat has sailed in the 90s.
in my locale's keyboard, curly brackets and the dollar sign are not obvious to input. they require an additional combo of keys that most people have no idea about.
> 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
...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.
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.
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.
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.
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.
Nobody gets to decide what's more or less sensitive. Younger generations can argue being rendered homeless due to mass housing affordability issues is also insensitive.
Ah, that’s fair. My comment is phrased as though I’m presenting a fact. Perhaps “the things which are seen as insensitive” is better phrasing.
I can agree that people are often over-sensitive but I wouldn’t expect that calling a person deadweight is likely to garner their thoughtful attention, precisely because it is disrespectful. Indeed, it would be foolish of me to expect them to start (or continue) listening to my words.
Maybe you have better luck in New York but I bet you could find people (read: strangers whom you’ve never met or spoken to) there who are personally offended when you call them deadweight. If you’re walking somewhere and you see someone whom you think is homeless, do you let them know they’re deadweight to society? Do you think one is being over-sensitive if they become offended after they are simply called “stupid”? It might be worth explaining an opinion more instead of using such terminating cliches.
Maybe because the one commenter used the phrase “insensitive opinion” there is a misunderstanding. I’m not trying to suggest that the opinion is insensitive, only the way it’s expressed. This opinion can be presented in a friendlier way, despite the topic. (It may also be worth pointing to four words in my initial comment: “regardless of the veracity”.) One can be tolerant of opinions while being intolerant of name-calling in a way that is compatible with not being the “tyrannical minority”.
It is incredibly useful to powerful people to keep at this generational war narrative, as it keeps people who might otherwise work together from doing so with an aim of crushing the power of the wealthy.
The fact is, anti-human attitudes to both housing and technology are harmful everywhere. Nobody has to "win" at the other side's expense here.
Some games are zero sum and some aren't. Everyone is more secure if a large bank replaces 2FA over unencrypted SMS, even though some may be inconvenienced.
Leveling down on everyone's security in exchange for usability for a segment of the population is not a realistic long-term strategy.
I let people set their own password. This is like canary letter for them to know if anyone accessed their data. If sysadmins need access they take it and go through a new password rotine with the user.
I also have no password requirements (other than non-blank)
I do this because I see it as user centric. I have never had a problem.
One environment requires no privacy expectation. That environment we use simple nouns all in the same category.
All the environments are full SSO they only need to login.
Good sir, if we're going for fantasy/conspirological themes, we have to go deeper than this distasteful banality.
People and technology and aristocracy are for the memes. It's just one huge anthill where the ideas evolve, living on biological (and then technological) foundations.
Power hubs (be it aristocracy or any other form of government) is just a convenient mechanism for spreading ideas - politicians and millionaries are just superspreaders (in their respective ages, but they're losing it to the technological platforms - and of course there's a struggle). So is technology. So are people. It's all an evolutionary process - just notice how designed systems rarely win, nearly always giving to chaotic blind evolution - whatever catches more brainspace truly matters, not what works best. If the memetic winds will blow in a certain direction, LLMs may make us obsolete, but not in the way we think they would.
This comment is sponsored by "You think the moon is real?" meme. Sorry (not sorry).
It is when they are all a variant of each other. I can't imagine him successfully writing down a bunch of none alphanumeric characters and not giving up.
Please pay attention to the use of pass-PHRASE. Pass-phrases are well understood at this point as far as what they are and how to generate them securely. A key point is that they’re much longer so have plenty of entropy to resist cracking attempts.
The article is discussing the merits of letting users generate their own passwords at all. So unless you can guarantee the website will generate nice pass phrases, you’ll have to account for weird characters too.
A password manager can generate nice passphrases. Really, generating a nice and secure passphrase is no different from a nice and secure password at this point. It's all about entropy and byte mapping.
Sadly you still have many sites that have stupid password rules like requiring numbers and "special characters" -- but no spaces, and no, periods don't count as special characters, and blah blah blah. Point being, the ideal of a simple phrase that's easy to remember gets thrown out the window when you have to deal with all the different rules.
I’m getting very confused about the comments here that are trivially refuted. So make a passphrase like: Correct6$Horse7&Battery and be done with it. That’s still easy to write down and remember while transcribing.
Nobody’s arguing that passwords/phrases should only be remembered and never written down or stored in a password manager. That ship sailed a long time ago.
Gonna be eagerly waiting for the time when we can finally change our behavior at will, be it neural implants or nanomachines or whatever other method of direct intervention to the brain.
> Take my father, there is no way he could use a password manager...He has a notebook of passwords
Your father does use a password manager: a slow, very inconvenient one. If you could teach him to reach for ctrl-c/ctrl-v instead of a pencil, it would be easier for him.
It would be easier for you, who (I suspect) has, like most of us here on HN, a good understanding of what happens on a computer, how to control that, how to manage their software, how to be aware of what is on the foreground when and taking input when. How to recognise various applications and seeing the difference between materially different ones that try to look the same.
Your notebook will look markedly different from a website that tries to imitate your notebook. Your password manager will only look markedly different from a website imitating your password manager if you have a certain level of awareness and acuity of what happens on-screen and what it means. I think GP's father doesn't have that awareness, and never will, by choice. They choose to spend their energy elsewhere.
Younger generations had no choice and will have spent that energy already by the time they're 12 years old, and have these problems less.
> I think GP's father doesn't have that awareness, and never will, by choice.
This! I mention password managers, two factor or just try and get him to improve his passwords and his eyes glaze over and can see him beginning to nod off. Probably somewhat my fault for always bring them up after a meal when he's probably already half way to napping...
I wasn't trying to imply an actual password manager is as easy as a sheet of paper. I just meant that a simple text document would work as well, with find and replace, and the ability to easily make a copy of it for backup.
I think you sell older people short on what they are and aren't aware of. I think it's more that they see computer technology as a necessary annoyance of the modern world and not anything helpful. They used to manage their bank balance on a ledger in the back of their checkbook, and that seems easier to them than having to sit down in front of the computer or use an app on a small screen that's constantly throwing popups in their face, either ads or little "helpful tips" about this month's new features.
I'm getting close to 60, but I've been programming and working with computers since in was in 6th grade. When I was in my 30s, paying my bills meant sitting down at the table once a month with my checkbook, stack of bills, and book of stamps. Open a bill, write a check, put a stamp on the envelope, repeat. It took maybe 15 minutes and was very easy. Compare that to opening a different website, with a different username and password and maybe TOTP code or SMS code, for each bill I need to pay. It's slower and more complicated.
There is no online payment method I've seen that seems easier to me than just writing a check. Of course I rarely write checks these days, so I use the apps and websites and feel annoyed every time I do.
I am not at all claiming that all people above a certain age have difficulty with these things! Though it is usually people above, say, 40 who feel this way — and this is not a negative thing: it may well be just because they remember that a different way existed. I.e. most people with tech difficulties are older, but many older people have no tech difficulties.
Though you are also correct that dealing with "technology" today requires a certain level of pain tolerance. Good UX exists but is rare, and authentication is still a mess basically everywhere if you don't want to do OAuth and centralise it to the behemoths. "Poweruser apps" can be extremely empowering, but always have a steep learning curve, sometimes very steep; they can help making your dayjob much easier, but typically help nought with, say, filing your taxes or paying your bills.
The first was about having difficulty, the second about not liking it. Again, the (fuzzy, approximate) implication goes only one way: having difficulty breeds dislike, but dislike does not imply difficulty.
EDIT: you are correct I didn't word my original message correctly. Perhaps you have a point.
Yeah and I do use autopay for some very predictable things like utilities. I'm not totally comfortable with giving someone access to draw from my checking account whatever amount they claim I owe, but realistically these days a paper check becomes an ACH payment so I figure there are non-zero chances for error that just cannot be easily avoided.
Well a check is authorization to withdraw a specific amount (which you can verify is reasonable) after a specific time (which you can verify the funds will be good).
I highly recommend setting up autopay via your banks bill pay system. Less organizations having your account info is a good thing, and it’s super convenient for bill tracking.
> I think it's more that they see computer technology as a necessary annoyance of the modern world and not anything helpful.
They are correct aren't they? None of the modern software is made to serve and help the user. It's made to serve advertisers and be promotion vehicles for product managers.
I am a computer guy. I am constantly and continuously irritated by all the crap in software. I see how my non-techie mom struggles, and it's several orders of magnitude worse for her.
> There is no online payment method I've seen that seems easier to me than just writing a check.
How I paid bills in Thailand:
1. Bill comes in the mail, with a QR code. Bill says I owe 413 ฿ for power.
2. I scan the QR code with my phone.
3. Message comes up from my bank saying, "You want to pay 413 ฿ for your power?"
4. I tap yes. Bill is paid.
Apart from autopay (mentioned by someone else) it doesn't get simpler than that.
My point wasn't that an actual password manager would be easier. My point was that a text document on the computer would be as easy/easier to keep track of than a piece of paper.
It might reasonably be argued that it's less secure, since it's pretty hard to hack an air-gapped sheet of paper. But it's not harder to use.
>> Take my father, there is no way he could use a password manager...He has a notebook of passwords
>Your father does use a password manager: a slow, very inconvenient one
Writing down certain passwords can be very convenient. No hacker on the internet is going to access the piece of paper on my desk.
I consider myself computer savvy and I still write down some passwords on paper instead of having them stored on an internet connected computer. (I believe burglars really don't care about passwords. And it is very easy to obscure the written passwords.)
I'd wager that >99% of all burglaries are looking for physical possessions which can be sold for a quick buck. Not looking for random notebooks of passwords. So locking it in a safe might not be optimal because it will be like putting a spotlight on it.
Something like 90% of burglaries are looking for car keys. That's why I keep my keys by the front door in eyesight on anyone who comes in. I have insurance, and don't want a thug wandering around my house.
I have the opposite approach when parking my car in San Francisco, I just leave the doors unlocked so they don't smash my window. I don't mind if they want to rummage around and find nothing but some old taco bell napkins.
This reminds me of a quote from James Mickens regarding computer security.
"Unfortunately, large swaths of the security community are
fixated on avant garde horrors such as the fact that, during
solar eclipses, pacemakers can be remotely controlled with a
garage door opener and a Pringles can. It’s definitely unfor-
tunate that Pringles cans are the gateway to an obscure set
of Sith-like powers that can be used against the 0.002% of
the population that has both a pacemaker and bitter enemies
in the electronics hobbyist community. However, if someone
is motivated enough to kill you by focusing electromagnetic
energy through a Pringles can, you probably did something to
deserve that. I am not saying that I want you dead, but I am
saying that you may have to die so that researchers who study
per-photon HMACs for pacemaker transmitters can instead
work on making it easier for people to generate good passwords."
My point being if someone's motivated enough to break into your house to steal your passwords in order to steal your life savings, that's probably an outside scenario, given most B&Es are junkies looking to score enough for their next high.
This is potentially a false equivalency. If storing passwords in a notebook is a common enough pattern, they become something a thief might start looking for. I don’t have the statistics, but would imagine that since “junkies” skew younger as a demographic, a good portion of them is computer literate (or knows someone who would be interested in buying accounts).
> If someone breaks into my house I’d rather they just got my TV and some belongings rather than my life savings
I think this is very unlikely. For one, the notebook does not contain all the information - say "Bank1 Password" - which bank is that? What's the username? What about 2FA?
Secondly, surely the whole point if a safe is that it's bolted down and hard to burgle / steal?
I find there are generally two reasons people use analogies. The first is to make a concept easier to understand. The second is to subtly change what is being argued in order to make their position seem stronger. I did the second for years without realizing what I was doing, and still fall into the trap.
Or the third to to illustrate the argument in another context.
I usually avoid analogies of HN as you are often called out on the technicalities of them. And you are right that can often damage an argument.
However, I have argued that changing peoples behaviour, even when their current behaviour is bad for them, is often impossible despite all evidence, from the beginning.
> Or the third to to illustrate the argument in another context.
This is still case 1.
I actually agree with you that some people with bad security habits will never change their behavior, but do you really feel that someone using passwords in a notebook because that's what they're comfortable with is in the same class of behavior as someone addicted to nicotine?
Feel free to have the last word here. 1 on 1 HN threads more than 3 deep rarely result in productive conversation. Cheers
I find there are generally two reasons people pick apart argument structure rather than deal with an argument's content. The first is to point out fallacies or rhetorical devices which are invalid or illogical. The second is because they realize their position is too weak to confront it directly.
You don't seem to be 'simply' doing anything. Everything you have posted besides the first comment about phishing is some kind of dodge which uses obvious manipulation tactics, for instance saying 'I do that myself sometimes', which is a cop method for encouraging confessions, or 'you can have the last word' works to actually let you have the last word. Stop doing that.
You're ascribing a ton of ill will here, and I hope you'll give me a little more grace, but on the other hand maybe there is some truth to your words. I'll see if I can communicate more clearly and authentically in the future. Thanks for the opportunity to introspect.
* to respond to something you don't agree with, in this case a metaphor, perhaps just write "I don't agree with that metaphor" or "let's stick to realistic examples"
* try not to dissect motives unless necessary. The person you responded to made a good point that people will do things against their interests out of habit or convenience -- why does use of a completely legitimate tactic need to be singled out?
* technical people who work with non-technical people (or even who deal with non-technical families and friends and children) are highly accustomed to describing things in simple metaphors
I realize that I have been uncordial and somewhat aggressive with you in this instance, but it made me particularly irked to see someone profess such an amount of self-awareness while showing a profound lack of it.
Either you are (a) just not in your groove mentally at that moment, (b) not as centered as you like to think you are, or (c) playing some kind of game, either consciously or unconsciously. Either way I figured my approach would get a response and hopefully a correction.
I look forward to our next encounter and genuinely hope it starts off on a better footing because you seem like an interesting person.
> Take my father, there is no way he could use a password manager, or two factor, it's just never going to happen.
Have you tried the “passkey” integration on Apple devices? If so, do you think your father would be able to use that?
To me, it seems such a simple UX that I can’t imagine even the most technically illiterate being unable to use it. In the Apple ecosystem, there is literally no configuration for the “password manager” it’s just integrated into the Apple Account. You’d go from a notebook of passwords to just one (the main Apple ID password, for recovery etc).
Obviously “passkey” is not available in most sites yet, but I imagine that once it is, the switch might be pretty painless for the non-tech savvy. Assuming the other device manufacturers can provide similar seamless integration.
There is an overwhelming amount of superfluous text in this article.
The author's solution:
> 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.
He also claims that TOTP storage in the password manager is useless. It's only useless if the entire password manager is compromised. If your attack vector is a keystroke logger, or compromise of a single password via a dump, or even someone having written down the password... storing the TOTP is still effective.
Keylogger would still get the TOTP code. Dump would include the TOTP secret. Why write only the password down if you still need password manager for the TOTP code?
I think I mostly agree TOTP in password manager is useless, but it's not worse than not having TOTP at all so it's whatever.
A TOTP code must be marked as “used” immediately after processing it, so an attacker using a keylogger would have only a few seconds at most to use the code, assuming the user typed the code from the password manager instead of copy/paste.
The protection offered for TOTP in a password manager is from people who reuse the same password on multiple sites and some other site gets hacked. In that case, the attacker would not be able to login, regardless of having the password.
Also, once a system is so thoroughly compromised that the attacker can install a key logger or dump a password database, that system and all the user accounts are already completely compromised.
TOTP at this point is essentially a forced password that changes every 30 seconds instead of an actual additional factor, however in many cases that’s good enough.
you missed the attack. a keylogger doesn’t capture the TOTP (and fully synchronous 0-reuse TOTP isn’t possible on global scale, instead you catch it in audit) a keylogger captures the master password to the pwm that stores the TOTP secret.
But then they have to have physical access to your pwm or an export of it. If it's cloud-based, I'd have to assume there's some additional auth done for non-approved devices, or it's a bad cloud pwm.
In the keylogger case, it still makes the attack more complicated -- they need to steal your login before that code expires, so rather than passive password-harvesting it has to be an immediate attack.
2FA protects two different attacks: 1) Hacker obtaining your password (through phishing, compromise of third party, etc.) 2) _You_ actually being compromised yourself somehow.
It is still effective for the first protection if you store your codes in your password manager, but less for the second. I say less, and not completely, because if your machine is compromised, gaining access to your phone too is only a matter of time. Of course this can be mitigated why proper hardware tokens, but most people aren't using those.
This is basically what passkeys are, right? Except the autogenerated password isn't even shown to the user, just stored immediately in the user’s password manager.
(I recognize that it’s a bit
more involved, eg if i get it right, passkeys add some public key encryption to the mix to avoid sending the “password” over the wire needlessly often etc, but those are just icing on the cake as far as I’m concerned)
While you can't memorize it (memorizing a fair amount of entropy would take an intelligent human quite some time), you can of course store them offline (it's just a key). Today's initial implementation on macOS restricts exporting, but that is supposed to be added according to reliable Apple devs: https://hachyderm.io/@rmondello/110329118270492669
> memorizing a fair amount of entropy would take an intelligent human quite some time
Everyone who has seen it remembers correct horse battery staple and intelligent humans find it relative straightforward to reroll diceware until they can imagine a story for the words they see.
Permute case, use symbols and digits as word dividers, and most HN readers can remember 'uncrackable' amounts of entropy.
There isn’t encryption nor a generated password involved with passkeys. Rather, your device generates a private key and stores it in your password manager - and only the public key is sent to the server.
When you log in later, the server uses an API to give your client a random unique challenge (just some bytes), you unlock and approve and the pwm signs some stuff including the challenge and sends the signature back. The server verifies with the public key, and is satisfied because only your private key could’ve generated that signature.
But you are exactly right - this is detail and the UX is essentially the same as having the pwm generate random passwords that you never get to see or copy.
Important to emphasize that passkeys are phishing resistant. Unlike passwords that allow you to copy and paste them to a website (hmm, auto complete isn’t working on this broken website, I can just go find it and paste it in — boom phished).
There isn't encryption involved? I mean how can you use public and private keys without encryption?
Anyways yes, I agree otherwise. That said for all intents and purposes, the private key is a password. It’s the thing you store that gives you access to the service. That it’s not transmitted, but instead the whole public key / challenge response dance is done, is IMO sufficiently well summarized as “well, it’s a special kind of autogenerated password, which can’t be insecurely transmitted or badly stored by the service”.
If we really want people to adopt passkeys we gotta begin talking about them in terms people understand. I consider myself pretty tech savvy and it took me like 6 articles until I finally grokked that a passkey is just an autogenerated password (plus some free automatic bonus security that doesn’t affect my UX)
> 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.
I don’t understand that logic. Normally, systems generate API keys and show them to a person _knowing_who_that_person_is_.
I, when I lose my password, the system can generate a new one for me even when I’m not logged in, how can it know it’s doing that for me and not for someone claiming to be me?
I don't understand your confusion. The generated high entropy password would be shown to you with the system knowing who you are too - because you just registered or reset your password.
It sounds almost exactly like the mechanics of a session cookie as implemented on nearly every website on earth. Exchange a password for a bearer credential that is randomly chosen and revocable. There are only so many basic ideas in security.
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.
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).
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.
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).
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?
Yes. Like I know people that have 100% bought-in to a single architecture -- all Google or all Apple -- who use the suggested random passwords built into the cross-platform-browsers of these platforms. But if you're not a single-platform cloud-account all the things person it's much more difficult.
> 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.
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:
1. click profile
2. click settings
3. click developer settings (the last item of 24 items)
4. click personal access tokens (again the last item in the list)
5. click tokens classic (again the last item)
6. click generate new token
7. click generate new token (classic)
8. enter password
9. click confirm
10. enter note
11. choose expiration
12. choose scope
13. click generate token
thats just way, way too many steps for the average user.
GitHub is a development platform, heavily related to tech though. People that are experienced enough to do git push can definitely manage API key-like passwords. This solution is not exactly suitable for any other industry, its literally a call for bankruptcy (unless you are B2B, and even with that, so many tickets, support overload...)
99% of their users, even 99.99% might be programmers, but I was involved with a project where most of the contributors were lawyers. Most of them could only use the GitHub web interface ('edit file', not even the VS Code one) to make changes, so making it easier for them to use git push would be advantageous for everyone involved.
I don’t push with any access token, I push with SSH keys.
An alternative IIRC is to a UI client like GitHub Desktop which lets you login/SSO everything like that, although I’m not sure if that only works because my SSH credentials are configured.
Personal Access Tokens are intended for fully automated access, such as a deployment pipeline. They are not intended for daily use, and step 4 even explicitly says "Need an API token for scripts or testing?".
For regular pushing you are expected to use a SSH key, and those are far easier to add.
Indeed, but you still need a Personal Access Token to integrate pull requests and issues with your Git client. GitHub doesn't support SSH authentication in those cases.
I think they mean a desktop GUI application on top of git like GitKraken or SourceTree. These sometimes allow you to perform actions like creating a PR (which is not done via git itself, of course).
> but you still need a Personal Access Token to integrate pull requests and issues with your Git client
(Nitpick from a former GH employee) PATs really are almost exclusively intended for personal testing with curl and such. The strongly preferred way for apps like you describe to work is a pseudo-OAuth flow (“GitHub Apps”) which yields a token that is not a Personal Access Token. Better in just about every way: more ergonomic, more secure (revocable, shorter duration, predictable fine grain scope with a mechanism for requesting additional permissions as apps change, etc), and requests are attributable to the application which generated them instead of just the user. If you use an app that actually requires generating and pasting a PAT, it’s either extremely old or made by someone who is not prioritizing security and user experience. It even works well in CLI apps, cf. the `gh` command line utility.
I should have clarified; sorry. I was referring to how some editors and IDEs can interact with git repositories. For instance, if I was editing a file that had uncommitted changes, it might display that text in a different colour. Interaction with GitHub might be in the form of browsing pull requests within the IDE.
This is what I do with Emacs using a package called Magit[1]; VS Code comes with something similar.
> 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.
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 not being phased out.
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.
I kinda wish there was something like cookies, but even more persistent. Lets call them permacookies.
I want to "remember my device", and have that keep me logged in forever with a permacookie. I don't even want to have a username and password. I want to create an account and be forever logged in.
There would be mechanisms to backup my permacookies, or transfer them to other devices. I'd have control of which sites could set permacookies for when I didn't want to be tracked too.
Honestly that feels like what apps are. One of the most compelling reasons to install an iOS app for something like an online bank is so that I won't have to worry about my cookies expiring and forcing me to login again.
This is why I hope PWAs take off more. If there is an implicit "save first party cookies forever" for PWAs that have been "installed" and we make them discoverable it's a net win.
Exactly, they are in recent years moving to address these previous issues, I applaud them.
I would like it if they were more discoverable, but not necessarily with the obnoxious pop ups. It would be awesome if they let you list a PWA in the App Store for a fee or the 30% cut.
Besides - there are plenty of other things Apple can do to ensure PWA's don't take off. For example, there is no ability for a web-app to have a "click here to install to desktop" button - the website must try to guide the user into clicking the share button and then creating a desktop icon - which most users don't associate with 'installing' something.
Also, the 50Mb limit on PWA's prevents a lot of usecases - like photo/video editors, and even most messaging apps.
This isn't just the limit for css/js... It's the limit for user data too. Ie. if you share some videos with a PWA app, then all the videos have to fit inside 50MB unless you want to fetch them from a server each time you play them.
Or consider a PWA music player - 50MB of music is all you can play offline.
Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server.
> Or consider a PWA music player - 50MB of music is all you can play offline.
> Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server.
Why should either of these be saving files in an app-specific private datastore? Music, photos, videos, etc. should be in the standard system locations. The app's data storage should be solely used for settings, cache, and other internal data only useful to the app.
I'm not familiar with PWAs but if they can't access system storage then I don't think they're a useful choice for a music player or photo editor.
Because you might not have unrestricted rights to the files. The Netflix app allows me to download movies to watch offline but they're DRMed and rented to me by Netflix, not owned by me. A Netflix PWA would not allow for such feature.
DRMed files can be stored on the normal filesystem just fine, if they're DRMed that means they're encrypted at rest and decrypted on the fly.
DRMed content providers might not want to store their files on the normal filesystem because then they might have to answer uncomfortable questions like "why can't I copy this file to X and play it there?" but there's no technical reason they can't do just like every DRMed content provider on normal PC platforms has always done and store encrypted files on the normal filesystem.
I hate the fact that if you lose your phone and restore to a new one, suddenly every app is logged out again.
Like can't the login-state be part of the backup? If I was logged in when the backup was taken, I should still be logged in when restored to a new device.
On iOS many (most?) apps do store your credentials in a way that you don’t have to login if you have restored from backup or setup a new device from backup. Not all do this. Google is one annoying example that requires a fresh authentication.
My banking apps ask only for my fingerprint, or a short PIN if biometrics are not available. You could call that “logging in”, but it’s certainly not as serious of a log-in as you would have on the web (with a username and a password, and if the computer is unrecognized, authentication on the phone).
Either I use a short, easy to type password for my banking so I can log in all the time, or I use a long one and use a password manager to fill it for me and we’re basically back to “use the phone’s biometric authentication” with extra steps.
There’s already a strong, secure option for authenticating the user on a mobile device… I wish everyone would use it instead of trying to use the crap option we’re using elsewhere, especially since passwords are a pain on a tiny touchscreen keyboard.
You don’t force login on your banking apps? Eek. Or maybe you mean they do biometric auth instead of user/pwd? Leaving banking/finance apps unprotected sounds sketchy AF to me.
The idea with client certificates is that they'll live in a secure keychain and never leave it. The API exposed by whatever manages them will expose functions of the key (authenticate, encrypt) but not the key itself. If the implementation is decent, you'll authenticate every request, so it isn't possible for requests to be forged or credentials stolen unless you've got a vector to attack the OS's keychain.
I saw this pattern done on a forum. You just provided your email, and it would set a super-long-lived cookie. There was a button for "recreate my cookie" which sent you an email - like a password reset function without a password.
It was surprising the first time I used it but now I wish everything that didn't handle cash worked that way.
You can use mTLS client certificates (kept in the system key store) in browsers this way; but the UX is pretty hard to get right, and certificates nearly always have to have an expiry date to deal with the compromise-able nature of keys imported into the system key store.
What you're looking for is client certificates. This has existed for years but webby people think users are too stupid to use them, so we get the menagerie of half baked trash we have now instead.
Yes, if you've ever managed a shared unix system that uses ssh keys for login, you know that a large fraction of users cannot manage them.
Among the steps of generating a key pair, getting the public key (not the private one) into their authorized_keys file (which is in a hidden directory, for pete's sake) without introducing any extra characters or line breaks or getting the wrong permissions on the file, getting their ssh client programs to use the proper private key for the host they are trying to log in to, or figuring out ssh-agent, there are just way too many opportunities to screw up or get confused.
It seems a little bit uncharitable to assume the UX on client certs has to be as bad as the UX on SSH keys, although I'll concede the point that historically it has been.
When I worked on a code signing app, I had front row seats to how magical everyone thinks certificates are. It took me several years to convince the group that they aren't that complicated.
I think the world would be a better place if LetsEncrypt had come into being about five years earlier.
It's a myth, they are not. They are uneducated and lazy¹, not stupid.
Save for minorities with genuine learning disorders, people can learn how to click/tap a bunch of buttons in a sequence. They aren't running a PKI (that's on platform/browser vendor), they are just picking an identity from the list after all. They learn how to click the right buttons all the time, as UI designers' managers decide it's time for a new bonus and swing things around with a "new graphic language".
Basic certificate management (from end-user perspective) is not harder than password management. Passkeys are conceptually the exact same thing² as TLS client certificates, just without a purposefully neglected UI and a DIY attitude³ (TLS is supported by nearly anything, barely anything knows about WebAuthn JS shenanigans).
1) Not in a bad way. "Lazy" as in "lazy evaluation", not "lazy ass". Maybe there's a better word for this.
2) Save for some technical details, both are essentially keypair management.
3) There is almost no UI, it's just an API then all the visual bits are left out as an exercise to individual app designers (partially on platform/browser developers, partially on website developers). Browser vendors just hated those areas because they weren't deemed cool and fancy ([un]like some JS framework of the day) and shoved them under the rug as deep as they could. And unlike TLS, there is no standard how to pass data around, everyone invents their own `POST /login/webauthn` semantics.
Might as well use client certificates at that point. Along with TFA, if we don't have users choose passwords, then just issue a client cert and have it installed in the browser, would probably require some new web standard.
Password managers could take over and manage cookie storage/retrieval.
Or browsers could treat cookies more like passwords and have a user-controllable flow on each new session: "Here's this site's cookies from your last session, do you want to place these back in the browser storage?"
The fundamental issue is that browser cookies and password managers have an overlap in their usage domain.
not all of my passwords are for browser-based services, not all of my secrets are passwords, and I have several devices with different operating systems.
(eg, my password manager includes github recovery tokens, ssh keys and passphrases, recovery questions, my tax and health service identifiers, wifi passwords and the admin passwords)
Webauthn should allow use of private key authentication stored on external hardware key or in device.
You really want support for key authentication just like ssh.
You shouldn’t move private keys between devices, you should have easy way to add new public keys to a service when you setu new device.
Problem is permacookies or private keys don’t really allow ad-hoc access but maybe nowadays people don’t need to login to their accounts from cyber cafes :)
How about local storage? Only downside is that this data isn't sent automatically on ever request (unlike cookies). It would be possible though to send this secret from local storage via a separate request and receive a session cookie that then let's you be logged in automatically
Maybe shared local storage should be a browser standard. Let me keep track of my own data, but also share it with my tablet and phone by clicking a bunch of buttons.
This is circling around Native File Access, which is absolutely something the web needs and if handled correctly would be a huge improvement for user privacy and user autonomy. It would open the door for fully offline webapps with no accounts or serverside components, with much better sandboxing than native apps, and with full user control over app data using just a file browser. And it would allow for app data that could be easily shared between apps when necessary without compromising user privacy or security because the app data would just be a directory with files.
BUT... the problem is that if handled incorrectly it would be a disaster for web security, would open up tons of holes for user tracking and data theft, and would basically be a horror show. There are a dozen things that could go wrong with the spec, and all of them would be serious problems if they did go wrong.
And Chrome is heavily involved in the spec. So it's a tough position to be in to try and figure out whether it's worth advocating for. Mozilla currently considers native filesystem access to be harmful, and I don't know whether or not I agree with them. I wish Mozilla would propose an alternative spec developed entirely internally without interaction from Google.
We are talking about tablet phone and laptop sharing a data store.
Not multiple user agents on the same device sharing a data store. Though we have entered the era where the names of specs or initiatives have little to nothing to do with the actual meat of the thing.
I don't know, I use filesystem sync for all of that. All that really means is that on iOS/iPad you'd have a file portal sitting in front of your browser. And on Android, it's already filesystems anyway.
Maybe you're right though and the UI would need to be different :shrug:
This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage. There's no way to present a themed login form, no way to log the user out at all, and all sorts of weird papercut bugs[0] in between.
[0] My favorite: opening DevTools triggers a second credential prompt because the DevTools session wants to download some mapfiles or something. No infrastructure exists to make that HTTP request in the context of the current tab, apparently.
You can log the user out by changing the “realm” parameter, which is a freeform string and can be quite long. As well, setting realm will cause devtools to use cached credentials similar to a new tab.
“No themed login form” oh no! Anyway. (I really think that the “theming” on login and sign-up forms breaches which bits are done by the browser and which bits are not. We’ve had to kludge back support)
Maybe you don't listen on port 80 but I can imagine a standard web server using Let's Encrypt, for example, that could suffer from a user leaking credentials by inadvertently using HTTP rather than HTTPS.
I have to look into some protections to this. I recently did a project and used Basic Auth for expediency thinking that later I would replace with a "proper" auth form. My theory was that this was better because sending cookies is based on the protocol also not just the domain.
Know what my favorite part of the whole modern auth is? The most "reliable and secure" way to enter and transmit credentials is the browser. You know, that thing that has had absolutely tons of footguns with XSS problems, terrible cookie management/stealing, and generally leaving things up to websites to do auth.
They're even deprecating auth via non-browser means in newer OAuth/GNAP standards. It's like they're designing around what things are now, rather than thinking ahead as to what would be best. Like rather than website - managed auth, it be fully browser controlled (not HTML forms). Not cookies, but something prescribed by the browser (or whatever other application you might use, rather than needing to embed a browser yet again in everything).
> This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage.
I had assumed the cause was something like this: Product management people want functionality which is fundamentally incompatible with security-- like complete control of the appearance and behavior of the login form (which can't be squared with impersonation attacks). Security people substantially control the https auth experience, and say NO. Product management people say fine, and just don't use the secure login functionality.
Everyone is happy: PMs get the security dumpster fire they asked for, Security people keep their perfect ice castle and can complain that all breaches are the fault of the PMs doing the wrong stuff. Except the users, of course, who get a needlessly insecure experience because there are many improvements to the http auth process that don't substantially compromise security.
Pulling on this thread a bit, when I get a new set top box, most of the apps have a url or a QR code you can use to copy your session to a new machine. You could just do that for all machines and have no cookies at all. iOS even has some ways to make that a bit easier.
For some apps this would suffice. But for apps we use to live our lives, what do you do when someone has no access to their devices and they need to log in to a fresh device? Some apps will need passwords, or some other mechanism to prove you are who you say you are. But then you can leverage those apps to get back into your other apps in the case of, say, a fire.
Isn't such a thing called a crypto key? And if you had such a thing, why in the hell would anyone sensible ever use browser cookie functionality to store that?
I'm sure I'm missing something, but... isn't that cookies?
I think expiration fields on cookies are optional (correct me if I'm wrong), you just can't rely on them sticking around because the user might clear them (I'd have control of which sites could set permacookies for when I didn't want to be tracked too). Which is honestly desired behavior, I'm assuming you would want the ability to delete a permacookie.
Cookies can't be synced through Firefox sync (I thought they could but just checked and my bad, they can't) -- but there's nothing preventing browser sync from handling that, and Firefox sync is E2EE so it would as secure as any other transfer method. It wouldn't be too hard to build a browser extension to allow exporting them or importing them manually; cookies are just text content so they're trivial to inspect and manipulate and even manually copy and paste into new browsers through the dev tools.
As a login mechanism, having a permacookie is somewhat insecure so most sites use expiration dates. I'm sympathetic to the desire to be able to override that, but... the mechanisms most sites use are things like signed tokens with expiration dates checked serverside, so there's not much a browser can do about blocking a website from doing that. Short of using stateless key-based authentication I'm not sure how it would be technically possible to get rid of that behavior.
----
I'm being a little bit disingenuous here in the sense that... yeah I want native file access too. I understand that cookies are not the same as native file access and the controls aren't really the same. But that's a much larger conversation with much larger scope and with more implications for browser security.
But if you're talking specifically about login, it does seem like cookies are mostly doing everything you want and your bigger problem is just that websites time-out logins? And that Firefox sync doesn't currently sync them, which... an extension could handle that.
What is the non-permanent part of a cookie, is it just that user controls for clearing cookies aren't granular enough and they're too easy for the user to accidentally delete?
I guess mobile too, iOS safari will clear localstorage sometimes. That's a very real issue (and a big reason why I want native file access), but it's less of an issue for login since occasionally losing your login permacookie isn't a big deal, it's only a big deal if you lose offline serverless webapp data.
Cookies already last months or years, I don't think the tech limits duration so much as the sites explicitly set a time, or clear the token on the backend.
What I'd really like is to just be able to use the native filesystem. But Firefox doesn't like that, and people apparently use that, so it's not a real standard.
At the very least, they should make the origin private filesystem user-visible with a flag. Don't allow everything, just ~/WebData/default/DOMAIN_NAME
I read OP's mention of third party cookies as an example of browsers supposedly moving in a more privacy focused direction, not as being related to authentication.
Well, the weird thing about the phrasing is the claim that third-party cookies are being phased out to "prevent this sort of thing"—where "this sort of thing" is "remember this device".
This is... sorta true? Insofar as creepy advertisers also "remember this device". But a first-party site storing a cookie to remember a login session is not at all in the same category for me.
All post reads like Dunning-Kruger case, he seems to know quite some stuff but also misses 3rd party cookies. Overly focuses on weak passwords completely skipping password leaks or just mentioning password reuse.
Ignoring that TOTP is actually decent interface for getting non technical and not caring at all users use random high entropy secrets. Getting regular people to keep some generated random strings won’t work.
In the end ignoring all experience of industry which is:
leaked passwords and email lists can be used in password spraying attacks where specific user is not targeted it is just opportunistic low hanging fruit automated exploitation.
Then those easy exploitable accounts in services can be used to ask connected users for loans or financial help as a scam.
I dont agree with you that it's the user's fault. The issue isn't understanding of remember this device feature. The issue is it's a fundamentally broken design. One, because users have multiple devices and second, the feature is crippled when employing privacy preserving behavior.
I should be able to authenticate by proving access to a device such as a yubikey, as an example. Now, the site can properly remember the user. This missing feature is the fault of crummy UX, not the user.
When I think 'multiple devices' I think 'multiple devices'. Yubikey is a solution for multiple computers but I don't see how something 'such as a yubikey' solves this problem for devices.
I see nothing about the design that is broken. Most websites have implemented "remember this device" functionality in a way that 99% of users understand fine how to use. Some people have specifically implemented an option that says "Completely erase any potential for sites to remember this device", and then start bitching about poor design??
Queen, please. I have no objection for people choosing the "forget my device" option, but the nonsensical whining about explicitly choosing this option and then bemoaning that a website doesn't remember you is absurd.
“Please read my rant about how this useless hair-shirt I wear to clear first party cookies too often breaks the web (for me)”
> the web has no notion of a “device”, and this is a very intentional design choice made for privacy purposes [...] why do web developers persist in believing in this fiction of a “device”?
Cookies are a core part of the web which enable the construction of stateful applications on top of a stateless protocol. “Remembered device” is usually just an extra cookie set on login, or a row in a backend database. It’s no more fictional than the web itself, which is after all just a series of electrical impulses over wires.
Whether a device (however you build that abstraction) has previously logged in is a high-signal data point that meaningfully increases account security at login time and all serious web security teams use it to protect their users.
Imagine if these people made posts like "I edited user32.dll to dummy out random functions I deem unnecessary like RegisterClass or CreateWindowEx and now nothing works! This is proof that Windows is broken!"
It will forever be a mystery for me why people deliberately make their browsers work in ways that contradict the standards the web is built on and then manage to find blame in others when stuff doesn't work. It's already difficult enough to support all major browsers when their interpretations of the standards differ very slightly.
or the entitled "I've disabled Javascript, all web developers should make their site work without JS" when even in 2013 only 0.2% of all users to gov.uk had JS disabled*
That might be a very misleading statistic. What if more than 0.2% of people wanted to disable JavaScript, but in the end surrended to the fact that those pesky web devs never test their creations with JS disabled?
I know I am one of those who would like to disable JS, but it's just not practical. So stats really are a dangerous tool, they sometimes can end up telling you just what you want to hear...
If anyone tests their web pages without JS, it would be gov.uk. I'm an American but I frequently reference their guidelines on accessibility and similar because they're so thorough and conscientious about it.
Yeah but I am afraid every other website on the Internet is not done with the care and good craftsmanship that the gov.uk applies to its website. I wish, though! But then so many web devs (and so many of their managers, too!) would be lost without knowing what to do without a JS framework that weights several MBs worth of bloat...
It's about cost. If it takes a web dev a day to progressively enhance a page from html through css and JS, then it's a day they're adding value to a small slice of the users.
Even if you multiplied the 0.2 by 10 or 20, you're still looking at a slice not large enough to build for.
I'd say it's about priorities (i.e. very much related to cost, but with slight differences). That's why I mentioned the lack of people who cares. If you as a manager care, or if a dev with enough decision power cares, it will just be included as part of the time it costs to get the website done.
A worker putting a helmet and appropriate clothes is losing time that could be beter spent producing value. Or if we talk about social policies and minorities, for example, even if as the word says, it's a "minority" of people so it might seem that it's a slice not large enough to improve for. A bit extreme examples, but you get the idea.
Also a 0.2% of all world population is still a huge amount of people. It's just that people who can take decisions, just don't care. But some people do care, like those in charge of co.uk websites, and then we all see how well things can be done and how poorly we've been doing in comparison.
> people...who would like to disable JS, but it's just not practical
As I tell my kid when he "wants" something, I want a pony, and a million dollars.
I don't see why the fact that some people might like that matters. I mean, given the choice for free sure I'd "like" it too. But it will never remotely be worth it to build two entirely separate web applications for every website to make that dream a reality, nor do I see the whole Internet agreeing to discard the decades of advancements in FE technologies to go back to script-free HTML.
All that said, boy would that be a great jobs program for developers over age 35 though! Imagine developing for the web with no Webpack, no JS compilers, transpilers, bundles.[1]
[1]: Or whatever you frontend folks use for your toolchain this year, or this nanosecond...
> decades of advancements in FE technologies to go back to script-free HTML.
I don’t think modern webshit which requires downloading megabytes and megabytes of obfuscated code to view someone’s blog is an “advancement” for anyone except the adtech bastards.
Look. I agree with you, in the core idea. There have really been advances in technology, but for each step made with brilliance and prowess, there have been 3 steps back with laziness and carelessness.
Some applications of the newer technologies merit their use.
Most use cases, however, don't.
Bad practices abound, the "art" of programming becomes a chore made by let's say not very skilled people. Luckily there are still lots of good managers and good devs that value adequately done products, but on average that's not the case and the Web gets more and more bloated as a whole.
One day you decide to disable JavaScript in your phone (which BTW is an incredible way to speed up modern webshit, as the sibling comment puts it, in under-powered mobile devices), and turns out that lots of f*ing blogs don't load their plain text and static pictures if JS is not enabled. That's an absurd situation we've collectively ended up in.
The mere thought of having a Word document with just text, images, and a couple tables, and not being able to open it if VB macros were disabled, sounds absurd. But that's exactly what large parts of the Web have become.
Maybe I'm just too old but it feels like humanity will always find a way to collectively fuck everything up. The web is always going to be shit. Fortunately another contingent of humanity invented uBlock and reading mode.
Your complain is conflated. Turning off javascript is not akin to turning off macros in a Word document. It’s like deleting your desktop environment and complaining Word doesn’t work in a terminal.
I’m not sure if you’re really thinking about the impact of not having any javascript. Want to reply to a comment on HN? The whole page reloads. Want to upvote a comment? The whole page reloads. Sure you can give every comment an ID and reload back to where you were, but then you can’t have collapsible comments (because css, presumably what you’re hacking for collapsible comments without JS, can’t respond to anchor references).
There’s a million other usability things that require JS, it’s so much more than a macro language.
There are bad practices everywhere, in every field, and it feels like everyone feels they have the authority to beat down JS, and web dev as a whole, likely with zero experience working with it.
Web arguably has the best developer experience of any field. It’s so good, they took the web and put it in your desktop. Electron, GTK, KDE, everything is javascript.
The war is lost and over. Start arguing/discussing how JS can be improved instead that it shouldn’t exist (there’s PLENTY to complain about, don’t get me wrong).
You made it sound like even for a simple site, JavaScript would be a necessity and we should expect websites to not work well without it. I was actually about to concede that it's OK if JS has eaten the world (see my closing thought)...
> you can still view it through https://nitter.net, which I guess makes the open source Javascript-less front-end to Twitter more accessible for SEO
WHAT? I had no idea. So there is Nitter [1] frontend for Twitter -which is a platform clearly more complicated than HN- and they manage to not only work without JavaScript, but have it as one of their core motivations.
Things get even better, from that project I find about Invidious [2], a frontend for nothing else than YouTube! And again, no JS is not only an option but a highlighted feature.
After these discoveries, my bar for how JS-free we should expect most websites to be has just gone up, not down. Especially those websites consisting on just presenting text and media (i.e. the immense majority)
I agree the war is lost, though. Luckily there will still exist people desiring and making noise for a leaner and faster experience. The problem is bloated frameworks and privacy invasion via JS. Those are essentially my main reasons to want to browse the Web without JS.
this happens a lot. A LOT. not this exactly, but I know a lot of people who keep .reg files for "fixing Windows bullshit" on a new system, which they built up when Windows XP or Windows 2000 was new.
Of course, a lot of those "fixes" now break things, because the underlying workings of windows changes a lot, but every last person I know who uses these has very odd problems with Windows that I have never once seen myself.
a lot of these things that only experts knew how to do 20 years ago are now the causes of very odd problems, because these folks don't bother to verify that these registry settings are still the correct way to make the intended changes.
It seems to me like the user you're replying to is well aware of how web devs attempt to identify unique devices (browser cookies.) They're saying that the manner that this is implemented leads to poor user experiences due to the faulty assumption that just because a cookie doesn't exist in the client browser, that the device is in fact unique to previously used devices. Which I don't see how your comment actually addresses. I tend to agree with the other user. Making healthy security conscious decisions like low TTLs on local cookie storage (such as cookie purge on browser/tab close) feels unrewarded when the site enforces additional security gates on login. The point is: unique login devices may have been a good idea, but in practice the design of the web does not make them an ideal candidate for bolstering user security. Maybe someday passkeys solves the unique device problem sufficiently such that faulty assumption methods like browser cookie storage cease to be commonplace.
I'm the parent commenter, but the viewpoint you're agreeing with is an extract from the article, not my perspective, as indicated by the > before the paragraph. My own comments are the subsequent two paragraphs.
In short, I entirely agree with @brasic: the article author has a nonstandard configuration (clearing cookies automatically before their expiry date) and based their entire article on the difficulties that this highly unusual and unnecessary choice has caused for them. "Hair shirt" is a great way to describe it.
> Making healthy security conscious decisions like low TTLs on local cookie storage (such as cookie purge on browser/tab close) feels unrewarded when the site enforces additional security gates on login. The point is: unique login devices may have been a good idea, but in practice the design of the web does not make them an ideal candidate for bolstering user security.
This is exactly @brasic's point, though: if a website can affirmatively identify that you've logged in from this machine before, that's a pretty good indicator that this new session is a legitimate login. We can do that through cookies, and for most users that's just fine. If you clear cookies regularly for security reasons, then you shouldn't be offended that a website asks you for extra confirmation that you are you, since that is also done for security reasons.
Clearing cookies for a domain is instructing your browser to identify itself as though it had never spoken to that server before. If you want the server to know you're still you, maybe just leave the cookies there?
Yep, to be clear I was agreeing with lolinder. I would have posted top level but they had already expressed almost exactly my objection to the article so I replied to avoid redundancy.
Maybe just accept my password and at most my TOTP? Asking for some others auth method that I may not be able to provide in a timely manner or at all only helps the provider cover their ass.
The author is Hugo Landau, so of course it is a bad take, how else could it be. The real question at this point is why his terrible takes reach the front page every two weeks…
Seriously, reading this article made me wish for a downvote option on submissions. I'm glad the top comment is pointing out the nonsense of this argument, but then I'm just left wondering how this made it to the top of HN in the first place. The author's diatribe about "remember device" functionality is just flat out silly, for all the reasons other commenters have pointed out.
> I'm glad the top comment is pointing out the nonsense of this argument, but then I'm just left wondering how this made it to the top of HN in the first place.
The last two posts from the same author[1][2], in the past month, where of the same kind and got the same kind of reception (except that for the fediverse blog post, the top comments were either discussing about the topic of the title without addressing the (dumb) content of the article). So yeah, the mystery is why it keeps coming back.
Yeah I don't think he has adequately explored what happens when the website gives him a giant token to enter and then it can't be stored in a cookie. What does he think is going to happen next?
He's right that it's a him problem- but my bank and my HR website both have "Remember this device" placebo checkboxes that do absolutely nothing. The feature is broken way too often even on stock browsers.
I thought "remember this device" more typically worked via a combination of browser fingerprinting (which can be pretty sophisticated, e.g. even relying on rendering behaviours) and local storage, which may or may not involve cookies.
> anyone who is savvy enough to configure that setting is also savvy enough to understand that that will break "remember this device"
I don't think so. Most people who understand that that will break "remember this device" also understand that clearing cookies doesn't help much with privacy. So the people who do enable that setting generally only know that cookies == tracking and do not understand that that will break "remember this device" ("Dunning-Kruger").
> 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 not being phased out.
Cookies are cookies, not a "device". You could theoretically copy whatever cookies they put in to authenticate in other place and get automatically logged in.
> The author has configured their browser to throw away cookies when the last tab closes
If web was supposed to be stateful, this would be a bug, and the author would have had to dig through experimental or advanced settings to enable it. But because web(HTTP) is fundamentally stateless, it is a feature, and it's a feature that every browser exposes to normal user. Your browser is not expected to keep your cookies, just like your browser isn't expected to support javascript to access a website, or that you should enable them even if you could.
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):
https://khromov.se/building-a-privacy-friendly-self-hosted-a...
- 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.
- 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.
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.
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.
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.
100%. Storing your "2FA" TOTP tokens in your password manager is asking for trouble, in my opinion. Why put all your bags in one basket? The moment your PC gets owned your are pretty much permanently locked out of all your accounts.
I agree, but I'd point out one thing just in case you're using "PC" in a restrictive sense.
There's no difference between using a big Personal Computer (PC) like a desktop computer, or a small Personal Computer (PC) like a smartphone. Both are something you have.
The problem is not that a bigger computer that never leaves your home is more insecure and that the small computer with a touch screen that actually leaves your home is more secure.
The problem is also not storing TOTP in a password manager. Because a password manager can also be used from a smartphone and a TOTP authenticator can also be used from a desktop computer.
The problem is using the same device ("factor", if we're being fancy) for storing and reading both secrets, because that means if the device is compromised it'll be able to read both types of secrets.
So using a desktop computer for passwords and a smartphone for TOTP, should be just as fine as using a laptop 1 for passwords and a laptop 2 for TOTP.
I'm way more at risk of locking myself out than someone getting onto my system, getting into my password store, exporting secrets, and using them to ruin my life. Honestly it would probably make national news if someone physically burgled their digital identity.
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
The problem is that email is not guaranteed to arrive in 30 seconds. Speaking from experience, it is extremely frustrating trying to access a resource and being unable to do so because someone in the entire email chain did a transient whoopsie.
Yep. And it's often not solvable by just sending the email again: I've more than once found cases where an app's email provider is particularly slow and the tokens arrive late no matter how many times I send them.
Bonus points if each email has a new token and only the most recent one is valid, because then you're stuck trying to remember how many times you clicked the "email me" button. Is this the right token, or am I waiting for one more to come in?
I use two services that do the same, so it is not completely uncommon. Both services don't require frequent login, though. One service is a DNS provider and the other a learning platform where the primary way of interaction doesn't require a login at their platform.
I know plenty of people who use that approach for all but their most used accounts ... just click on the "reset password" link, use it, and forget the new password!
It works but it's incredibly heavyweight. For every login you use an entire email infrastructure, doing all the email "security" processes. That a great deal of work.
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.
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).
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.
But if the author insists, users should be given printed password books and enable MFA.
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.
This isn’t the attack vector to be concerned about. More concerning is when there’s a data breach and an attacker gains access to hashed passwords. At that point, you attack the hash not the API.
This comment is an example of why I wouldn’t want any given website to choose my password.
That assumes the situation where the password hashes are stored in a way that is less secure than the actual data that the attacker ultimately wants access to. That must not be a very common situation.
The passwords will not be of any use on any other system. This would eliminate password reuse.
Accessing a users data is not the only reason for hacking their account. Performing actions on behalf of a user is just as much of a threat.
Edit: also, if an attacker dumps all the data today then loses access to the data tomorrow, having access to my password hashes means they can access my account and data later.
That’s all fun and nice until someone decides to antagonise you and they intentionally make three failed login attempts for your username into the website every n hours, keeping you unable to sign into your account.
They do this to the accounts you use to communicate simultaneous with an attack on your reputation, i.e., when being able to to communicate suddenly becomes critical (for defending yourself against the allegations).
You can't ratelimit someone you have not yet identified. Unless their username is also a password. But then you just have 2 passwords. And the ID password would have to be sufficiently high entropy to not be hit by bots.
389 comments
[ 3.0 ms ] story [ 352 ms ] threadIt will effectively be the same as those places that send you a login email after you have entered your password for security or harrashment (looking at you, Zoom).
For the non-American aspect, it's extremely common for websites to force ASCII today (either explicitly, or because using anything else breaks in various unexpected ways) anyway, I doubt that any internet user around the globe will have an issue with that. That boat has sailed in the 90s.
...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.
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.
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.
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.
Technology is for people, not the other way around.
Yet akin to the article, because of the overly sensitive, everyone's expressive creativity must be dulled down. Who's the intolerant one?
Reminds me of this classic https://medium.com/incerto/the-most-intolerant-wins-the-dict...
I can agree that people are often over-sensitive but I wouldn’t expect that calling a person deadweight is likely to garner their thoughtful attention, precisely because it is disrespectful. Indeed, it would be foolish of me to expect them to start (or continue) listening to my words.
Maybe you have better luck in New York but I bet you could find people (read: strangers whom you’ve never met or spoken to) there who are personally offended when you call them deadweight. If you’re walking somewhere and you see someone whom you think is homeless, do you let them know they’re deadweight to society? Do you think one is being over-sensitive if they become offended after they are simply called “stupid”? It might be worth explaining an opinion more instead of using such terminating cliches.
Maybe because the one commenter used the phrase “insensitive opinion” there is a misunderstanding. I’m not trying to suggest that the opinion is insensitive, only the way it’s expressed. This opinion can be presented in a friendlier way, despite the topic. (It may also be worth pointing to four words in my initial comment: “regardless of the veracity”.) One can be tolerant of opinions while being intolerant of name-calling in a way that is compatible with not being the “tyrannical minority”.
That's simply incorrect. Everyone gets to decide.
The fact is, anti-human attitudes to both housing and technology are harmful everywhere. Nobody has to "win" at the other side's expense here.
Leveling down on everyone's security in exchange for usability for a segment of the population is not a realistic long-term strategy.
As for the rest, is there any actual evidence of widespread interception of SMS 2fa actually being a problem?
I also have no password requirements (other than non-blank)
I do this because I see it as user centric. I have never had a problem.
One environment requires no privacy expectation. That environment we use simple nouns all in the same category.
All the environments are full SSO they only need to login.
Technology is not for people. It ought to be, but it is not.
Technology exists so that the aristocracy can line their pockets and control the populace more efficiently.
People and technology and aristocracy are for the memes. It's just one huge anthill where the ideas evolve, living on biological (and then technological) foundations.
Power hubs (be it aristocracy or any other form of government) is just a convenient mechanism for spreading ideas - politicians and millionaries are just superspreaders (in their respective ages, but they're losing it to the technological platforms - and of course there's a struggle). So is technology. So are people. It's all an evolutionary process - just notice how designed systems rarely win, nearly always giving to chaotic blind evolution - whatever catches more brainspace truly matters, not what works best. If the memetic winds will blow in a certain direction, LLMs may make us obsolete, but not in the way we think they would.
This comment is sponsored by "You think the moon is real?" meme. Sorry (not sorry).
In all seriousness, tech must adapt to humans. Engineers are at their best when they aren’t dictators
The same capitalistic analysis can be said for fetuses, infants, and children up to working age.
Is your proposal for infanticide the same as your gerontocide?
Nobody’s arguing that passwords/phrases should only be remembered and never written down or stored in a password manager. That ship sailed a long time ago.
Your father does use a password manager: a slow, very inconvenient one. If you could teach him to reach for ctrl-c/ctrl-v instead of a pencil, it would be easier for him.
Your notebook will look markedly different from a website that tries to imitate your notebook. Your password manager will only look markedly different from a website imitating your password manager if you have a certain level of awareness and acuity of what happens on-screen and what it means. I think GP's father doesn't have that awareness, and never will, by choice. They choose to spend their energy elsewhere.
Younger generations had no choice and will have spent that energy already by the time they're 12 years old, and have these problems less.
This! I mention password managers, two factor or just try and get him to improve his passwords and his eyes glaze over and can see him beginning to nod off. Probably somewhat my fault for always bring them up after a meal when he's probably already half way to napping...
I'm getting close to 60, but I've been programming and working with computers since in was in 6th grade. When I was in my 30s, paying my bills meant sitting down at the table once a month with my checkbook, stack of bills, and book of stamps. Open a bill, write a check, put a stamp on the envelope, repeat. It took maybe 15 minutes and was very easy. Compare that to opening a different website, with a different username and password and maybe TOTP code or SMS code, for each bill I need to pay. It's slower and more complicated.
There is no online payment method I've seen that seems easier to me than just writing a check. Of course I rarely write checks these days, so I use the apps and websites and feel annoyed every time I do.
Though you are also correct that dealing with "technology" today requires a certain level of pain tolerance. Good UX exists but is rare, and authentication is still a mess basically everywhere if you don't want to do OAuth and centralise it to the behemoths. "Poweruser apps" can be extremely empowering, but always have a steep learning curve, sometimes very steep; they can help making your dayjob much easier, but typically help nought with, say, filing your taxes or paying your bills.
Disclaimer: am 25 years old.
and immediately you write this:
> Though you are also correct that dealing with "technology" today requires a certain level of pain tolerance. Good UX exists but is rare
So it's not just 40+ year olds who feel this way
EDIT: you are correct I didn't word my original message correctly. Perhaps you have a point.
Autopay. I only pay one bill manually, twice a year, because they don't allow autopay (property taxes). Otherwise I just don't think about it.
Sure, you may not like autopay for whatever reason, but that's a choice. The option is there.
It's not comfortable, but every time you write a check you're doing exactly this.
They are correct aren't they? None of the modern software is made to serve and help the user. It's made to serve advertisers and be promotion vehicles for product managers.
I am a computer guy. I am constantly and continuously irritated by all the crap in software. I see how my non-techie mom struggles, and it's several orders of magnitude worse for her.
So I totally agree with you.
How I paid bills in Thailand:
Apart from autopay (mentioned by someone else) it doesn't get simpler than that.It might reasonably be argued that it's less secure, since it's pretty hard to hack an air-gapped sheet of paper. But it's not harder to use.
>Your father does use a password manager: a slow, very inconvenient one
Writing down certain passwords can be very convenient. No hacker on the internet is going to access the piece of paper on my desk.
I consider myself computer savvy and I still write down some passwords on paper instead of having them stored on an internet connected computer. (I believe burglars really don't care about passwords. And it is very easy to obscure the written passwords.)
A notebook in a locked safe is the most secure datastore for 90 - 98% of the population - depending of how deeply you distrust NSA.
If someone breaks into my house I’d rather they just got my TV and some belongings rather than my life savings.
Does it make sense to also keep some decoy items, like an old MacBook in plain sight?
I hope so. I always leave an old Macbook and iPhone in sight when leaving the house.
"Unfortunately, large swaths of the security community are fixated on avant garde horrors such as the fact that, during solar eclipses, pacemakers can be remotely controlled with a garage door opener and a Pringles can. It’s definitely unfor- tunate that Pringles cans are the gateway to an obscure set of Sith-like powers that can be used against the 0.002% of the population that has both a pacemaker and bitter enemies in the electronics hobbyist community. However, if someone is motivated enough to kill you by focusing electromagnetic energy through a Pringles can, you probably did something to deserve that. I am not saying that I want you dead, but I am saying that you may have to die so that researchers who study per-photon HMACs for pacemaker transmitters can instead work on making it easier for people to generate good passwords."
My point being if someone's motivated enough to break into your house to steal your passwords in order to steal your life savings, that's probably an outside scenario, given most B&Es are junkies looking to score enough for their next high.
I think this is very unlikely. For one, the notebook does not contain all the information - say "Bank1 Password" - which bank is that? What's the username? What about 2FA?
Secondly, surely the whole point if a safe is that it's bolted down and hard to burgle / steal?
they exist but uh. most people just have portable fire-safe boxes as far as I've seen. or nothing.
Some people will just never change a behaviour.
I usually avoid analogies of HN as you are often called out on the technicalities of them. And you are right that can often damage an argument.
However, I have argued that changing peoples behaviour, even when their current behaviour is bad for them, is often impossible despite all evidence, from the beginning.
This is still case 1.
I actually agree with you that some people with bad security habits will never change their behavior, but do you really feel that someone using passwords in a notebook because that's what they're comfortable with is in the same class of behavior as someone addicted to nicotine?
Feel free to have the last word here. 1 on 1 HN threads more than 3 deep rarely result in productive conversation. Cheers
Fwiw I think you're actually right that HN tends to spend way too much time on semantics, and I'm certainly guilty of that myself sometimes
* to respond to something you don't agree with, in this case a metaphor, perhaps just write "I don't agree with that metaphor" or "let's stick to realistic examples"
* try not to dissect motives unless necessary. The person you responded to made a good point that people will do things against their interests out of habit or convenience -- why does use of a completely legitimate tactic need to be singled out?
* technical people who work with non-technical people (or even who deal with non-technical families and friends and children) are highly accustomed to describing things in simple metaphors
I realize that I have been uncordial and somewhat aggressive with you in this instance, but it made me particularly irked to see someone profess such an amount of self-awareness while showing a profound lack of it.
Either you are (a) just not in your groove mentally at that moment, (b) not as centered as you like to think you are, or (c) playing some kind of game, either consciously or unconsciously. Either way I figured my approach would get a response and hopefully a correction.
I look forward to our next encounter and genuinely hope it starts off on a better footing because you seem like an interesting person.
So do I for some passwords, physical security is way easier.
Have you tried the “passkey” integration on Apple devices? If so, do you think your father would be able to use that?
To me, it seems such a simple UX that I can’t imagine even the most technically illiterate being unable to use it. In the Apple ecosystem, there is literally no configuration for the “password manager” it’s just integrated into the Apple Account. You’d go from a notebook of passwords to just one (the main Apple ID password, for recovery etc).
Obviously “passkey” is not available in most sites yet, but I imagine that once it is, the switch might be pretty painless for the non-tech savvy. Assuming the other device manufacturers can provide similar seamless integration.
How would a users use different devices?
The author's solution:
> 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 think I mostly agree TOTP in password manager is useless, but it's not worse than not having TOTP at all so it's whatever.
The protection offered for TOTP in a password manager is from people who reuse the same password on multiple sites and some other site gets hacked. In that case, the attacker would not be able to login, regardless of having the password.
Also, once a system is so thoroughly compromised that the attacker can install a key logger or dump a password database, that system and all the user accounts are already completely compromised.
TOTP at this point is essentially a forced password that changes every 30 seconds instead of an actual additional factor, however in many cases that’s good enough.
It is still effective for the first protection if you store your codes in your password manager, but less for the second. I say less, and not completely, because if your machine is compromised, gaining access to your phone too is only a matter of time. Of course this can be mitigated why proper hardware tokens, but most people aren't using those.
Ultimately if someone can log keystrokes and has access to your device, it's game over.
(I recognize that it’s a bit more involved, eg if i get it right, passkeys add some public key encryption to the mix to avoid sending the “password” over the wire needlessly often etc, but those are just icing on the cake as far as I’m concerned)
Passkey depends on your device.
>Today's initial implementation on macOS restricts exporting,
So you can't. Will be able. How long can Tesla owner earn money with their self driving Tesla?
If you can export and import them, isn't that a security risk?
Everyone who has seen it remembers correct horse battery staple and intelligent humans find it relative straightforward to reroll diceware until they can imagine a story for the words they see.
Permute case, use symbols and digits as word dividers, and most HN readers can remember 'uncrackable' amounts of entropy.
When you log in later, the server uses an API to give your client a random unique challenge (just some bytes), you unlock and approve and the pwm signs some stuff including the challenge and sends the signature back. The server verifies with the public key, and is satisfied because only your private key could’ve generated that signature.
But you are exactly right - this is detail and the UX is essentially the same as having the pwm generate random passwords that you never get to see or copy.
Anyways yes, I agree otherwise. That said for all intents and purposes, the private key is a password. It’s the thing you store that gives you access to the service. That it’s not transmitted, but instead the whole public key / challenge response dance is done, is IMO sufficiently well summarized as “well, it’s a special kind of autogenerated password, which can’t be insecurely transmitted or badly stored by the service”.
If we really want people to adopt passkeys we gotta begin talking about them in terms people understand. I consider myself pretty tech savvy and it took me like 6 articles until I finally grokked that a passkey is just an autogenerated password (plus some free automatic bonus security that doesn’t affect my UX)
Signing is different from encrypting.
https://en.wikipedia.org/wiki/Digital_Signature_Algorithm
And yes, 100% agree we can do better in terms of explaining passkeys. The hardest part is that different audiences require such different approaches.
I don’t understand that logic. Normally, systems generate API keys and show them to a person _knowing_who_that_person_is_.
I, when I lose my password, the system can generate a new one for me even when I’m not logged in, how can it know it’s doing that for me and not for someone claiming to be me?
By emailing you a OTP :)
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).
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.
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).
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.
With a stupid email login I have to do many more steps (and email isn't 100% reliably immediate)
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:
1. click profile
2. click settings
3. click developer settings (the last item of 24 items)
4. click personal access tokens (again the last item in the list)
5. click tokens classic (again the last item)
6. click generate new token
7. click generate new token (classic)
8. enter password
9. click confirm
10. enter note
11. choose expiration
12. choose scope
13. click generate token
thats just way, way too many steps for the average user.
An alternative IIRC is to a UI client like GitHub Desktop which lets you login/SSO everything like that, although I’m not sure if that only works because my SSH credentials are configured.
For regular pushing you are expected to use a SSH key, and those are far easier to add.
This is what I do with Emacs using a package called Magit[1]; VS Code comes with something similar.
[1]: https://magit.vc/
https://github.com/nostr-protocol/nips/blob/master/19.md
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 not being phased out.
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.
I want to "remember my device", and have that keep me logged in forever with a permacookie. I don't even want to have a username and password. I want to create an account and be forever logged in.
There would be mechanisms to backup my permacookies, or transfer them to other devices. I'd have control of which sites could set permacookies for when I didn't want to be tracked too.
I would like it if they were more discoverable, but not necessarily with the obnoxious pop ups. It would be awesome if they let you list a PWA in the App Store for a fee or the 30% cut.
Besides - there are plenty of other things Apple can do to ensure PWA's don't take off. For example, there is no ability for a web-app to have a "click here to install to desktop" button - the website must try to guide the user into clicking the share button and then creating a desktop icon - which most users don't associate with 'installing' something.
Also, the 50Mb limit on PWA's prevents a lot of usecases - like photo/video editors, and even most messaging apps.
Firefox refuses to implement pwa. Chrome has pwas but they're not isolated.
Apple is the only one with sane pwa but somehow they're the worst and are totally sabotaging PWAs because something something walled garden?
The entirety of TempleOS (including dozens of programs and multimedia games) is 2MB.
Or consider a PWA music player - 50MB of music is all you can play offline.
Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server.
> Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server.
Why should either of these be saving files in an app-specific private datastore? Music, photos, videos, etc. should be in the standard system locations. The app's data storage should be solely used for settings, cache, and other internal data only useful to the app.
I'm not familiar with PWAs but if they can't access system storage then I don't think they're a useful choice for a music player or photo editor.
DRMed content providers might not want to store their files on the normal filesystem because then they might have to answer uncomfortable questions like "why can't I copy this file to X and play it there?" but there's no technical reason they can't do just like every DRMed content provider on normal PC platforms has always done and store encrypted files on the normal filesystem.
Like can't the login-state be part of the backup? If I was logged in when the backup was taken, I should still be logged in when restored to a new device.
Either I use a short, easy to type password for my banking so I can log in all the time, or I use a long one and use a password manager to fill it for me and we’re basically back to “use the phone’s biometric authentication” with extra steps.
There’s already a strong, secure option for authenticating the user on a mobile device… I wish everyone would use it instead of trying to use the crap option we’re using elsewhere, especially since passwords are a pain on a tiny touchscreen keyboard.
Almost every single app on my phone forgets who I am even after minor updates.
Apps I use infrequently? It's like they never knew me to begin with.
It was surprising the first time I used it but now I wish everything that didn't handle cash worked that way.
I agree with this, but...
> users are too stupid to use them
they are. Key management is not trivial.
Among the steps of generating a key pair, getting the public key (not the private one) into their authorized_keys file (which is in a hidden directory, for pete's sake) without introducing any extra characters or line breaks or getting the wrong permissions on the file, getting their ssh client programs to use the proper private key for the host they are trying to log in to, or figuring out ssh-agent, there are just way too many opportunities to screw up or get confused.
I think the world would be a better place if LetsEncrypt had come into being about five years earlier.
Save for minorities with genuine learning disorders, people can learn how to click/tap a bunch of buttons in a sequence. They aren't running a PKI (that's on platform/browser vendor), they are just picking an identity from the list after all. They learn how to click the right buttons all the time, as UI designers' managers decide it's time for a new bonus and swing things around with a "new graphic language".
Basic certificate management (from end-user perspective) is not harder than password management. Passkeys are conceptually the exact same thing² as TLS client certificates, just without a purposefully neglected UI and a DIY attitude³ (TLS is supported by nearly anything, barely anything knows about WebAuthn JS shenanigans).
1) Not in a bad way. "Lazy" as in "lazy evaluation", not "lazy ass". Maybe there's a better word for this.
2) Save for some technical details, both are essentially keypair management.
3) There is almost no UI, it's just an API then all the visual bits are left out as an exercise to individual app designers (partially on platform/browser developers, partially on website developers). Browser vendors just hated those areas because they weren't deemed cool and fancy ([un]like some JS framework of the day) and shoved them under the rug as deep as they could. And unlike TLS, there is no standard how to pass data around, everyone invents their own `POST /login/webauthn` semantics.
I would burn client certs to the ground if I could.
There would also be intentional and unintentional mechanisms for stealing these permacookies.
Or browsers could treat cookies more like passwords and have a user-controllable flow on each new session: "Here's this site's cookies from your last session, do you want to place these back in the browser storage?"
The fundamental issue is that browser cookies and password managers have an overlap in their usage domain.
(eg, my password manager includes github recovery tokens, ssh keys and passphrases, recovery questions, my tax and health service identifiers, wifi passwords and the admin passwords)
Fruitcakes.
is it secure? hell no, but it can be used.
You really want support for key authentication just like ssh.
You shouldn’t move private keys between devices, you should have easy way to add new public keys to a service when you setu new device.
Problem is permacookies or private keys don’t really allow ad-hoc access but maybe nowadays people don’t need to login to their accounts from cyber cafes :)
Log in once, on one website, then be logged in on all websites forever.
If you work for advertisers this sounds like a great idea. Better than eating babies.
BUT... the problem is that if handled incorrectly it would be a disaster for web security, would open up tons of holes for user tracking and data theft, and would basically be a horror show. There are a dozen things that could go wrong with the spec, and all of them would be serious problems if they did go wrong.
And Chrome is heavily involved in the spec. So it's a tough position to be in to try and figure out whether it's worth advocating for. Mozilla currently considers native filesystem access to be harmful, and I don't know whether or not I agree with them. I wish Mozilla would propose an alternative spec developed entirely internally without interaction from Google.
We are talking about tablet phone and laptop sharing a data store.
Not multiple user agents on the same device sharing a data store. Though we have entered the era where the names of specs or initiatives have little to nothing to do with the actual meat of the thing.
Maybe you're right though and the UI would need to be different :shrug:
[0] My favorite: opening DevTools triggers a second credential prompt because the DevTools session wants to download some mapfiles or something. No infrastructure exists to make that HTTP request in the context of the current tab, apparently.
“No themed login form” oh no! Anyway. (I really think that the “theming” on login and sign-up forms breaches which bits are done by the browser and which bits are not. We’ve had to kludge back support)
https://joeldare.com/why-im-using-http-basic-auth-in-2022
non-iOS browsers seem to handle HTTP basic auth gracefully.
I have to look into some protections to this. I recently did a project and used Basic Auth for expediency thinking that later I would replace with a "proper" auth form. My theory was that this was better because sending cookies is based on the protocol also not just the domain.
They're even deprecating auth via non-browser means in newer OAuth/GNAP standards. It's like they're designing around what things are now, rather than thinking ahead as to what would be best. Like rather than website - managed auth, it be fully browser controlled (not HTML forms). Not cookies, but something prescribed by the browser (or whatever other application you might use, rather than needing to embed a browser yet again in everything).
I had assumed the cause was something like this: Product management people want functionality which is fundamentally incompatible with security-- like complete control of the appearance and behavior of the login form (which can't be squared with impersonation attacks). Security people substantially control the https auth experience, and say NO. Product management people say fine, and just don't use the secure login functionality.
Everyone is happy: PMs get the security dumpster fire they asked for, Security people keep their perfect ice castle and can complain that all breaches are the fault of the PMs doing the wrong stuff. Except the users, of course, who get a needlessly insecure experience because there are many improvements to the http auth process that don't substantially compromise security.
For some apps this would suffice. But for apps we use to live our lives, what do you do when someone has no access to their devices and they need to log in to a fresh device? Some apps will need passwords, or some other mechanism to prove you are who you say you are. But then you can leverage those apps to get back into your other apps in the case of, say, a fire.
Learn to use a password manager.
I think expiration fields on cookies are optional (correct me if I'm wrong), you just can't rely on them sticking around because the user might clear them (I'd have control of which sites could set permacookies for when I didn't want to be tracked too). Which is honestly desired behavior, I'm assuming you would want the ability to delete a permacookie.
Cookies can't be synced through Firefox sync (I thought they could but just checked and my bad, they can't) -- but there's nothing preventing browser sync from handling that, and Firefox sync is E2EE so it would as secure as any other transfer method. It wouldn't be too hard to build a browser extension to allow exporting them or importing them manually; cookies are just text content so they're trivial to inspect and manipulate and even manually copy and paste into new browsers through the dev tools.
As a login mechanism, having a permacookie is somewhat insecure so most sites use expiration dates. I'm sympathetic to the desire to be able to override that, but... the mechanisms most sites use are things like signed tokens with expiration dates checked serverside, so there's not much a browser can do about blocking a website from doing that. Short of using stateless key-based authentication I'm not sure how it would be technically possible to get rid of that behavior.
----
I'm being a little bit disingenuous here in the sense that... yeah I want native file access too. I understand that cookies are not the same as native file access and the controls aren't really the same. But that's a much larger conversation with much larger scope and with more implications for browser security.
But if you're talking specifically about login, it does seem like cookies are mostly doing everything you want and your bigger problem is just that websites time-out logins? And that Firefox sync doesn't currently sync them, which... an extension could handle that.
What is the non-permanent part of a cookie, is it just that user controls for clearing cookies aren't granular enough and they're too easy for the user to accidentally delete?
I guess mobile too, iOS safari will clear localstorage sometimes. That's a very real issue (and a big reason why I want native file access), but it's less of an issue for login since occasionally losing your login permacookie isn't a big deal, it's only a big deal if you lose offline serverless webapp data.
What I'd really like is to just be able to use the native filesystem. But Firefox doesn't like that, and people apparently use that, so it's not a real standard.
At the very least, they should make the origin private filesystem user-visible with a flag. Don't allow everything, just ~/WebData/default/DOMAIN_NAME
This is... sorta true? Insofar as creepy advertisers also "remember this device". But a first-party site storing a cookie to remember a login session is not at all in the same category for me.
Sounds like a you problem, dude. You have to go out of your way to force this behavior with any mainstream browser.
All post reads like Dunning-Kruger case, he seems to know quite some stuff but also misses 3rd party cookies. Overly focuses on weak passwords completely skipping password leaks or just mentioning password reuse.
Ignoring that TOTP is actually decent interface for getting non technical and not caring at all users use random high entropy secrets. Getting regular people to keep some generated random strings won’t work.
In the end ignoring all experience of industry which is:
leaked passwords and email lists can be used in password spraying attacks where specific user is not targeted it is just opportunistic low hanging fruit automated exploitation.
Then those easy exploitable accounts in services can be used to ask connected users for loans or financial help as a scam.
I should be able to authenticate by proving access to a device such as a yubikey, as an example. Now, the site can properly remember the user. This missing feature is the fault of crummy UX, not the user.
Queen, please. I have no objection for people choosing the "forget my device" option, but the nonsensical whining about explicitly choosing this option and then bemoaning that a website doesn't remember you is absurd.
Whether a device (however you build that abstraction) has previously logged in is a high-signal data point that meaningfully increases account security at login time and all serious web security teams use it to protect their users.
It will forever be a mystery for me why people deliberately make their browsers work in ways that contradict the standards the web is built on and then manage to find blame in others when stuff doesn't work. It's already difficult enough to support all major browsers when their interpretations of the standards differ very slightly.
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
I know I am one of those who would like to disable JS, but it's just not practical. So stats really are a dangerous tool, they sometimes can end up telling you just what you want to hear...
Even if you multiplied the 0.2 by 10 or 20, you're still looking at a slice not large enough to build for.
A worker putting a helmet and appropriate clothes is losing time that could be beter spent producing value. Or if we talk about social policies and minorities, for example, even if as the word says, it's a "minority" of people so it might seem that it's a slice not large enough to improve for. A bit extreme examples, but you get the idea.
Also a 0.2% of all world population is still a huge amount of people. It's just that people who can take decisions, just don't care. But some people do care, like those in charge of co.uk websites, and then we all see how well things can be done and how poorly we've been doing in comparison.
As I tell my kid when he "wants" something, I want a pony, and a million dollars.
I don't see why the fact that some people might like that matters. I mean, given the choice for free sure I'd "like" it too. But it will never remotely be worth it to build two entirely separate web applications for every website to make that dream a reality, nor do I see the whole Internet agreeing to discard the decades of advancements in FE technologies to go back to script-free HTML.
All that said, boy would that be a great jobs program for developers over age 35 though! Imagine developing for the web with no Webpack, no JS compilers, transpilers, bundles.[1]
[1]: Or whatever you frontend folks use for your toolchain this year, or this nanosecond...
I don’t think modern webshit which requires downloading megabytes and megabytes of obfuscated code to view someone’s blog is an “advancement” for anyone except the adtech bastards.
Some applications of the newer technologies merit their use.
Most use cases, however, don't.
Bad practices abound, the "art" of programming becomes a chore made by let's say not very skilled people. Luckily there are still lots of good managers and good devs that value adequately done products, but on average that's not the case and the Web gets more and more bloated as a whole.
One day you decide to disable JavaScript in your phone (which BTW is an incredible way to speed up modern webshit, as the sibling comment puts it, in under-powered mobile devices), and turns out that lots of f*ing blogs don't load their plain text and static pictures if JS is not enabled. That's an absurd situation we've collectively ended up in.
The mere thought of having a Word document with just text, images, and a couple tables, and not being able to open it if VB macros were disabled, sounds absurd. But that's exactly what large parts of the Web have become.
I’m not sure if you’re really thinking about the impact of not having any javascript. Want to reply to a comment on HN? The whole page reloads. Want to upvote a comment? The whole page reloads. Sure you can give every comment an ID and reload back to where you were, but then you can’t have collapsible comments (because css, presumably what you’re hacking for collapsible comments without JS, can’t respond to anchor references).
There’s a million other usability things that require JS, it’s so much more than a macro language.
There are bad practices everywhere, in every field, and it feels like everyone feels they have the authority to beat down JS, and web dev as a whole, likely with zero experience working with it.
Web arguably has the best developer experience of any field. It’s so good, they took the web and put it in your desktop. Electron, GTK, KDE, everything is javascript.
The war is lost and over. Start arguing/discussing how JS can be improved instead that it shouldn’t exist (there’s PLENTY to complain about, don’t get me wrong).
Then read this comment:
https://news.ycombinator.com/item?id=36849820
> you can still view it through https://nitter.net, which I guess makes the open source Javascript-less front-end to Twitter more accessible for SEO
WHAT? I had no idea. So there is Nitter [1] frontend for Twitter -which is a platform clearly more complicated than HN- and they manage to not only work without JavaScript, but have it as one of their core motivations.
Things get even better, from that project I find about Invidious [2], a frontend for nothing else than YouTube! And again, no JS is not only an option but a highlighted feature.
After these discoveries, my bar for how JS-free we should expect most websites to be has just gone up, not down. Especially those websites consisting on just presenting text and media (i.e. the immense majority)
I agree the war is lost, though. Luckily there will still exist people desiring and making noise for a leaner and faster experience. The problem is bloated frameworks and privacy invasion via JS. Those are essentially my main reasons to want to browse the Web without JS.
[1]: https://github.com/zedeus/nitter
[2]: https://github.com/iv-org/invidious
Of course, a lot of those "fixes" now break things, because the underlying workings of windows changes a lot, but every last person I know who uses these has very odd problems with Windows that I have never once seen myself.
a lot of these things that only experts knew how to do 20 years ago are now the causes of very odd problems, because these folks don't bother to verify that these registry settings are still the correct way to make the intended changes.
In short, I entirely agree with @brasic: the article author has a nonstandard configuration (clearing cookies automatically before their expiry date) and based their entire article on the difficulties that this highly unusual and unnecessary choice has caused for them. "Hair shirt" is a great way to describe it.
> Making healthy security conscious decisions like low TTLs on local cookie storage (such as cookie purge on browser/tab close) feels unrewarded when the site enforces additional security gates on login. The point is: unique login devices may have been a good idea, but in practice the design of the web does not make them an ideal candidate for bolstering user security.
This is exactly @brasic's point, though: if a website can affirmatively identify that you've logged in from this machine before, that's a pretty good indicator that this new session is a legitimate login. We can do that through cookies, and for most users that's just fine. If you clear cookies regularly for security reasons, then you shouldn't be offended that a website asks you for extra confirmation that you are you, since that is also done for security reasons.
Clearing cookies for a domain is instructing your browser to identify itself as though it had never spoken to that server before. If you want the server to know you're still you, maybe just leave the cookies there?
The last two posts from the same author[1][2], in the past month, where of the same kind and got the same kind of reception (except that for the fediverse blog post, the top comments were either discussing about the topic of the title without addressing the (dumb) content of the article). So yeah, the mystery is why it keeps coming back.
[1]: https://news.ycombinator.com/item?id=36549218 [2]: https://news.ycombinator.com/item?id=36466133
I don't think so. Most people who understand that that will break "remember this device" also understand that clearing cookies doesn't help much with privacy. So the people who do enable that setting generally only know that cookies == tracking and do not understand that that will break "remember this device" ("Dunning-Kruger").
Cookies are cookies, not a "device". You could theoretically copy whatever cookies they put in to authenticate in other place and get automatically logged in.
> The author has configured their browser to throw away cookies when the last tab closes
If web was supposed to be stateful, this would be a bug, and the author would have had to dig through experimental or advanced settings to enable it. But because web(HTTP) is fundamentally stateless, it is a feature, and it's a feature that every browser exposes to normal user. Your browser is not expected to keep your cookies, just like your browser isn't expected to support javascript to access a website, or that you should enable them even if you could.
- 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.
- 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.
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.
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.
There's no difference between using a big Personal Computer (PC) like a desktop computer, or a small Personal Computer (PC) like a smartphone. Both are something you have.
The problem is not that a bigger computer that never leaves your home is more insecure and that the small computer with a touch screen that actually leaves your home is more secure.
The problem is also not storing TOTP in a password manager. Because a password manager can also be used from a smartphone and a TOTP authenticator can also be used from a desktop computer.
The problem is using the same device ("factor", if we're being fancy) for storing and reading both secrets, because that means if the device is compromised it'll be able to read both types of secrets.
So using a desktop computer for passwords and a smartphone for TOTP, should be just as fine as using a laptop 1 for passwords and a laptop 2 for TOTP.
Bonus points if each email has a new token and only the most recent one is valid, because then you're stuck trying to remember how many times you clicked the "email me" button. Is this the right token, or am I waiting for one more to come in?
It works but it's incredibly heavyweight. For every login you use an entire email infrastructure, doing all the email "security" processes. That a great deal of work.
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.
But if the author insists, users should be given printed password books and enable MFA.
This comment is an example of why I wouldn’t want any given website to choose my password.
The passwords will not be of any use on any other system. This would eliminate password reuse.
Edit: also, if an attacker dumps all the data today then loses access to the data tomorrow, having access to my password hashes means they can access my account and data later.
I like this idea, but what browser config does this?