Why even let users set their own passwords?
devever.net
devever.net
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)
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.
> 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”?
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.
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.
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’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:
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.
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.
I don't understand this whole discussion and maligning of passwords.
You cannot save all people. Some fixed %-age of people will always become victims - either by choosing a terrible password or by being shot in the foot by some terribly complex 5FA device-based passphrase scheme that attempts to protect them but ends up betraying the user once they replace their phone or it breaks or for any other mundane reason.
User picked passwords (1FA) are and will always be the single best solution that has ever existed for authentication, considering everything from security to usability and practicality, wholistically.
If I sign up for some crappy service that I'll barely even remember a week later I should be good to go setting my password to "asdf" and that's everything I need to log in.
Fuck everything else. https://news.ycombinator.com/item?id=36717356
Do you know that major tech companies saw a near 100% reduction of successful phishing attacks after adding yubikeys? The population there is hardly uneducated, yet they still had quite a few break-ins. Some of the companies have also nearly removed passwords, changing the minimum length requirement to something like 5 lowercase characters. They still experience a near zero, or zero, phishing success rates.
Does that mean it's a great idea?
What about losing the yubikey?
In any case it's a different matter when it comes to high stake scenarios, in which case I don't mind something slightly more sophisticated.
But not as the default for everything.
I know it's not your point and I agree with everything you're saying in this thread 100%, but DNA based login would be a username, not a password. Like all biometrics. And it'd have a really bad false positive rate if you're just doing restriction enzyme cut location tests like lots of "police work". A full exome scan ~$300-500/per might do it.
I have 5 yubikeys on multiple continents. If I lose one I can log in with the others and remove login access with the compromised yubikey.
Are you actually retarded or just disingenuous? This is hardly a workable solution even for security nuts, let alone the average person.
The actual question is: "Did they see an INCREASE in other types of attacks after using yubikeys?"
To presume that these actors who were willing to go to some illegal lengths to get this information in the first place just "gave up" because "yubikeys exist" is a dangerous way to process these facts.
His point (my emphasis):
> User picked passwords (1FA) are and will always be the single best solution that has ever existed for authentication, _considering everything from security to usability and practicality, wholistically_
So his point is that if you consider all aspects wholistically, including usability and practicality, passwords are the best solution.
I'm not saying I agree, but a 100% reduction of successful phishing attacks after introducing Yubikeys only considers security, and not the other factors.
- we lose contact with people because they get locked out of their email
- we pay more in bank account fees to subsidise fraud compensation
- we have our personal information stolen because others chose weak passwords
Given how much we suffer from other peoples' poor choices, there is a huge incentive to somehow stop people from making poor choices. By analogy, we all benefit from fences by cliffs because the family of the unlucky soul who wandered off it, the emergency services and their funders all suffer too. If it weren't for values like personal freedom, aesthetics, financial cost and an apathy towards accidents, there would be no clifftop in the world without a fence by it.
I've been locked out of my email because Google insists that "we don't recognize your device", and locked out of my other accounts because my phone was stolen, not because I didn't remember my password.
People forgetting passwords isn't a problem that's solved with other schemes. It's a problem that's exacerbated by them.
>- we pay more in bank account fees to subsidise fraud compensation
Bank account fees, seriously? I can't remember the last time I've paid any.
In any case, worrying about saving the banks a few bucks is dead last on my list of worries.
>- we have our personal information stolen because others chose weak passwords
If our info can be stolen because someone else chose a weak password, the weak password isn't the problem. It's the system that was badly designed in the first place.
>Given how much we suffer from other peoples' poor choices,..
We don't.
>By analogy, we all benefit from fences by cliffs
The analogy doesn't hold because you have to first show that alternatives to passwords are better for the users, even those in the category you mention.
Sorry, I should have clarified: that was in reference to users being unable to successfully use the parent's hypothetical 'terribly complex 5FA device-based passphrase scheme'. Passwords don't get any blame here.
> Bank account fees, seriously? I can't remember the last time I've paid any.
OK, fractionally lower interest growth then, or less frequent premium bond wins. In any case, the bank is going to find a way of passing the cost of business to you, so you have an indirect incentive for their business to be cheaper to them.
> If our info can be stolen because someone else chose a weak password, the weak password isn't the problem. It's the system that was badly designed in the first place.
That is correct for some kinds of personal information, like how storing documents on a 'cloud' without client-side encryption is a badly designed system for privacy. However, there are genuinely some occasions where a third-party needs to have access to (not just verification of) your information, but also has a responsibility to keep their copy secure. A hospital might need to see your medical records to do its job, for instance.
> The analogy doesn't hold because you have to first show that alternatives to passwords are better for the users, even those in the category you mention.
I completely agree with you. All I'm saying is that a lot of people will try to replace passwords (because we all have an incentive to improve the situation), even if their replacement fails at being better for users!
An example of this is chargeback fraud on marketplaces. The way the fraud works is someone buys a bunch of credit card numbers off of the dark web due to some websites’ bad security practices and a data breach. The fraudster then ATOs a merchant account on some marketplace platform or makes a fake account, e.g. Doordash, Airbnb, Shopify, etc. The ATO is usually possible because some subset of the merchants of the platform use the same passwords on another website that has been compromised, again, some data set is sold on the deep web. The fraudster then either has to change the payout method of the marketplace merchant account, which they can usually do by ATOing an acquiring bank that they can access the funds in some way, again due to another external institution with tenuous security practices.
Finally the fraudster charges all the stolen credit cards and in most cases leaves the platform taking the liability. This results in the platform pushing up take rates against their merchant accounts, which almost always gets passed back to the consumers of the service (us) by increasing the prices of the service.
The problem with passwords is that we expose ourselves to everyone else’s negligence. You might handle passwords with all the best security practices to be known but you expose yourself and your users to every other system’s incompetence. It wasn’t until I saw this play out, that I understood passwords aren’t just a disservice to the negligent compromised user but really to the whole ecosystem of the internet that partakes in password authentication.
Yes, there is always a trade off in security and friction. This has always been true. But if we know passwords are faulty and essentially useless, why continue with such a bad practice? To reduce friction to a maximal extent? By that logic we might as well throw out the concept of security altogether. Why not just make it so a user only has to enter their email/username and nothing else? Let me know how that goes for you. I think webauthn is likely the sustainable, long term solution but we’ve got a ways to go before some of the inane thinking around password preservation dies out.
This is a temporary condition, and they can create another email or communicate via other means. If some part of your life is highly dependent on a single email address remaining 100% available, you've made a mistake already.
> - we pay more in bank account fees to subsidise fraud compensation
I have a feeling that if you got rid of passwords, new forms of fraud would become prevalent, and the fees would remain. Humans are humans, taking away the password does not insulate them from their own basic nature.
> - we have our personal information stolen because others chose weak passwords
It's the same issue as above. Your information has value, so it will be sought out by people who wish to exploit it. Social engineering exists and won't go away just because we got rid of a single token based mechanism.
> Given how much we suffer from other peoples' poor choices,
It's a poor choice to be dependent on email or to give your personal information away to every single form that asks for it. You can balk at the external factors if you like, but you won't solve anything by it.
For instance if grandma wishes me happy birthday, and she gets hacked, now they know my birthday. Grandma also probably gave away my mother's maiden name as well.
It's trivially easy to generate passwords with 128 bits of entropy and have them managed by a password manager.
Until the password manager gets hacked. Well, tough shit. If your primary device gets hacked, the hacker just has to wait until the next time you log in with the bullshit gazillion factor authentication.
And it always collapses to 1FA for the lost password recovery process, which you're gonna have to provide if you want customers.
Can you elaborate? This scenario assumes that a) the primary device is the only 2FA option b) there is no one-time codes and c) the attacker persistently waits until a 2FA request comes through then somehow hijacks it with their own connection request?
Now, the rest of your argument kinda sucks, sorry to say. There are things we can do to make everyone's personal information more secure. Using childhood clubhouse password "technology" is not cutting it. We can definitely do better than shared secrets that get leaked to the whole internet on the regular. We can be more secure with an easier to use UI. Yes, people will still get pwned, but less people will, the bad guys will have to work harder.
I can count on one hand the services that are critically important enough to warrant unique passwords and good practices anyway.
All the other services I have accounts for? I literally can't care if some yahoo in WhereTheHellistan wants to and does get in, there's nothing valuable in there. They all get the same, simple, short password because that's the value of the things behind the password.
Yes, this means all of you reading this are quite welcome to try and steal this HN account guarded by the same, simple, short password. I don't care, all you'll be getting are worthless shitposts and things of similar value in any other services you can find and breach with the same credentials.
Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token does expire, right?
> We are literally living through the gradual phase-out of third-party cookie.
Yes, and a "remember this device" uses a first-party cookie, so it isn't affected.
> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed
So you are intentionally breaking the web and complaining that things are cumbersome? Gee, I wonder why.
> [..] yet that same website is happy to let me authenticate using an API key for API access as a single authentication step. No “2FA” here.
Yes, because that API key is often used to sign the request, contains enough entropy to make guessing impossible, and because the URL is hardcoded in the app phishing is impossible.
> guaranteed use of a high-entropy secret obviates the need for additional authentication
No, it does not. See: phishing.
Forcing the use of website-generated passwords is cute, but doing basic entropy checks on a user-provided password pretty much solves the issue anyways. Why bother alienating a significant fraction of your user base?
Authentication is pretty much a solved problem. Use a password locker encrypted using a single remembered key for the "something you know" part, and use a physical Webauthn token for the "something you have" part. Stop trying to reinvent the wheel, it'll only end up annoying your users.
No it does not. Users will find one high-enough-entropy variant of their password, and reuse it across all sites for life.
> Authentication is pretty much a solved problem
Hrm. It might be solved for you and users like you - but it depends on your site's demographics: most internet users on the whole will not know anything about encrypted "password lockers" and "physical Webauthn tokens". Browser-managed passkeys, on the other hand, stand some chance of being easy enough to use while enforcing good security and high entropy secrets, but lack widespread adoption so far.
Passkeys can’t come soon enough, and email providers better make sure they are never compromised.
That's a bit like saying laptops aren't secure. Well okay, laptops are not inherently secure, but my instance of laptop is secure (enough). Same with e-mail; there's nothing inherent in e-mail that would make it secure, but the way my e-mails have been set is secure (again, "enough" for practical reasons).
>> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed >So you are intentionally breaking the web and complaining that things are cumbersome? Gee, I wonder why.
Clearing cookies isn't breaking the web. Some of your websites functionality may require things to happen again if I clear cookies, but a) that seems like a you problem, and b) doesn't seem broken to me.
> Yes, because that API key is often used to sign the request, contains enough entropy to make guessing impossible, and because the URL is hardcoded in the app phishing is impossible.
Not sure where you're seeing this "often", but most services I have API keys for work _exactly_ like passwords. I have to jump through a few hoops to get a working key, true, but once I have it, it's essentially a password, and used in the same way.
> Authentication is pretty much a solved problem. Use a password locker encrypted using a single remembered key for the "something you know" part, and use a physical Webauthn token for the "something you have" part. Stop trying to reinvent the wheel, it'll only end up annoying your users.
I don't feel like it's a solved problem if normal people refuse to do that. That's a solution in the same way that the advice "Everybody be nice to each other" is going to make the world a better place.
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 :)
This is not actually true. API keys are highly disfavored because they are easily stolen, and these days if you try to create an access key in AWS, you'll be shown a screen called "Access key best practices & alternatives" which tries to get you to use something else (such as temporary credentials from the EC2 metadata service). There's even federation between providers now, so for example if you need to access your AWS account from a GitHub Action, you don't need to use API keys (https://docs.github.com/en/actions/deployment/security-harde...)
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.
> but you still need a Personal Access Token to integrate pull requests and issues with your Git client
This is what I do with Emacs using a package called Magit[1]; VS Code comes with something similar.
[1]: https://magit.vc/
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).
My only gripe with this approach is that my specific password is a bit awkward to type. I tend to pick passwords at least partly based on "keyboard feel" and it's annoying that there's one word that has a lot of repetition of colocated letters.
Other than that it's a fantastic model and hugely preferred over routine password resets.
Does your company also use 2FA? I'd be curious to see if very long passwords are secure enough to not need the 2FA anymore, as most methods are annoying to the user.
correct horse battery staple?
https://www.explainxkcd.com/wiki/index.php/936:_Password_Str...
Note that if your attacker knows the dictionary used, the effective strength of a passphrase isn't based on its string length but on the number of individual words within the phrase.
Six words gives an effective key strength of 2^77 bits.
I'm assuming they stuck with four to make them memorable by actually humans. Even then I have my moments where I type in an adjective form instead of a noun for a particular word/variant.
Coming up with grammatical combinations (adjective noun verb adverb preposition article noun, say: "brown dog ran quickly past the barn") might create more memorisable patterns, though at a cost of key strength.
Taking this to its logical conclusion, we'd have poetic stanzas of epic sagas randomly generated for mnemonic power utilising rhyme and meter....
TOTP and passwords are not the 'similar' because TOTP is a secret generated from the 'key' and is only valid for a short time period
this make usage of that secret vastly more challenging for attackers, especially at scale.
I've seen real attacks where passwords are stolen, it is impossible to keep track of that. However for TOTP since the attacker has to login NOW, you can very easily detect anomalies of a new IP addr with many successful logins for different accounts
Or to put it differently, when you capture a password it is always valid credential but for TOTP, it requires more advanced infrastructure(automatic logins, save tokens)
and even then the token will eventually expire, with password you can generate infinite tokens
It's not though. The whole point is the secret moves once, from server to client (ignoring user exports and whatnot). Pass(word|key)s are basic authentication, and so have to be transmitted with every request. That's a huge difference in surface area. Also they are guaranteed to be high entropy, unlike user-picked passwords with no filter.
1. TOTP is time based, after 30 seconds it means absolutely nothing, you cannot recreate the 'secret key' from that number
2. with TOTP everything is well-known. TOTP will usually generate a 6 digit 'secret', this makes managing it very predictable:
6 digits = 1,000,000 options(including all zeros) we can easily calculate a good security margin
like: 5 attempt - 5/1,000,000 = 0.000005% chance of success Very predictable security margin
for passwords it's a huge unknown, it entirely depends on the user password quality
Passwords are used because they are convenient and intuitive.
Once you use a 'password manager' you basically have a glorified key generator/storer
We already have so many alternatives from GPG keys to FIDO/FIDO2 solutions
Security isn't always the first priority when running a website/app, it is the sad but honest truth(coming from security expert with over a decade of experience)
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).
It's a combo of:
* All accounts need to be tied to an identity, generally in the form of a Mainland Chinese phone number which is linked in the backend to a Government ID/Foreign Passport
* Mobile first development where mobile is assumed to be the primary or only way to interact with most services.
* Overwhelming dominance of two 3rd party identity providers (WeChat and Alipay)
* WeChat mini-apps taking over most of the small use cases where authentication is baked in.
The usual flow is that you sign up with a phone number as your username and authenticate with SMS 2FA. Because it's a mobile app, it doesn't have to deal with web bullshit and actually remembers you across sessions spanning months. To reauthenticate on a different device, you just enter your phone number and use the same SMS 2FA to login.
The web flow for a lot of sites is that they require you to open the logged in mobile app and scan a QR code to login on the web.
A few legacy sites like Taobao still support password login but they're by far not the majority.
Looking forward to them being replaced with passkeys.
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)
A compromise between allowing users full control over their passwords and none at all would be generating a list of permitted alternatives and having them pick one. What I'd then like to see is that early on you are required to supply it quite frequently, giving you a chance to commit it to memory, but then allow having the browser store it or session cookies with longer lifetimes be used. But I've yet to come across a login system where ensuring the user learns their password and doesn't forget it was a priority at all.
The whole point of a passphrase is that IT DOESNT CHANGE HANDS EVER.
The reality though is that computers subvert the system of passphrasing because the complexity required for passphrases within a computing systems is easy for computers to beat but hard for people to recall
So you have a perfect situation where the historical context is maintained (person will remember their self-generated passphrase) but the system also can probably guess any passphrase that a human could remember without any additional tools
So now, given that we REQUIRE more complexity than people can recall, we force people to use additional tools for creating/managing their passphrases which subvert the entire principle of a passphrase. Namely:
IT DOESNT CHANGE HANDS EVER
So the whole system is corrupted at it's root and there is no way to solve this problem with the current structure
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.
Today I would just use passkeys.
I don't support passwords on any of my services. Emailed magic links and SSO are the encouraged methods, even with all the tradeoffs. I've considered allowing users to generate tokens similar to OP, but some percentage of them will be emailed around and pasted into phishing sites etc.
But something like this could work as an option, especially if it could integrate with a couple popular password managers as well. Not sure if that's even possible.
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.
The first diatribe against 'nondeterminstic' logins demonstrates a naivety to both account takeover and botting mitigations.
Passwords have to be assumed to be low entropy long lived credentials which are horrible from nearly every standpoint.
API keys at least have a high entropy but are long lived and difficult to secure. (How many times do we need to see apikeys accidently leaked in a pull request?). They also do nothing from a phishing perspective.
OTP is a high entropy and the authenticated credential exchanged has a very short lifetime. The exchanged credential may also be much shorter. It is still susceptible to phishing mitm attacks.
Thankfully it's 2023 and webauthn is here for the browser. We can keep long lived secrets in a secured environment, be resistant to phishing and if the risk model includes physical loss of device utilize pins / passwords even if they are low entropy.
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.
Corp policies asking users to change their passwords every 60 days or whatever, combined with the ever-more-arcane password content requirements -- yes, why the HELL are you asking me to change my password? I'll just go to one of the online passgens, generate a string, and immediately save it in a text file in my local home directory, because there's no way I will remember it.
Might as well generate passwords for your users already. Don't email me asking to come up with my own, send me a link to a form where I can copy the new password from.
I'm not saying you're wrong, but it would be a definitive trade off.
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.
- 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.
...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.
Yeah, but at the same time if you keep loosing access to your accounts because you can’t remember your password, you are just 1FA with your email or phone number. Might as well then skip passwords entirely and use sign in via phone or email.
Some websites think they enforce secure passwords, but don't seem to understand that a random password will occasionally have duplicate characters, or might include symbols other than @!#$, or might be longer then 10 characters.
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.
If anything they should only be used for resetting the account coupled with successful use of a 2nd factor, I suppose, but recovery keys aren’t a bad compromise depending on the user
Legitimising 'Risk-Based Authentication' as a strategy is a big mistake in the software industry. It allows criminals to sit on compromised credentials, trying different combinations of accounts, user-agents and IP addresses until they get the jackpot: a website decides this time that there is 'low risk' to the login attempt, and the bad actors are in. When you make security-critical decisions with statistics (in this case, whether to permit a login attempt), you are essentially guaranteeing that there will be a certain proportion of breaches, because you set the risk threshold!
Our efforts as an industry should be in making sure that credentials are not stolen in the first place: better and more widespread encryption, phishing resistance (with UX that supports that) and low-level security audits of encryption software and hardware are just a few of the areas where research and development would be valuable.
Pardon my ignorance, but isn’t this saying “we can’t rely on reducing the likelihood of breaches, we should focus on reducing the likelihood of breaches”? Your recommendations are no more deterministic than the methods you eschew.
It can't be your wife's name, or your birthday, your kids' names, car license, or anything which someone could research.
We've had this discussion before.
From the web site’s POV I certainly do.
But my password manager generates the password and remembers it for me and I only ever see it if the generated one somehow violates the site’s arcane password rules and thus requires a bit of manual manipulation. Which rarely happens.
Nowadays, websites and apps force users to follow a certain pattern when setting their password. Since users have to comply in order to successfully proceede with setting their password, does it still count? (Count as in letting users set their own password)
We let users set their own passwords because users are unable to remember secure passwords, which would create a lot of work for people running the service (and the user as well), even vulnerabilities because we'd be habituated to recovering lost passwords.
When the user can set their password they will set an insecure one that they can remember, eliminating most of the password reset work. Then when the user is compromised it's their fault. This compromise works because most users aren't particularly vulnerable-- no one is trying, or no one cares if they are compromised.
Why don't we just rely on the recovery security? well Mozilla's persona thing pretty much did.
It also forces me to look at my email inbox, which can be a pretty annoying thing if I am trying to relax and now see some email with bad news - requireing me to break the flow again.
Most important however: it is simply wrong and not needed. The flow has been settled.
What's preventing you from getting the email code from another device?
Sure, you could say:
P[password X is compromised] * P[password Y is compromised] <= P[password X is compromised]
If your password recovery flow only requires the user to enter their email, then you've done nothing to raise the security of the account. At that point, the only important password is the one for the email associated with the account- the password for your login system, and all others like it, can be considered mutable and temporary.
If you have "we sent you a code" MFA and email-based password recovery, you have probably de-incentivised hacking of your service. But, the approach also puts a target on the email service provider's back.
Edit: I’m talking about first-party cookies.
Any time you give developers access to storage on the user device for any reason, you've given them a way to track users. First-party cookies are a decent compromise in my book: you can track users, but you can only track their movements on your own domain.
Third-party cookies don’t have this ambiguity, they’re unequivocally bad.
We want apps to be able to store session IDs so that I don't have to send my username/password with every single HTTP request. But as soon as I've given you permission to remember my session, you can use that to start tracking my movements on your site. There's no way around that.
The only thing we could do is add a layer on top that prevents most sites from using cookies at all—make cookies a permission similar to camera and screen sharing. But first-party cookies aren't easy to use for abusive purposes and (as we all found out post-GDPR) popup fatigue is real, so I'm personally okay leaving them as is by default. Anyone who isn't comfortable with them can easily install extensions that implement more complex behaviors.
I like this idea, but what browser config does this?
They will simple use the same login as their tamagotchi pet.
Instead of eliminating passwords, they are added to something else to get 2FA.
How would a users use different devices?
As or more important as house keys
If you aren't big enough to maintain your own operating system and web browser, you shouldn't be storing passwords.