This is truly terrible advice. Most people use the same or very similar passwords across services, suggesting to rely on email for secondary authentication is like locking a safe in a room, then...
A decent alternative to passkeys, if you need the extra layer of security, is to lean on email for the first login from a new device. Treating email as a second factor, but only on the first login from that device. Everyone has email, everyone understands email.
This is truly terrible advice. Most people use the same or very similar passwords across services, suggesting to rely on email for secondary authentication is like locking a safe in a room, then putting the key to the safe in the same room. Sure you still need to break into the room, but once you've done that you can easily find the key and break into the next thing.
And the solutions, like scanning a QR code with a separate device, are cumbersome and alien to most users.
Is it? Maybe I'm biased because we use such a solution in Sweden to sign into literally all government services, banks, insurance, even some third party services, etc. We cannot use a username/password combo, our only option is to sign in using our personal number (equivalent to social security number) and authenticating via the app that is issued via our banks.
If literally our entire nation can do this, including most old people, then I'm sure people can learn to use passkeys efficiently.
Have you tried to use them in a heterogenous environment? I have degoogled android, occasional iOS use, occasional Mac OS use, and heavy Linux desktop use. Passkeys are an abomination at the...
I'm sure people can learn to use passkeys efficiently.
Have you tried to use them in a heterogenous environment? I have degoogled android, occasional iOS use, occasional Mac OS use, and heavy Linux desktop use.
Passkeys are an abomination at the moment, I don't care how determined you are to use them efficiently, right now they just suck.
I only have passkeys on my phone and scan QR codes to sign in to other devices, if that's what you're asking. I will say though that our national passkey solution (called BankID) is MUCH easier to...
I only have passkeys on my phone and scan QR codes to sign in to other devices, if that's what you're asking.
I will say though that our national passkey solution (called BankID) is MUCH easier to use than third-party passkeys (such as Bitwarden, MS authenticator, etc).
I tried that, and bitwarden when I was experimenting. Didn't matter, as soon as I got android, iOS, Linux and Mac in the mix, it always ended up broken in one way or another. Either a browser on...
I tried that, and bitwarden when I was experimenting.
Didn't matter, as soon as I got android, iOS, Linux and Mac in the mix, it always ended up broken in one way or another. Either a browser on linux or mac would work, whilst others wouldn't, or you couldn't create new passkeys on Android if you found you happened to need that, it was all just a mess.
Thanks for sharing your experience. I’ve been on the fence about trying it out to see if it could replace my password manager setup. Reading your comment makes me think that would be a waste of...
Thanks for sharing your experience. I’ve been on the fence about trying it out to see if it could replace my password manager setup. Reading your comment makes me think that would be a waste of time. There are better ways for me to waste my time.
I’ve had a much smoother experience than @trim. I have an iPhone, two MacBooks (one old intel, one new apple silicon) and a Windows desktop (was 10, now 11). 1Password syncs the passkey around...
I have an iPhone, two MacBooks (one old intel, one new apple silicon) and a Windows desktop (was 10, now 11). 1Password syncs the passkey around where I have it installed and integrates seamlessly into mobile Safari and desktop Chrome/Firefox browsers. On my work MacBook, I scan the QR code with my phone and I’m in. Having them in 1Password alongside traditional passwords means I don’t have to think much about whether a particular site uses one or the other.
For some services that I use frequently on company devices, I’ve created another local passkey after logging in once via QR code. Previously I’d have to open up 1Password on my phone and manually type a password since I’m not installing my personal password manager on company hardware.
So high impact financial services, infrequently accessed? Seems like a great case for prioritising security over a frictionless login. I'm not sure e.g. Tildes deserves the same tradeoff. If every...
literally all government services, banks, insurance
So high impact financial services, infrequently accessed? Seems like a great case for prioritising security over a frictionless login.
I'm not sure e.g. Tildes deserves the same tradeoff. If every site did this and you were doing it ten times a day, it would get more frustrating. Also would you remember to take care to transfer your passkeys for that app you use twice a month when switching phone brand?
BankID is extremely frictionless, it takes 2 seconds to authenticate. It's actually something I use quite often, at least a few times a week. It’s also much easier to set up than other passkey...
BankID is extremely frictionless, it takes 2 seconds to authenticate. It's actually something I use quite often, at least a few times a week.
It’s also much easier to set up than other passkey solutions that I’ve seen too, even if you lost your previous passkey. Our banks give us hardware authenticators that we can use as well to authenticate, this is used when set up the passkey if we don't have one already.
It sounds like you have a government-run system that serves the entire populace in a sensible and standard way. In that environment, led by an entity that truly wants people to be more secure and...
We cannot use a username/password combo, our only option is to sign in using our personal number (equivalent to social security number) and authenticating via the app that is issued via our banks.
It sounds like you have a government-run system that serves the entire populace in a sensible and standard way. In that environment, led by an entity that truly wants people to be more secure and has no other motive, I agree something like this is sensible. But here in the US, it's going to be a way to further capitalist constipationmonetization(1), with the security benefit being secondary.
1-autocorrupt produced constipation, and for once I think it know what it is doing
BankID is actually operated by a private company owned by several of our largest banks. According to that wikipedia page 94% of swedish smartphone users use BankID. I know some people are not too...
BankID is actually operated by a private company owned by several of our largest banks. According to that wikipedia page 94% of swedish smartphone users use BankID. I know some people are not too happy giving a private company that much power. Personally I think that it works pretty great, and I'm not that worried about it. But it surely is centralizing a lot of power and information, which is not all good.
Funnily enough the service is not government run, but it’s co-owned by all major banks and has been adopted by the government for their services as well. But you’re right, it would likely not work...
Funnily enough the service is not government run, but it’s co-owned by all major banks and has been adopted by the government for their services as well.
But you’re right, it would likely not work in the US. It is heavily regulated in Sweden.
And does the bank issue you a smartphone which can run the app, and repair/replace it as needed? Do they support the app on less-popular platforms? Unless they do, which I seriously doubt, that...
authenticating via the app that is issued via our banks
And does the bank issue you a smartphone which can run the app, and repair/replace it as needed? Do they support the app on less-popular platforms?
Unless they do, which I seriously doubt, that doesn't sound anything like a strict improvement over username/password to me.
In what way do you think that it's not an improvement? I'm pretty sure it's more secure, and for me personally, and most people, it's also more convenient. It's also not the only way you can login...
In what way do you think that it's not an improvement? I'm pretty sure it's more secure, and for me personally, and most people, it's also more convenient. It's also not the only way you can login or sign your transfers (I only checked my own bank, but I'm pretty sure others offers alternatives as well), so you don't need to get a smartphone if you don't want to.
No but they offer free hardware authenticators as well. The BankID software works on iOS/Android but also Windows/macOS. It’s a universal personal authentication app, so each bank doesn’t have...
No but they offer free hardware authenticators as well.
The BankID software works on iOS/Android but also Windows/macOS. It’s a universal personal authentication app, so each bank doesn’t have their own proprietary.
While an email login might be compromised alongside a password for a login, it's also generally much more secure than the most common alternative: SMS and/or automated phone call. And wiser...
Most people use the same or very similar passwords across services, suggesting to rely on email for secondary authentication is like locking a safe in a room, then putting the key to the safe in the same room
While an email login might be compromised alongside a password for a login, it's also generally much more secure than the most common alternative: SMS and/or automated phone call. And wiser providers have already separated usernames from emails and phones (ironically like the good old days when having an 8-character username was far better than an email due to storage constraints).
The biggest problem with requiring an app is mandating that everyone has an active smartphone, which also means enforcing the Android/IOS duopoly. Unless your banks are also required to support any arbitrary operating system or an alternate method. While that might not be a big problem in countries with good social safety nets, a lost or broken phone can make the difference between being able to afford a bill or not that month.
They do. Most banks offer some sort of hardware authenticator as well. But you can also install the BankID software on a computer, but then you can only authenticate on that specific computer...
The biggest problem with requiring an app is mandating that everyone has an active smartphone, which also means enforcing the Android/IOS duopoly. Unless your banks are also required to support any arbitrary operating system or an alternate method.
They do. Most banks offer some sort of hardware authenticator as well. But you can also install the BankID software on a computer, but then you can only authenticate on that specific computer (similar to how Windows Hello login works on Microsoft sites).
Incidentally the way Microsoft handles their accounts being deeply engrained in the OS makes it a massive pain in the butt to install Minecraft on my kid's account unless I want to set them up an...
Incidentally the way Microsoft handles their accounts being deeply engrained in the OS makes it a massive pain in the butt to install Minecraft on my kid's account unless I want to set them up an entire new OS profile.
On Linux, for Java, it's fantastic. It's what I use on the Steam Deck and my kid's laptop. My kid needed a Bedrock install to join a friend's game. I had the audacity to try to install the...
On Linux, for Java, it's fantastic. It's what I use on the Steam Deck and my kid's laptop.
My kid needed a Bedrock install to join a friend's game. I had the audacity to try to install the official launcher under my Windows account with their account, and now the accounts are in a horrifically intermingled mess on my computer, the best resolution to which I could find online was 'delete child account and family group, then create new child account and buy a new copy of Minecraft.' Oh and I probably need to format the machine to un-fuck the OS profile as well.
So instead we told said friend to join our Java server which has Geyser, solving the problem.
Was just catching up on darknet diaries podcast about security this morning and was on one where at one point the podcaster switched to ai text to speech mimicking his voice and I did not catch it...
Was just catching up on darknet diaries podcast about security this morning and was on one where at one point the podcaster switched to ai text to speech mimicking his voice and I did not catch it AT ALL that he had swapped. The world is going to need a strong authentication method to be commonly used everywhere because our voice and video is no longer going to be proof enough of who we are. The only way I can see it is if we have a strong encrypted token of some sort to prove our identity, that must be one of the checks for financial related accounts we hold, so people are going to need to learn it fast imho.
I had thought that passkeys would be the saviour of my elderly parents password woes. Even with a vault that's the easiest to work with (BitWarden), they're forever not being able to use it and...
I had thought that passkeys would be the saviour of my elderly parents password woes. Even with a vault that's the easiest to work with (BitWarden), they're forever not being able to use it and going through password reset flows that they then don't do correctly, and we end up where the old password doesn't work, and the new one doesn't either because they didn't do the reset correctly.
So I started looking at passkeys for a couple of my own accounts, and there's no way they'd be able to cope with this. It'd be far more complex and confusing for them, and that's even before we get to the problem of not everything supporting them, and (at the time -- there are partial foss solutions to this now) extreme vendor lock in , but they have a multi OS environment, Mac, Android, ChromeOS and iOS.
So back to managing BitWarden it is.
For what it's worth, I use KeepassXC with Firefox as my Passkey provider for the couple of accounts I enabled it for. This allows me to use my passkey login through my Keepass vault, on both Linux and Mac OS, though not Android sadly. Still, the fact that it's in my vault, under my control, and works on my desktops and laptop machines, is good enough. I expect it'd work fine on Windows too.
Passkeys are not ready for the hoi polloi yet. Or, perhaps anyone.
yeah we did that. One day the notebook went missing :( we think they threw it out. And also, hard to tell which ones were crossed out. It was almost good, right up until it wasn't. I'd far rather...
yeah we did that. One day the notebook went missing :( we think they threw it out.
And also, hard to tell which ones were crossed out. It was almost good, right up until it wasn't.
I'd far rather guard against internet threats than evil maids, if I could only help them guard against one or the other.
We're just about squeaking by with bitwarden, it helps that I also have a Macbook so I can usually fix things remotely over screen sharing when they manage to break a login, as I don't live especially near by.
I work with many elderly clients, who all have the same password problems. We keep a single-page password shortlist in a Word document, and print copies so that there is one wherever they may need...
I work with many elderly clients, who all have the same password problems. We keep a single-page password shortlist in a Word document, and print copies so that there is one wherever they may need it. One in the office, one on the coffee table next to where they use their ipads, stuff like that.
Even so, they still occasionally find themselves resetting, scribbling, not crossing out, getting confused. Once every couple of months, I'll swing by, unceremoniously shred the marked up, confusing ones, reset what needs to be reset, and print new copies, with the latest date clearly written across the top. I do not try to play the 'which one of these scribbles is correct' game. We just reset properly and move on. If they come across an older version that I missed, they know to just toss it and reprint.
This has proven to be the most tenable, least-frustrating method so far. It's not perfect, because no system is, but I've been doing elder care for family and close friends for more than 15 years, and work in the IT field, so I've had a lot of time to try different things.
It worked well for me too, until a tipping point about a year ago. Part of the problem with bitwarden seems to be that, on the computer, the browser extension keeps unhelpfully signing itself out...
It worked well for me too, until a tipping point about a year ago.
Part of the problem with bitwarden seems to be that, on the computer, the browser extension keeps unhelpfully signing itself out from time to time, despite my trying to set options so that it doesn't do that.
If it does sign out of the extension, that often begins the failure prone email reset chain of doom.
It's a genuinely hard problem, isn't it. Some of my older clients are also now dealing with various degrees of cognitive impairment, including Alzheimer's. I've switched them from...
It's a genuinely hard problem, isn't it.
Some of my older clients are also now dealing with various degrees of cognitive impairment, including Alzheimer's. I've switched them from computers/laptops to ipads when they can no longer use mice and keyboards, although they are still not a panacea.
The number of scam apps with predatory pricing (ie, 'Memory Cleaner' cache clearer, for $79/week subscription!) is crazy, and shame on Apple for being complicit. If you want a 'fun' challenge, try and find a coloring book or jigsaw puzzle app that is genuinely ad-free, paid or not. 99% of them are targeting older adults, and every single one of literal dozens that I've tried has ultimately served an ad like I describe.
Yes! I’ve been helping out my elderly neighbors and they are using that. At first it seemed sketchy, but then I realized it is by far the most secure solution they could’ve picked. They are using...
Yes! I’ve been helping out my elderly neighbors and they are using that. At first it seemed sketchy, but then I realized it is by far the most secure solution they could’ve picked. They are using unique passwords AND it’s not on any of their digital devices. That’s pretty good security in an age where the biggest threat is coming from online criminals.
I agree that passkeys have problems in terms of usability, but from a technical standpoint they’re a lot more secure than passwords. There are other solutions though, like Bitwarden, that lets you...
I agree that passkeys have problems in terms of usability, but from a technical standpoint they’re a lot more secure than passwords. There are other solutions though, like Bitwarden, that lets you store and use your passkeys on any device.
Hmm, I might be being cynical but that FIDO proposal sounds like a Microsoft, Apple, Google thing where you might be able to transfer between those. Hope it ends up not just including the tech...
Hmm, I might be being cynical but that FIDO proposal sounds like a Microsoft, Apple, Google thing where you might be able to transfer between those. Hope it ends up not just including the tech giants, I don't want them to have my credentials /at all/
These discussions are exhausting. So, in the spirit of finding myself in a hole with a shovel and starting to dig, here's my contribution. There are obvious tradeoffs between both approaches....
Exemplary
These discussions are exhausting. So, in the spirit of finding myself in a hole with a shovel and starting to dig, here's my contribution.
There are obvious tradeoffs between both approaches. Neither is categorically superior nor inferior. So, here's a table of the tradeoffs I see. If you have an authentication use case, pick the applicable rows in the table to see why you should vigorously reject one approach or another. ("No" is the "good" answer in each row.)
Password in head
Password manager
Hardware token¹
Transferrable token²
Can be stolen from third party and reused
Yes
Yes
No
No
Can trivially/noninteractively be phished³
Yes
No
No
No
Can complicatedly/interactively be phished⁴
Yes
Yes
No
Yes
I'm screwed if I lose my phone/hardware token⁵
No
No
Yes
No
Do you ever reuse passwords, or do you actually memorize secure unique passwords per site? Don't lie.
Yes
No
No
No
Likely to be platform-locked
No
No
No
Yes
¹ One where it's impossible to extract the private keys, e.g. a Yubikey. Don't talk to me about chip decapping, if the CIA is after you, this whole conversation is moot.
² One where there is a mechanism to transfer the private keys; note that it's not really possible to reliably distinguish between another device belonging to the user and a device belonging to an attacker when transferring keys.
³ E.g. by typosquatting, sketchy links in emails, etc.
⁴ E.g. by pretending to be tech support and walking someone through revealing/transferring their secrets.
⁵ I'm assuming appropriate backup hygiene here. You could of course lose the only copy of your password manager DB and then be screwed, but duplicates (and encrypted cloud backups) are a normal feature of such systems.
This has basically always been my worry with all of this. Yes you're assuming proper backup hygiene, but god do I think that's extremely hard to actually get anyone to do correctly.
I'm screwed if I lose my phone/hardware token⁵
This has basically always been my worry with all of this. Yes you're assuming proper backup hygiene, but god do I think that's extremely hard to actually get anyone to do correctly.
According to your chart, the only advantage that a transferable token has over a password manager is that it can't be stolen by a third party and re-used. If you're talking 'directly talking to...
According to your chart, the only advantage that a transferable token has over a password manager is that it can't be stolen by a third party and re-used. If you're talking 'directly talking to site that was stolen from', that's true, but provided the user follows through on not-reusing-passwords, the impact is minimal (and almost all sites where significant danger would occur are much less important....this isn't 1999 after all and banks/government institutions mostly have their act together).
And even then, I'd contend that if you're using a password manager, that reuse is much less of a problem especially if hardware or transferable tokens are used in combination for 2FA.
The biggest flaw in these discussions is that people feel that switching to passkeys obviate the need for 2FA. Using passwords with a password manager is still superior as a first-factor, especially given the platform-lock. Using passkeys, 2nd verified-device, and hardware tokens as a 2FA where you'll get locked out, but usually have a recovery process, are much less dangerous in that vein.
I think with “I’m screwed if I lose my phone/hardware token” that assumes you only have one. Generally speaking, for every door, you should have two independent keys so you have a backup, and that...
I think with “I’m screwed if I lose my phone/hardware token” that assumes you only have one. Generally speaking, for every door, you should have two independent keys so you have a backup, and that concept is somewhat independent of technology - you can mix and match.
This might also make being platform-locked a non-issue, provided that those two independent keys are on separate platforms.
Are you sure about that? I would argue that getting people to tap a blinking YubiKey is easier than getting them to enter an application specific password. I do realize that CTAP2 allows for...
Can complicatedly/interactively be phished
Hardware token - No
Are you sure about that? I would argue that getting people to tap a blinking YubiKey is easier than getting them to enter an application specific password. I do realize that CTAP2 allows for access to a specific private key to be tied to some origin information (e.g. a TLS certificate), but that requires a trusted client application (e.g. Browser) to accurately provide such information to the hardware token. The issue here is, that the YubiKey just blinks. It doesn't tell you what it's authorizing, it just tells you that some operation needs to be authorized by tapping it. Wether that operation is an authentication request for the service you think you're interacting with, an authentication request for some other site, an enrollment request, or some other thing entirely - you don't know from the blinking alone.
Can be stolen from third party and reused
Harfware token - No
Well, true. All you could do with the keys stolen from the service side is emulate the service and get signed challenges from a hardware token you're actively interacting with. (Although the service side is arguably the second party, so I'm not quite sure what you mean by third party with regards to password stealing. Stealing from someone that's already stolen it? An authentication service that gives a third party access to your password hashes in a legit scenario is kinda problematic by design.)
What's missing from your table is 'Can be stolen from first party'. It's much easier to steal your hardware token, than it is to steal your passwords, if you have physical access. And setting a PIN for FIDO2 operations is actually optional and up to the service provider to require. I wouldn't want anyone who finds my YubiKey on my desk to be able to login to many of my accounts without any additional knowledge. Hence your hardware token is a great second factor, but should not be your only factor in my opinion.
I was under the impression that the way YubiKeys (and passkeys) work, it's impossible for any third-party to get your YubiKey to trigger to authenticate unless they compromised your computer as...
I was under the impression that the way YubiKeys (and passkeys) work, it's impossible for any third-party to get your YubiKey to trigger to authenticate unless they compromised your computer as well. Like I can't go to Tild3s.net by accident and it prompt anything.
There's some complicated scenarios where they MITM and spoof the network, but then it still requires your computer to be compromised? I'm not well versed here.
That's what I meant by requiring a trusted client application. Your browser is responsible for attaching origin information in order to prevent simple forwarding attacks. But this only works as...
That's what I meant by requiring a trusted client application. Your browser is responsible for attaching origin information in order to prevent simple forwarding attacks. But this only works as long as the browser can be trusted to attach the correct information about the website its interacting with. So yes, you're correct that the application facilitating the communication needs to be compromised, but if that's the case it's sufficient to get you to attempt to log in to some random low security account to gain access to other more important ones. At least that's how I remember the CTAP2 protocol.
Consider the following scenario: You have a low security zoom account and a high security bank account. You get an invitation to an important meeting on zoom.scam. When you click the link it doesn't work in the browser, so you click on the button to download the new fancy zoom client. When you open the client it prompts you to sign into your zoom account. You connect your YubiKey and tap the button. Unfortunately the 'zoom client' connects to attackerserver.evil in the background, which in turn connects to your bank. Your bank sends a challenge to attackerserver.evil which forwards the challenge together with the banks TLS certificate to the 'zoom client'. The malicious client forwards the request together with the banks TLS certificate to the YubiKey. (A legit browser would attach the wrong certificate here, since its talking to attackerserver.evil.) The YubiKey gladly answers the challenge and communicates it back to attackerserver.evil, which forwards it to the bank. Now the attacker has access to your bank account. Had you used your low-security zoom password instead the attacker would now have access to your Zoom account, but your bank account would still be safe.
Or consider a malicious, overcontrolling employer that wants to spy on your private email account. They could access it using the same idea without you ever logging in to your private mail account on your work computer. It always boils down to the YubiKey being incapable of telling you what authentication request you're authorizing. Of course it requires a different setup than simply phishing passwords, but its a reasonable attack vector nonetheless.
Note that your zoom account and your bank account in the scenario above use two completely different sets of keys behind the scenes, but the method authorizing their use is the same from the user's perspective. Also note that completely sandboxing the malicious application to prevent keylogging or similar spying activities, and running the application with fine granular rights management and minimal privileges doesn't help here either, as the app doesn't actually interact with any local resource it shouldn't interact with.
by the time you have malicious software MITM’ing FIDO tokens on your computer, i think it’s safe to assume that all of your session cookies, saved passwords, and keystrokes are being captured as well
by the time you have malicious software MITM’ing FIDO tokens on your computer, i think it’s safe to assume that all of your session cookies, saved passwords, and keystrokes are being captured as well
Thanks, I hadn't considered that scenario and that was interesting to think about. For YubiKey, I guess this does sound like a con versus username+password. For passkeys though, I think there's...
Thanks, I hadn't considered that scenario and that was interesting to think about. For YubiKey, I guess this does sound like a con versus username+password. For passkeys though, I think there's some protection here in that the system prompts can be designed to tell you what you're authenticating for. I just checked with Apple's Passwords passkeys support and it tells me I'm trying to sign into bestbuy.com. Not perfect, but one more bit of protection.
Websites could also combine that with a 2FA code to be entered, so then it would rely on user downloading a compromised client, ignoring any prompts about it being a different domain, and then looking up their 2FA for the wrong domain as well. I've never seen YubiKey+2FA, but no reason it couldn't happen.
Again, I'm a noob here so please let me know if any of that is totally wrong. I have 2 passkeys set up so far to try and they've been a joy to use.
Apart from the uniquely bad advice on using Email-As-Authentication patterns, the things DHH is talking about are just straight up untrue. I am in the position of using a Windows computer and...
Apart from the uniquely bad advice on using Email-As-Authentication patterns, the things DHH is talking about are just straight up untrue. I am in the position of using a Windows computer and iCloud Keychain, a situation DHH postulates is not pleasant or smooth to solve. And yet, when I log onto GitHub with a passkey, my computer first checks for a passkey in Hello, doesn't find one, and presents me with a simple QR code I scan with my phone, which verifies me using the Face ID scanner, and Bob's your uncle. It works flawlessly, every time, even though the truly anaemic bluetooth stack Windows comes with.
In fact, Passkeys would have never been implemented by anyone if that wasn't how it worked. A world in which Passkeys do not fall back to mobile auth methods of yesterday is a world that will never use Passkeys at all. It would be a hassle. And if you think that's the case, I can see why you'd write an article like this.
But it's simply not true. Not only do Passkeys work on every modern device that's reasonably up to date, they're more or less idiot proof, can't be forgotten, are easily created, and handled in a secure way by default. Nobody is storing their Passkeys in the notes field of their own contact card, a horrifying practice that I've seen more than once with classic passwords.
And no, having a phone as a requirement does not disqualify the method of entry. DHH says that everyone has email and everyone understands email - same here. Everyone has a smartphone, everyone knows how to use it, and the people that don't are either nerds that are smart enough to make things harder for themselves or people who willingly resist the changing times, and if that's their choice, they're standing in moving water.
So no. Passwords have problems, Passkeys fix them. And to ram the point home more: Passwords have problems, email-as-permission patterns are so laughably bad I have to seriously question if I ever want to use ONCE or Hey if they insist on using them.
Can you explain this, and what do you consider a "nerd"?
Everyone has a smartphone, everyone knows how to use it, and the people that don't are either nerds that are smart enough to make things harder for themselves
Can you explain this, and what do you consider a "nerd"?
People who dual boot. People who install Adblockers everywhere. People who like to read their emails in a terminal, the list tends towards infinity. I'm all of those, and I'm just saying here that...
People who dual boot. People who install Adblockers everywhere. People who like to read their emails in a terminal, the list tends towards infinity. I'm all of those, and I'm just saying here that the outliers are outliers so rare and specific that we probably won't lose much good will or scope if we decide to disregard those. It's fine if they want to live like that, their life and all, but it's also a personal choice and therefore shouldn't be included in the default scope of "general purpose application for the general public" like Passkeys aims to be.
But I tested things, for my parents as described above. The combination of hardware they have, iOS devices, Mac devices, ChromeOS devices, couldn't be made to be easy or seamless in any way I...
But I tested things, for my parents as described above. The combination of hardware they have, iOS devices, Mac devices, ChromeOS devices, couldn't be made to be easy or seamless in any way I could see, and they're certainly not bloody "nerds" for having mixed equipment.
I can see the necessity and value in moving towards these things, I really can. But single vendor hostage for your keys at the moment, a horrible experience in mixed environments, and wildly differing passkey support from websites, including most often, not supported at all, means I cannot recommend them as an easy way for them to get out of password manager hell. It's just not there.
Fair enough, but that's a fault of the specific implementation, and not the concept, no? As I said, it works beautifully on the pages I've tested it (which, at the time of writing, are Amazon,...
Fair enough, but that's a fault of the specific implementation, and not the concept, no? As I said, it works beautifully on the pages I've tested it (which, at the time of writing, are Amazon, Adobe, Ebay, Github and Google) and is much more convenient than having to keep track of passwords, even with a well-integrated manager. (And as an aside, I'm glad the technology is provided by a single open instance instead of being a general "concept" like passwords, seeing as how many breaches reveal absolutely appalling password hygiene on the part of portals using it.)
I’m wondering what you tried? In my experience, creating one passkey in Chrome’s password manager and another in Apple’s password manager for each website I use seems pretty workable - that covers...
I’m wondering what you tried? In my experience, creating one passkey in Chrome’s password manager and another in Apple’s password manager for each website I use seems pretty workable - that covers every machine I’d want to use to log in, and I’d have to lose both my Google account and Apple ID to be locked out.
However, I only use passkeys for a few websites (for example, GitHub), I use Chrome everywhere with account syncing turned on, and I don’t use Windows. I also still have the other authentication methods I was using before as backup. In some ways, this is fairly simple setup, and that’s an intentional choice.
I think there are two large sets of users who have really complex computing environments - very nontechnical users (who are often disorganized, have a lot of crappy devices and keep losing things) and very technical users, who sometimes do really obscure and non-standard things.
So I think it’s true that passkeys aren’t ready for everyone and vendors have to take that into account, but also that they’re not that hard once you get used to them and have things set up right? Or maybe I’ve been lucky.
This encapsulates my issues, or at least concerns, with passkeys fairly well: Is there any cross-device solution not dependent on big vendor syncing? For context, I’m mostly on Apple devices (and...
This encapsulates my issues, or at least concerns, with passkeys fairly well: Is there any cross-device solution not dependent on big vendor syncing?
For context, I’m mostly on Apple devices (and software) with some Linux usage in between, and currently use Bitwarden for desktop, mobile, CLI, and browser extension use. I haven’t (with admittedly little effort into research) seen any convincing implementation of passkeys covering all of those use cases across all devices and the (all-unix) OS lineup that’s independent enough to survive a de-{Apple, Google, Microsoft}’d device switch down the line. I don’t use Microsoft for much of anything and don’t have a Google account. My only “dependence” on Apple is for the app store on mobile, and to provide the OS’s in general I guess.
Could I now, for example, move away from Bitwarden and import my existing passkeys elsewhere with minimal hassle? I don’t know. With passwords, it’s guaranteed to work: Bitwarden will let me export them just as passkeys, but worst comes to worst, I’d still be able to create and maintain a plain text file and encrypt it.
And yes, of course I realize this is from the perspective of an outlier in terms of technology. For most people who almost never switch brands and/or have accounts with all five big tech companies (and for the cherry on top probably don’t use a password manager currently whatsoever), passkeys will be a massive improvement. I’m not arguing against them being adopted, by all means, please do. But I am concerned about my use case, so please don’t deprecate passwords. I will be happy and quiet as long as passkeys won’t be the only option for authentication. Or only having email as the 2FA. :P
Edit: What happens in the case of “my device drowned after driven over by truck after my house burned down”? What happens if my passkeys hadn’t been synced at all because I’m an average user with my phone as the main device + no backups?
I think using chrome (on Windows, was it? or ChromeOS?) and Safari might be part of it. I don't use either of these and I have an aversion to entrusting my data to big tech giants, having spent...
I think using chrome (on Windows, was it? or ChromeOS?) and Safari might be part of it. I don't use either of these and I have an aversion to entrusting my data to big tech giants, having spent quite a long time divesting myself of everything Google.
So I was primarily looking (for me when testing), at Graphene OS for mobile with Firefox (didn't work), a selection of browsers on Linux (firefox worked, librewolf didn't, Konqueror also did not), and third party managers (keepassxc and bitwarden).
My own requirements were for Graphene, and Linux primarily, with a little helping of Mac OS and iOS.
My parents needed things to work accross iOS, ChromeOS, MacOS (Firefox and Chrome) and Android, and I couldn't find a solution that worked properly on all of those.
Maybe one day, these things will work for folks with diffuse computing environments, but that day is not yet here
Honestly, I'm all for people using hardware FIDO tokens or similar (i.e. passkeys on their phones) as a second factor. I just don't think it's a good idea to use them as the only factor. Why...
Honestly, I'm all for people using hardware FIDO tokens or similar (i.e. passkeys on their phones) as a second factor. I just don't think it's a good idea to use them as the only factor. Why replace passwords and not just supplement them?
I for one use a hardware security token as a second factor wherever possible, but I'm very reluctant to use it to sign in without any password whatsoever.
Authentication via FIDO tokens simply opens up a different class of attack vectors. You exchange the factor knowledge for ownership. Left your YubiKey on your desk somewhere? Anyone who finds it...
Authentication via FIDO tokens simply opens up a different class of attack vectors. You exchange the factor knowledge for ownership.
Left your YubiKey on your desk somewhere? Anyone who finds it may now be able now sign into your accounts, if the serviceprovider doesn't mandate a pin being set on the key. (Turns out FIDO2 can be used without mandatory PIN requirements.)
Have a PIN set on your key? While CTAP2 sets up a new public-private key pair for each service, the PIN to authorize its usage is still the same for every service. Your plugged-in YubiKey is blinking and you tap it out of habit? Well you just athorized an authentication - there's no indicator what exactly you just authorized.
Using passkeys on my phone? Don't want anyone with access to my phone to be able to log into arbitrary accounts of mine I'm not already logged in to.
Sure, with CTAP2 or similar protocols you ensure that the actual authentication is based on a non-bruteforcable, randomly generated public-private key pair. On the upside you hence don't have any issues with bad, user-selected passwords that may be easily bruteforcable. On the downside you still need some non-circumventable way of authorizing the use of your private keys - an attractive attack surfcae. This method may simply be the physical ownership of the device that manages the private keys for you, it may require a button press, or you may even need to enter a PIN code. But in the end this only shifts the type of hurdle an attacker needs to overcome from obtaining a password to obtaining control over a specific device (or the keys therein). And with regards to social engineering it may arguably be easier to get a user to press an application-independent button than to enter an applicatio-specific password.
In the end different authentication factors protect against different types of attackers. Requiring both factors (knowledge and ownership) will always be more secure than requiring one or the other. Suddenly teaching people that passwords are bad, but that that fancy new authentication method is much better, may even be counterproductive, as a false sense of security settles in and new attack vectors get overlooked. People are already used to passwords. If you truly want logins to become more secure, our collective energy should be put into getting people to use passkeys as a >second< factor in addition to passwords, not as a replacement for them.
Another factor is that is the user doesn't understand the system well, that might be a security issue in itself. At work we use a combination of stuff, I get bombarded by keys, tokens, 2FA's, etc....
Another factor is that is the user doesn't understand the system well, that might be a security issue in itself. At work we use a combination of stuff, I get bombarded by keys, tokens, 2FA's, etc. it's just a headache. I end up clicking and copy pasting randomly until something works.
Yeah, I’ve avoided passkeys because none of the vendors that have tried to make me use one can be bothered to clearly explain what they are or how they work. 2FA is bad enough. I got a new phone...
Yeah, I’ve avoided passkeys because none of the vendors that have tried to make me use one can be bothered to clearly explain what they are or how they work.
2FA is bad enough. I got a new phone recently and was locked out of my Google account because I couldn’t confirm my login via the Gmail app on my phone. Every recovery method pointed me back to the Gmail app.
I’ve been using the internet since the mid-1990s, and I’ve never had an account compromised. When I have lost access to an account, it was always because of “security” BS.
The problems he's noting here aren't unique to passkeys. They're the same problem every type 2 authentication token would have. Ie; if you don't have the thing that lets you authenticate with you,...
The problems he's noting here aren't unique to passkeys. They're the same problem every type 2 authentication token would have.
Ie; if you don't have the thing that lets you authenticate with you, you can't authenticate. Thats the whole point of type 2. You have to have the thing to authenticate.
That doesn't mean that other authentication types are better, they all have problems. Passwords can be forgotten easily, and are very easy to manipulate out of someone, and type 3 authentication tokens can't be changed if they're compromised (outside of surgery).
Ultimately the friction here comes down to implientation problems, namely cross compatibility.
Why can't I use keychain to sync my passkeys on my android phone or Windows computer? Why is there no universally adopted passkey syncing service/protocol?
Password managers are good, but we've always known that passwords are a deeply flawed approach, even if randomly generated and stored in a good password manager. They require transmitting unencrypted authentication strings around, either by a user typing it or a pw manager pasting it into a field, both of which can be intercepted. They're human readable and easy for humans to relay to one another, which means they get frequently shared or written down, and are subject to the human tendency of reuse. The vast majority of breaches are caused not by new fancy zero days, they're caused by intercepting passwords, or getting in the middle of a user interactive session to grab session tokens. Passkeys with mutual authentication solve a lot of those problems, but they're very clunky in their current implimentation.
I'd love to see a day where authentication is universally done by the smartphones we already have, whether it's on your work PC or at your house, on your gaming console, your laptop, your desktop, or your ATM, and those passkeys are protected on your device by strong biometric backed encryption.
The issue is actually getting those implimentatons right, and ensuring that these things don't only work in corporate walled gardens.
Because of two things - attestation and spec writers hesitancy to allowing secrets to be exported. Attestation means that a website can require specific vendors of passkeys. A good idea for a...
Why is there no universally adopted passkey syncing service/protocol?
Because of two things - attestation and spec writers hesitancy to allowing secrets to be exported.
Attestation means that a website can require specific vendors of passkeys. A good idea for a corporate IT department supplying centrally managed hardware dongles, but not so good for the general user who might want something to change vendors and isn't organised enough to find and replace all their passkeys.
The second kind of goes in hand with the first, but keepassxc's run ins with the spec writers objecting to their ability to export passwords shows that the spec writers don't want the users to be able to take the secret out in a portable manner, lest they get phished into sending it to a bad guy. They'd rather a P2P protocol for specific trusted vendors which significantly limits new entrants and open source solutions. The attestation mechanism can then be used to lock out those that don't play ball with that vision.
Maybe there’s another way to think about it: what does it mean to copy a passkey? It seems like the best way would be to make a new passkey that unlocks the same door. That is, passkeys never get...
Maybe there’s another way to think about it: what does it mean to copy a passkey?
It seems like the best way would be to make a new passkey that unlocks the same door. That is, passkeys never get copied, but they can be synced by creating new, matching passkeys in another password manager, that unlock the same door.
And then the question is when the new passkeys should be accepted? This is a sensitive operation since you don’t want the bad guys to be able to do it.
I think I’m fine with not letting just anyone do it, just like you don’t want just anyone to start up a new domain registry. It’s enough for there to be a variety of vendors who meet the requirements.
Like whom? The owner of the key? Approved by the likes of that person dumping on KeepassXC, I don't think so. And it's highly likely the big players will wrap it all up amongst themselves. I dunno...
I think I’m fine with not letting just anyone do it
Like whom? The owner of the key?
It’s enough for there to be a variety of vendors who meet the requirements.
Approved by the likes of that person dumping on KeepassXC, I don't think so. And it's highly likely the big players will wrap it all up amongst themselves.
I dunno man. Could have been a good thing but I smell a smash and data grab. Maybe I'm just old and cynical. Could be either. Or both.
One thing that makes it tricky to make software for the masses is that sometimes they have to be protected from themselves. This is why anti-phishing is difficult - you can’t always trust the user...
One thing that makes it tricky to make software for the masses is that sometimes they have to be protected from themselves. This is why anti-phishing is difficult - you can’t always trust the user because they can be fooled into working for the other side.
This is also why we have app stores, etc, instead of letting you download whatever malware you want. Running an app store is a lot of power, though, and can definitely be abused.
So, I’m somewhat sympathetic to the argument that maybe the owner of a key shouldn’t be able to do everything they might want.
I do think there should be escape hatches for more technical users who accept the risks, but we should realize that we can be fooled too, and maybe not use those escape hatches unless we’re being very careful.
I contend that is a false assumption bred by perpetual cultural acceptance of tech ignorance. We generally as a society entrust people to take care of themselves, and usually actively resent when...
they have to be protected from themselves
I contend that is a false assumption bred by perpetual cultural acceptance of tech ignorance.
We generally as a society entrust people to take care of themselves, and usually actively resent when the government acts paternalizing.
"Libraries must ban books so that people don't learn dangerous things"
"Food stamps must have detailed and complicated rules because we can't trust people to use money"
Why do we accept this same attitude on computers?
Perhaps if we had not accepted tech ignorance, computing would have remained as an opt-in technology, not a mandatory part of everyone's lives.
If the users did want to be coddled, that should be an optional choice that they can add on themselves, not a mandatory function of every device.
Do we? I don't know anything about mechanical engineering, so I trust that when I buy a car, the NHTSA has certified that it won't lose control and kill me. Same goes for food and the FDA. I'm not...
We generally as a society entrust people to take care of themselves, and usually actively resent when the government acts paternalizing.
Do we?
I don't know anything about mechanical engineering, so I trust that when I buy a car, the NHTSA has certified that it won't lose control and kill me. Same goes for food and the FDA. I'm not allowed to buy raw milk at the grocery store, and I'm ok with that.
Cybersecurity is very, very complicated. Most technology people don't understand the main threats towards various kinds of credentials. There's no way a normal user has any hope of understanding them.
Your examples, other than raw milk, are largely more in the vein of "product doing what it says on the box at a minimum level of quality." That's not protecting users from themselves, that's...
Your examples, other than raw milk, are largely more in the vein of "product doing what it says on the box at a minimum level of quality." That's not protecting users from themselves, that's providing users the information they need (3rd party certification) in a uniform way to make decisions. Protecting the users from grifters is not the same as protecting the users from themselves.
I do consider bans on raw milk paternalizing. If some idiot wants to buy raw milk to drink, let them. I'd support proper labeling the same way we do cigarettes though. But there are actually some great use cases for buying raw milk: Cheese and Yogurt making. Banning raw milk is little different from banning flour sales. Flour isn't safe to eat uncooked either....that's why even vegan cookie dough is not safe to eat raw. I'd love to be able to buy small bits of raw milk for hobby cheesemaking, but the process to get it is onerous and annoying.
I'm talking the difference between "giving users the tools to protect themselves" and "protect the users from themselves." They may seem one and the same, but the difference comes down to users having the choice instead of a choice being forced upon them.
It's why I'm 100% against perma-locked bootloaders. If a firmware can be flashed, end users should be permitted to flash it via some reasonable mechanism, regardless of how bad of an idea it is. That's the only way you have an out against prematurely bricked hardware.
This is more or less being for kids dying of listeria for the crime of having stupid parents. I realize we're several metaphors deep now and I'm not trying to relate this back to the actual tech...
I do consider bans on raw milk paternalizing. If some idiot wants to buy raw milk to drink, let them.
This is more or less being for kids dying of listeria for the crime of having stupid parents. I realize we're several metaphors deep now and I'm not trying to relate this back to the actual tech discussion. But not banning raw milk does actually kill innocent people who don't actually have a say in the matter.
I understand what you're saying, but also feel that the benefit is almost certainly overblown. Banning the manufacture and distribution of deli meats and cheeses would do far more, but would be...
I understand what you're saying, but also feel that the benefit is almost certainly overblown. Banning the manufacture and distribution of deli meats and cheeses would do far more, but would be met witg fierce resistance. Banning the manufacture of peanut butter would likely also be met with apocalyptic levels of fury, despite saving even more lives of innocents.
You can buy raw milk and unwashed eggs in most of the world, albeit often with package and warning requirements. Even in America retail sales of raw milk are allowed in almost all states.
The parents that kill their kids with raw milk will likely kill their kids with something else if raw milk is banned. Because the issue is that they're a shitty anti-science parent and short of locking them up physics or biology will eventually catch up to them.
Course, I also think heroin should be legalized, so adjust expectations accordingly.
I live in part of the "most of the world" you talk about, and I think equating raw milk to unwashed eggs is extremely disingenuous. Unwashed eggs are just how eggs are outside of the countries...
I live in part of the "most of the world" you talk about, and I think equating raw milk to unwashed eggs is extremely disingenuous. Unwashed eggs are just how eggs are outside of the countries that wash them, and are found in all grocery stores. At least here in Germany, the same is not remotely true of raw milk (and Germany is the birthplace of homeopathy, so the same quacks promoting it as a miracle cure are definitely also a thing here). Some organic stores sell "Vorzugsmilch", but it is extremely tightly regulated by the government. Otherwise, one can buy raw milk directly from farmers at "Milchtankstellen", but they are required to warn you that you must boil it before using. Legally, farmers shouldn't even offer raw milk from their own cows to guests (though they are allowed to drink it themselves). Pretending that tightly-regulated environment of something that is known to be a health hazard is remotely similar to unwashed eggs (or deli meat or peanut butter) is completely disingenuous. The level of danger is not remotely equivalent.
Fwiw, I also think heroin should be legalized. That doesn't mean I think it should be legal for me to make my own and sell it out of my garage. Part of the reason I think drugs like heroin should be legalized is so that the government can regulate them to ensure that they're reaching certain levels of purity and not being laced with stuff. Shit like "regulating food and drugs to make sure they contain what they're supposed to and aren't full of dangerous pathogens" is one of the basic jobs of a state, and it's not paternalizing for the government to actually do their job to prevent people from literally being killed by contaminated products. IMO in the US they're actually falling far short of what they should be doing on that front, even without considering raw milk. Look at how poorly regulated supplements are.
You’re right that we often make the assumption that other people are responsible adults. However, it’s only an assumption and there are lots of exceptions. Most obviously, children, but also...
You’re right that we often make the assumption that other people are responsible adults. However, it’s only an assumption and there are lots of exceptions. Most obviously, children, but also elderly people who aren’t as sharp as they used to be, various people with mental health issues of various kinds, and so on.
People who do technical support have a more realistic idea of what sorts of trouble nontechnical users can get themselves into. Multiple people have posted in this topic about helping elderly relatives and friends. Don’t let libertarian ideals blind you to what people are really like.
Some of these people are officially recognized as needing care, but many others aren’t. These are the people scammers prey on.
I don’t believe every device has to have all safety features. I do think that it should be the default, that the device you do your banking on should be pretty locked down, even for those of us who buy other devices to hack on. (And being able to unlock older devices to hack on is a good thing too.)
keepassxc had issues with the spec writers? Got any links? It's the only bit of software that worked at all for my use cases. Which includes having full personal control of the backup and recovery...
keepassxc had issues with the spec writers? Got any links?
It's the only bit of software that worked at all for my use cases. Which includes having full personal control of the backup and recovery of my own security tokens.
Wow, I'd missed those, thanks. Bit shitty to be threatening open source implenentations with blocking, and bad mouthing them at security conferences, in favour of sending all your keys to Apple,...
Wow, I'd missed those, thanks.
Bit shitty to be threatening open source implenentations with blocking, and bad mouthing them at security conferences, in favour of sending all your keys to Apple, or Google .
All this does is make me less likely to invest any time or effort in passkeys
This is truly terrible advice. Most people use the same or very similar passwords across services, suggesting to rely on email for secondary authentication is like locking a safe in a room, then putting the key to the safe in the same room. Sure you still need to break into the room, but once you've done that you can easily find the key and break into the next thing.
Is it? Maybe I'm biased because we use such a solution in Sweden to sign into literally all government services, banks, insurance, even some third party services, etc. We cannot use a username/password combo, our only option is to sign in using our personal number (equivalent to social security number) and authenticating via the app that is issued via our banks.
If literally our entire nation can do this, including most old people, then I'm sure people can learn to use passkeys efficiently.
Have you tried to use them in a heterogenous environment? I have degoogled android, occasional iOS use, occasional Mac OS use, and heavy Linux desktop use.
Passkeys are an abomination at the moment, I don't care how determined you are to use them efficiently, right now they just suck.
I only have passkeys on my phone and scan QR codes to sign in to other devices, if that's what you're asking.
I will say though that our national passkey solution (called BankID) is MUCH easier to use than third-party passkeys (such as Bitwarden, MS authenticator, etc).
What if you’re using 1password? It shouldn’t be too hard then. Granted, I still don’t see non-technical users really understanding what’s going on.
I tried that, and bitwarden when I was experimenting.
Didn't matter, as soon as I got android, iOS, Linux and Mac in the mix, it always ended up broken in one way or another. Either a browser on linux or mac would work, whilst others wouldn't, or you couldn't create new passkeys on Android if you found you happened to need that, it was all just a mess.
Thanks for sharing your experience. I’ve been on the fence about trying it out to see if it could replace my password manager setup. Reading your comment makes me think that would be a waste of time. There are better ways for me to waste my time.
I’ve had a much smoother experience than @trim.
I have an iPhone, two MacBooks (one old intel, one new apple silicon) and a Windows desktop (was 10, now 11). 1Password syncs the passkey around where I have it installed and integrates seamlessly into mobile Safari and desktop Chrome/Firefox browsers. On my work MacBook, I scan the QR code with my phone and I’m in. Having them in 1Password alongside traditional passwords means I don’t have to think much about whether a particular site uses one or the other.
For some services that I use frequently on company devices, I’ve created another local passkey after logging in once via QR code. Previously I’d have to open up 1Password on my phone and manually type a password since I’m not installing my personal password manager on company hardware.
Are they? I've had to use them on a few platforms so far and have had no real issues. What problems are people running into?
So high impact financial services, infrequently accessed? Seems like a great case for prioritising security over a frictionless login.
I'm not sure e.g. Tildes deserves the same tradeoff. If every site did this and you were doing it ten times a day, it would get more frustrating. Also would you remember to take care to transfer your passkeys for that app you use twice a month when switching phone brand?
BankID is extremely frictionless, it takes 2 seconds to authenticate. It's actually something I use quite often, at least a few times a week.
It’s also much easier to set up than other passkey solutions that I’ve seen too, even if you lost your previous passkey. Our banks give us hardware authenticators that we can use as well to authenticate, this is used when set up the passkey if we don't have one already.
It sounds like you have a government-run system that serves the entire populace in a sensible and standard way. In that environment, led by an entity that truly wants people to be more secure and has no other motive, I agree something like this is sensible. But here in the US, it's going to be a way to further capitalist
constipationmonetization(1), with the security benefit being secondary.1-autocorrupt produced constipation, and for once I think it know what it is doing
BankID is actually operated by a private company owned by several of our largest banks. According to that wikipedia page 94% of swedish smartphone users use BankID. I know some people are not too happy giving a private company that much power. Personally I think that it works pretty great, and I'm not that worried about it. But it surely is centralizing a lot of power and information, which is not all good.
Funnily enough the service is not government run, but it’s co-owned by all major banks and has been adopted by the government for their services as well.
But you’re right, it would likely not work in the US. It is heavily regulated in Sweden.
And does the bank issue you a smartphone which can run the app, and repair/replace it as needed? Do they support the app on less-popular platforms?
Unless they do, which I seriously doubt, that doesn't sound anything like a strict improvement over username/password to me.
In what way do you think that it's not an improvement? I'm pretty sure it's more secure, and for me personally, and most people, it's also more convenient. It's also not the only way you can login or sign your transfers (I only checked my own bank, but I'm pretty sure others offers alternatives as well), so you don't need to get a smartphone if you don't want to.
No but they offer free hardware authenticators as well.
The BankID software works on iOS/Android but also Windows/macOS. It’s a universal personal authentication app, so each bank doesn’t have their own proprietary.
While an email login might be compromised alongside a password for a login, it's also generally much more secure than the most common alternative: SMS and/or automated phone call. And wiser providers have already separated usernames from emails and phones (ironically like the good old days when having an 8-character username was far better than an email due to storage constraints).
This is a great video essay and demonstration which highlights just how easy it is to hijack and intercept both.
The biggest problem with requiring an app is mandating that everyone has an active smartphone, which also means enforcing the Android/IOS duopoly. Unless your banks are also required to support any arbitrary operating system or an alternate method. While that might not be a big problem in countries with good social safety nets, a lost or broken phone can make the difference between being able to afford a bill or not that month.
They do. Most banks offer some sort of hardware authenticator as well. But you can also install the BankID software on a computer, but then you can only authenticate on that specific computer (similar to how Windows Hello login works on Microsoft sites).
Incidentally the way Microsoft handles their accounts being deeply engrained in the OS makes it a massive pain in the butt to install Minecraft on my kid's account unless I want to set them up an entire new OS profile.
Off-topic, but might be of use: Have you tried using an alternate/unofficial game launcher like Prism Launcher?
On Linux, for Java, it's fantastic. It's what I use on the Steam Deck and my kid's laptop.
My kid needed a Bedrock install to join a friend's game. I had the audacity to try to install the official launcher under my Windows account with their account, and now the accounts are in a horrifically intermingled mess on my computer, the best resolution to which I could find online was 'delete child account and family group, then create new child account and buy a new copy of Minecraft.' Oh and I probably need to format the machine to un-fuck the OS profile as well.
So instead we told said friend to join our Java server which has Geyser, solving the problem.
Was just catching up on darknet diaries podcast about security this morning and was on one where at one point the podcaster switched to ai text to speech mimicking his voice and I did not catch it AT ALL that he had swapped. The world is going to need a strong authentication method to be commonly used everywhere because our voice and video is no longer going to be proof enough of who we are. The only way I can see it is if we have a strong encrypted token of some sort to prove our identity, that must be one of the checks for financial related accounts we hold, so people are going to need to learn it fast imho.
My parents telephone banking relies on "my voice is my password".
Terrifying.
I had thought that passkeys would be the saviour of my elderly parents password woes. Even with a vault that's the easiest to work with (BitWarden), they're forever not being able to use it and going through password reset flows that they then don't do correctly, and we end up where the old password doesn't work, and the new one doesn't either because they didn't do the reset correctly.
So I started looking at passkeys for a couple of my own accounts, and there's no way they'd be able to cope with this. It'd be far more complex and confusing for them, and that's even before we get to the problem of not everything supporting them, and (at the time -- there are partial foss solutions to this now) extreme vendor lock in , but they have a multi OS environment, Mac, Android, ChromeOS and iOS.
So back to managing BitWarden it is.
For what it's worth, I use KeepassXC with Firefox as my Passkey provider for the couple of accounts I enabled it for. This allows me to use my passkey login through my Keepass vault, on both Linux and Mac OS, though not Android sadly. Still, the fact that it's in my vault, under my control, and works on my desktops and laptop machines, is good enough. I expect it'd work fine on Windows too.
Passkeys are not ready for the hoi polloi yet. Or, perhaps anyone.
For elderly users, the only solution I found that actually works well is to have them write down the passwords in a paper notebook.
yeah we did that. One day the notebook went missing :( we think they threw it out.
And also, hard to tell which ones were crossed out. It was almost good, right up until it wasn't.
I'd far rather guard against internet threats than evil maids, if I could only help them guard against one or the other.
We're just about squeaking by with bitwarden, it helps that I also have a Macbook so I can usually fix things remotely over screen sharing when they manage to break a login, as I don't live especially near by.
I work with many elderly clients, who all have the same password problems. We keep a single-page password shortlist in a Word document, and print copies so that there is one wherever they may need it. One in the office, one on the coffee table next to where they use their ipads, stuff like that.
Even so, they still occasionally find themselves resetting, scribbling, not crossing out, getting confused. Once every couple of months, I'll swing by, unceremoniously shred the marked up, confusing ones, reset what needs to be reset, and print new copies, with the latest date clearly written across the top. I do not try to play the 'which one of these scribbles is correct' game. We just reset properly and move on. If they come across an older version that I missed, they know to just toss it and reprint.
This has proven to be the most tenable, least-frustrating method so far. It's not perfect, because no system is, but I've been doing elder care for family and close friends for more than 15 years, and work in the IT field, so I've had a lot of time to try different things.
It worked well for me too, until a tipping point about a year ago.
Part of the problem with bitwarden seems to be that, on the computer, the browser extension keeps unhelpfully signing itself out from time to time, despite my trying to set options so that it doesn't do that.
If it does sign out of the extension, that often begins the failure prone email reset chain of doom.
It's a genuinely hard problem, isn't it.
Some of my older clients are also now dealing with various degrees of cognitive impairment, including Alzheimer's. I've switched them from computers/laptops to ipads when they can no longer use mice and keyboards, although they are still not a panacea.
The number of scam apps with predatory pricing (ie, 'Memory Cleaner' cache clearer, for $79/week subscription!) is crazy, and shame on Apple for being complicit. If you want a 'fun' challenge, try and find a coloring book or jigsaw puzzle app that is genuinely ad-free, paid or not. 99% of them are targeting older adults, and every single one of literal dozens that I've tried has ultimately served an ad like I describe.
Yes! I’ve been helping out my elderly neighbors and they are using that. At first it seemed sketchy, but then I realized it is by far the most secure solution they could’ve picked. They are using unique passwords AND it’s not on any of their digital devices. That’s pretty good security in an age where the biggest threat is coming from online criminals.
I agree that passkeys have problems in terms of usability, but from a technical standpoint they’re a lot more secure than passwords. There are other solutions though, like Bitwarden, that lets you store and use your passkeys on any device.
I also recently saw that the FIDO alliance are making a standard that aims to make it easy for passkeys to be moved between platforms. FIDO Alliance Publishes New Specifications to Promote User Choice and Enhanced UX for Passkeys
Hmm, I might be being cynical but that FIDO proposal sounds like a Microsoft, Apple, Google thing where you might be able to transfer between those. Hope it ends up not just including the tech giants, I don't want them to have my credentials /at all/
These discussions are exhausting. So, in the spirit of finding myself in a hole with a shovel and starting to dig, here's my contribution.
There are obvious tradeoffs between both approaches. Neither is categorically superior nor inferior. So, here's a table of the tradeoffs I see. If you have an authentication use case, pick the applicable rows in the table to see why you should vigorously reject one approach or another. ("No" is the "good" answer in each row.)
This has basically always been my worry with all of this. Yes you're assuming proper backup hygiene, but god do I think that's extremely hard to actually get anyone to do correctly.
According to your chart, the only advantage that a transferable token has over a password manager is that it can't be stolen by a third party and re-used. If you're talking 'directly talking to site that was stolen from', that's true, but provided the user follows through on not-reusing-passwords, the impact is minimal (and almost all sites where significant danger would occur are much less important....this isn't 1999 after all and banks/government institutions mostly have their act together).
And even then, I'd contend that if you're using a password manager, that reuse is much less of a problem especially if hardware or transferable tokens are used in combination for 2FA.
The biggest flaw in these discussions is that people feel that switching to passkeys obviate the need for 2FA. Using passwords with a password manager is still superior as a first-factor, especially given the platform-lock. Using passkeys, 2nd verified-device, and hardware tokens as a 2FA where you'll get locked out, but usually have a recovery process, are much less dangerous in that vein.
I think with “I’m screwed if I lose my phone/hardware token” that assumes you only have one. Generally speaking, for every door, you should have two independent keys so you have a backup, and that concept is somewhat independent of technology - you can mix and match.
This might also make being platform-locked a non-issue, provided that those two independent keys are on separate platforms.
Are you sure about that? I would argue that getting people to tap a blinking YubiKey is easier than getting them to enter an application specific password. I do realize that CTAP2 allows for access to a specific private key to be tied to some origin information (e.g. a TLS certificate), but that requires a trusted client application (e.g. Browser) to accurately provide such information to the hardware token. The issue here is, that the YubiKey just blinks. It doesn't tell you what it's authorizing, it just tells you that some operation needs to be authorized by tapping it. Wether that operation is an authentication request for the service you think you're interacting with, an authentication request for some other site, an enrollment request, or some other thing entirely - you don't know from the blinking alone.
Well, true. All you could do with the keys stolen from the service side is emulate the service and get signed challenges from a hardware token you're actively interacting with. (Although the service side is arguably the second party, so I'm not quite sure what you mean by third party with regards to password stealing. Stealing from someone that's already stolen it? An authentication service that gives a third party access to your password hashes in a legit scenario is kinda problematic by design.)
What's missing from your table is 'Can be stolen from first party'. It's much easier to steal your hardware token, than it is to steal your passwords, if you have physical access. And setting a PIN for FIDO2 operations is actually optional and up to the service provider to require. I wouldn't want anyone who finds my YubiKey on my desk to be able to login to many of my accounts without any additional knowledge. Hence your hardware token is a great second factor, but should not be your only factor in my opinion.
I was under the impression that the way YubiKeys (and passkeys) work, it's impossible for any third-party to get your YubiKey to trigger to authenticate unless they compromised your computer as well. Like I can't go to Tild3s.net by accident and it prompt anything.
There's some complicated scenarios where they MITM and spoof the network, but then it still requires your computer to be compromised? I'm not well versed here.
EDIT: some explanation from redditors
That's what I meant by requiring a trusted client application. Your browser is responsible for attaching origin information in order to prevent simple forwarding attacks. But this only works as long as the browser can be trusted to attach the correct information about the website its interacting with. So yes, you're correct that the application facilitating the communication needs to be compromised, but if that's the case it's sufficient to get you to attempt to log in to some random low security account to gain access to other more important ones. At least that's how I remember the CTAP2 protocol.
Consider the following scenario: You have a low security zoom account and a high security bank account. You get an invitation to an important meeting on zoom.scam. When you click the link it doesn't work in the browser, so you click on the button to download the new fancy zoom client. When you open the client it prompts you to sign into your zoom account. You connect your YubiKey and tap the button. Unfortunately the 'zoom client' connects to attackerserver.evil in the background, which in turn connects to your bank. Your bank sends a challenge to attackerserver.evil which forwards the challenge together with the banks TLS certificate to the 'zoom client'. The malicious client forwards the request together with the banks TLS certificate to the YubiKey. (A legit browser would attach the wrong certificate here, since its talking to attackerserver.evil.) The YubiKey gladly answers the challenge and communicates it back to attackerserver.evil, which forwards it to the bank. Now the attacker has access to your bank account. Had you used your low-security zoom password instead the attacker would now have access to your Zoom account, but your bank account would still be safe.
Or consider a malicious, overcontrolling employer that wants to spy on your private email account. They could access it using the same idea without you ever logging in to your private mail account on your work computer. It always boils down to the YubiKey being incapable of telling you what authentication request you're authorizing. Of course it requires a different setup than simply phishing passwords, but its a reasonable attack vector nonetheless.
Note that your zoom account and your bank account in the scenario above use two completely different sets of keys behind the scenes, but the method authorizing their use is the same from the user's perspective. Also note that completely sandboxing the malicious application to prevent keylogging or similar spying activities, and running the application with fine granular rights management and minimal privileges doesn't help here either, as the app doesn't actually interact with any local resource it shouldn't interact with.
by the time you have malicious software MITM’ing FIDO tokens on your computer, i think it’s safe to assume that all of your session cookies, saved passwords, and keystrokes are being captured as well
Thanks, I hadn't considered that scenario and that was interesting to think about. For YubiKey, I guess this does sound like a con versus username+password. For passkeys though, I think there's some protection here in that the system prompts can be designed to tell you what you're authenticating for. I just checked with Apple's Passwords passkeys support and it tells me I'm trying to sign into bestbuy.com. Not perfect, but one more bit of protection.
Websites could also combine that with a 2FA code to be entered, so then it would rely on user downloading a compromised client, ignoring any prompts about it being a different domain, and then looking up their 2FA for the wrong domain as well. I've never seen YubiKey+2FA, but no reason it couldn't happen.
Again, I'm a noob here so please let me know if any of that is totally wrong. I have 2 passkeys set up so far to try and they've been a joy to use.
Apart from the uniquely bad advice on using Email-As-Authentication patterns, the things DHH is talking about are just straight up untrue. I am in the position of using a Windows computer and iCloud Keychain, a situation DHH postulates is not pleasant or smooth to solve. And yet, when I log onto GitHub with a passkey, my computer first checks for a passkey in Hello, doesn't find one, and presents me with a simple QR code I scan with my phone, which verifies me using the Face ID scanner, and Bob's your uncle. It works flawlessly, every time, even though the truly anaemic bluetooth stack Windows comes with.
In fact, Passkeys would have never been implemented by anyone if that wasn't how it worked. A world in which Passkeys do not fall back to mobile auth methods of yesterday is a world that will never use Passkeys at all. It would be a hassle. And if you think that's the case, I can see why you'd write an article like this.
But it's simply not true. Not only do Passkeys work on every modern device that's reasonably up to date, they're more or less idiot proof, can't be forgotten, are easily created, and handled in a secure way by default. Nobody is storing their Passkeys in the notes field of their own contact card, a horrifying practice that I've seen more than once with classic passwords.
And no, having a phone as a requirement does not disqualify the method of entry. DHH says that everyone has email and everyone understands email - same here. Everyone has a smartphone, everyone knows how to use it, and the people that don't are either nerds that are smart enough to make things harder for themselves or people who willingly resist the changing times, and if that's their choice, they're standing in moving water.
So no. Passwords have problems, Passkeys fix them. And to ram the point home more: Passwords have problems, email-as-permission patterns are so laughably bad I have to seriously question if I ever want to use ONCE or Hey if they insist on using them.
Can you explain this, and what do you consider a "nerd"?
People who dual boot. People who install Adblockers everywhere. People who like to read their emails in a terminal, the list tends towards infinity. I'm all of those, and I'm just saying here that the outliers are outliers so rare and specific that we probably won't lose much good will or scope if we decide to disregard those. It's fine if they want to live like that, their life and all, but it's also a personal choice and therefore shouldn't be included in the default scope of "general purpose application for the general public" like Passkeys aims to be.
But I tested things, for my parents as described above. The combination of hardware they have, iOS devices, Mac devices, ChromeOS devices, couldn't be made to be easy or seamless in any way I could see, and they're certainly not bloody "nerds" for having mixed equipment.
I can see the necessity and value in moving towards these things, I really can. But single vendor hostage for your keys at the moment, a horrible experience in mixed environments, and wildly differing passkey support from websites, including most often, not supported at all, means I cannot recommend them as an easy way for them to get out of password manager hell. It's just not there.
Fair enough, but that's a fault of the specific implementation, and not the concept, no? As I said, it works beautifully on the pages I've tested it (which, at the time of writing, are Amazon, Adobe, Ebay, Github and Google) and is much more convenient than having to keep track of passwords, even with a well-integrated manager. (And as an aside, I'm glad the technology is provided by a single open instance instead of being a general "concept" like passwords, seeing as how many breaches reveal absolutely appalling password hygiene on the part of portals using it.)
I’m wondering what you tried? In my experience, creating one passkey in Chrome’s password manager and another in Apple’s password manager for each website I use seems pretty workable - that covers every machine I’d want to use to log in, and I’d have to lose both my Google account and Apple ID to be locked out.
However, I only use passkeys for a few websites (for example, GitHub), I use Chrome everywhere with account syncing turned on, and I don’t use Windows. I also still have the other authentication methods I was using before as backup. In some ways, this is fairly simple setup, and that’s an intentional choice.
I think there are two large sets of users who have really complex computing environments - very nontechnical users (who are often disorganized, have a lot of crappy devices and keep losing things) and very technical users, who sometimes do really obscure and non-standard things.
So I think it’s true that passkeys aren’t ready for everyone and vendors have to take that into account, but also that they’re not that hard once you get used to them and have things set up right? Or maybe I’ve been lucky.
This encapsulates my issues, or at least concerns, with passkeys fairly well: Is there any cross-device solution not dependent on big vendor syncing?
For context, I’m mostly on Apple devices (and software) with some Linux usage in between, and currently use Bitwarden for desktop, mobile, CLI, and browser extension use. I haven’t (with admittedly little effort into research) seen any convincing implementation of passkeys covering all of those use cases across all devices and the (all-unix) OS lineup that’s independent enough to survive a de-{Apple, Google, Microsoft}’d device switch down the line. I don’t use Microsoft for much of anything and don’t have a Google account. My only “dependence” on Apple is for the app store on mobile, and to provide the OS’s in general I guess.
Could I now, for example, move away from Bitwarden and import my existing passkeys elsewhere with minimal hassle? I don’t know. With passwords, it’s guaranteed to work: Bitwarden will let me export them just as passkeys, but worst comes to worst, I’d still be able to create and maintain a plain text file and encrypt it.
And yes, of course I realize this is from the perspective of an outlier in terms of technology. For most people who almost never switch brands and/or have accounts with all five big tech companies (and for the cherry on top probably don’t use a password manager currently whatsoever), passkeys will be a massive improvement. I’m not arguing against them being adopted, by all means, please do. But I am concerned about my use case, so please don’t deprecate passwords. I will be happy and quiet as long as passkeys won’t be the only option for authentication. Or only having email as the 2FA. :P
Edit: What happens in the case of “my device drowned after driven over by truck after my house burned down”? What happens if my passkeys hadn’t been synced at all because I’m an average user with my phone as the main device + no backups?
I think using chrome (on Windows, was it? or ChromeOS?) and Safari might be part of it. I don't use either of these and I have an aversion to entrusting my data to big tech giants, having spent quite a long time divesting myself of everything Google.
So I was primarily looking (for me when testing), at Graphene OS for mobile with Firefox (didn't work), a selection of browsers on Linux (firefox worked, librewolf didn't, Konqueror also did not), and third party managers (keepassxc and bitwarden).
My own requirements were for Graphene, and Linux primarily, with a little helping of Mac OS and iOS.
My parents needed things to work accross iOS, ChromeOS, MacOS (Firefox and Chrome) and Android, and I couldn't find a solution that worked properly on all of those.
Maybe one day, these things will work for folks with diffuse computing environments, but that day is not yet here
Honestly, I'm all for people using hardware FIDO tokens or similar (i.e. passkeys on their phones) as a second factor. I just don't think it's a good idea to use them as the only factor. Why replace passwords and not just supplement them?
I for one use a hardware security token as a second factor wherever possible, but I'm very reluctant to use it to sign in without any password whatsoever.
Why do you think it's not good to use them as the only factor?
Authentication via FIDO tokens simply opens up a different class of attack vectors. You exchange the factor knowledge for ownership.
Left your YubiKey on your desk somewhere? Anyone who finds it may now be able now sign into your accounts, if the serviceprovider doesn't mandate a pin being set on the key. (Turns out FIDO2 can be used without mandatory PIN requirements.)
Have a PIN set on your key? While CTAP2 sets up a new public-private key pair for each service, the PIN to authorize its usage is still the same for every service. Your plugged-in YubiKey is blinking and you tap it out of habit? Well you just athorized an authentication - there's no indicator what exactly you just authorized.
Using passkeys on my phone? Don't want anyone with access to my phone to be able to log into arbitrary accounts of mine I'm not already logged in to.
Sure, with CTAP2 or similar protocols you ensure that the actual authentication is based on a non-bruteforcable, randomly generated public-private key pair. On the upside you hence don't have any issues with bad, user-selected passwords that may be easily bruteforcable. On the downside you still need some non-circumventable way of authorizing the use of your private keys - an attractive attack surfcae. This method may simply be the physical ownership of the device that manages the private keys for you, it may require a button press, or you may even need to enter a PIN code. But in the end this only shifts the type of hurdle an attacker needs to overcome from obtaining a password to obtaining control over a specific device (or the keys therein). And with regards to social engineering it may arguably be easier to get a user to press an application-independent button than to enter an applicatio-specific password.
In the end different authentication factors protect against different types of attackers. Requiring both factors (knowledge and ownership) will always be more secure than requiring one or the other. Suddenly teaching people that passwords are bad, but that that fancy new authentication method is much better, may even be counterproductive, as a false sense of security settles in and new attack vectors get overlooked. People are already used to passwords. If you truly want logins to become more secure, our collective energy should be put into getting people to use passkeys as a >second< factor in addition to passwords, not as a replacement for them.
Another factor is that is the user doesn't understand the system well, that might be a security issue in itself. At work we use a combination of stuff, I get bombarded by keys, tokens, 2FA's, etc. it's just a headache. I end up clicking and copy pasting randomly until something works.
Yeah, I’ve avoided passkeys because none of the vendors that have tried to make me use one can be bothered to clearly explain what they are or how they work.
2FA is bad enough. I got a new phone recently and was locked out of my Google account because I couldn’t confirm my login via the Gmail app on my phone. Every recovery method pointed me back to the Gmail app.
I’ve been using the internet since the mid-1990s, and I’ve never had an account compromised. When I have lost access to an account, it was always because of “security” BS.
The problems he's noting here aren't unique to passkeys. They're the same problem every type 2 authentication token would have.
Ie; if you don't have the thing that lets you authenticate with you, you can't authenticate. Thats the whole point of type 2. You have to have the thing to authenticate.
That doesn't mean that other authentication types are better, they all have problems. Passwords can be forgotten easily, and are very easy to manipulate out of someone, and type 3 authentication tokens can't be changed if they're compromised (outside of surgery).
Ultimately the friction here comes down to implientation problems, namely cross compatibility.
Why can't I use keychain to sync my passkeys on my android phone or Windows computer? Why is there no universally adopted passkey syncing service/protocol?
Password managers are good, but we've always known that passwords are a deeply flawed approach, even if randomly generated and stored in a good password manager. They require transmitting unencrypted authentication strings around, either by a user typing it or a pw manager pasting it into a field, both of which can be intercepted. They're human readable and easy for humans to relay to one another, which means they get frequently shared or written down, and are subject to the human tendency of reuse. The vast majority of breaches are caused not by new fancy zero days, they're caused by intercepting passwords, or getting in the middle of a user interactive session to grab session tokens. Passkeys with mutual authentication solve a lot of those problems, but they're very clunky in their current implimentation.
I'd love to see a day where authentication is universally done by the smartphones we already have, whether it's on your work PC or at your house, on your gaming console, your laptop, your desktop, or your ATM, and those passkeys are protected on your device by strong biometric backed encryption.
The issue is actually getting those implimentatons right, and ensuring that these things don't only work in corporate walled gardens.
Because of two things - attestation and spec writers hesitancy to allowing secrets to be exported.
Attestation means that a website can require specific vendors of passkeys. A good idea for a corporate IT department supplying centrally managed hardware dongles, but not so good for the general user who might want something to change vendors and isn't organised enough to find and replace all their passkeys.
The second kind of goes in hand with the first, but keepassxc's run ins with the spec writers objecting to their ability to export passwords shows that the spec writers don't want the users to be able to take the secret out in a portable manner, lest they get phished into sending it to a bad guy. They'd rather a P2P protocol for specific trusted vendors which significantly limits new entrants and open source solutions. The attestation mechanism can then be used to lock out those that don't play ball with that vision.
Maybe there’s another way to think about it: what does it mean to copy a passkey?
It seems like the best way would be to make a new passkey that unlocks the same door. That is, passkeys never get copied, but they can be synced by creating new, matching passkeys in another password manager, that unlock the same door.
And then the question is when the new passkeys should be accepted? This is a sensitive operation since you don’t want the bad guys to be able to do it.
I think I’m fine with not letting just anyone do it, just like you don’t want just anyone to start up a new domain registry. It’s enough for there to be a variety of vendors who meet the requirements.
Like whom? The owner of the key?
Approved by the likes of that person dumping on KeepassXC, I don't think so. And it's highly likely the big players will wrap it all up amongst themselves.
I dunno man. Could have been a good thing but I smell a smash and data grab. Maybe I'm just old and cynical. Could be either. Or both.
One thing that makes it tricky to make software for the masses is that sometimes they have to be protected from themselves. This is why anti-phishing is difficult - you can’t always trust the user because they can be fooled into working for the other side.
This is also why we have app stores, etc, instead of letting you download whatever malware you want. Running an app store is a lot of power, though, and can definitely be abused.
So, I’m somewhat sympathetic to the argument that maybe the owner of a key shouldn’t be able to do everything they might want.
I do think there should be escape hatches for more technical users who accept the risks, but we should realize that we can be fooled too, and maybe not use those escape hatches unless we’re being very careful.
I contend that is a false assumption bred by perpetual cultural acceptance of tech ignorance.
We generally as a society entrust people to take care of themselves, and usually actively resent when the government acts paternalizing.
"Libraries must ban books so that people don't learn dangerous things"
"Food stamps must have detailed and complicated rules because we can't trust people to use money"
Why do we accept this same attitude on computers?
Perhaps if we had not accepted tech ignorance, computing would have remained as an opt-in technology, not a mandatory part of everyone's lives.
If the users did want to be coddled, that should be an optional choice that they can add on themselves, not a mandatory function of every device.
Do we?
I don't know anything about mechanical engineering, so I trust that when I buy a car, the NHTSA has certified that it won't lose control and kill me. Same goes for food and the FDA. I'm not allowed to buy raw milk at the grocery store, and I'm ok with that.
Cybersecurity is very, very complicated. Most technology people don't understand the main threats towards various kinds of credentials. There's no way a normal user has any hope of understanding them.
Your examples, other than raw milk, are largely more in the vein of "product doing what it says on the box at a minimum level of quality." That's not protecting users from themselves, that's providing users the information they need (3rd party certification) in a uniform way to make decisions. Protecting the users from grifters is not the same as protecting the users from themselves.
I do consider bans on raw milk paternalizing. If some idiot wants to buy raw milk to drink, let them. I'd support proper labeling the same way we do cigarettes though. But there are actually some great use cases for buying raw milk: Cheese and Yogurt making. Banning raw milk is little different from banning flour sales. Flour isn't safe to eat uncooked either....that's why even vegan cookie dough is not safe to eat raw. I'd love to be able to buy small bits of raw milk for hobby cheesemaking, but the process to get it is onerous and annoying.
I'm talking the difference between "giving users the tools to protect themselves" and "protect the users from themselves." They may seem one and the same, but the difference comes down to users having the choice instead of a choice being forced upon them.
It's why I'm 100% against perma-locked bootloaders. If a firmware can be flashed, end users should be permitted to flash it via some reasonable mechanism, regardless of how bad of an idea it is. That's the only way you have an out against prematurely bricked hardware.
This is more or less being for kids dying of listeria for the crime of having stupid parents. I realize we're several metaphors deep now and I'm not trying to relate this back to the actual tech discussion. But not banning raw milk does actually kill innocent people who don't actually have a say in the matter.
I understand what you're saying, but also feel that the benefit is almost certainly overblown. Banning the manufacture and distribution of deli meats and cheeses would do far more, but would be met witg fierce resistance. Banning the manufacture of peanut butter would likely also be met with apocalyptic levels of fury, despite saving even more lives of innocents.
You can buy raw milk and unwashed eggs in most of the world, albeit often with package and warning requirements. Even in America retail sales of raw milk are allowed in almost all states.
The parents that kill their kids with raw milk will likely kill their kids with something else if raw milk is banned. Because the issue is that they're a shitty anti-science parent and short of locking them up physics or biology will eventually catch up to them.
Course, I also think heroin should be legalized, so adjust expectations accordingly.
I live in part of the "most of the world" you talk about, and I think equating raw milk to unwashed eggs is extremely disingenuous. Unwashed eggs are just how eggs are outside of the countries that wash them, and are found in all grocery stores. At least here in Germany, the same is not remotely true of raw milk (and Germany is the birthplace of homeopathy, so the same quacks promoting it as a miracle cure are definitely also a thing here). Some organic stores sell "Vorzugsmilch", but it is extremely tightly regulated by the government. Otherwise, one can buy raw milk directly from farmers at "Milchtankstellen", but they are required to warn you that you must boil it before using. Legally, farmers shouldn't even offer raw milk from their own cows to guests (though they are allowed to drink it themselves). Pretending that tightly-regulated environment of something that is known to be a health hazard is remotely similar to unwashed eggs (or deli meat or peanut butter) is completely disingenuous. The level of danger is not remotely equivalent.
Fwiw, I also think heroin should be legalized. That doesn't mean I think it should be legal for me to make my own and sell it out of my garage. Part of the reason I think drugs like heroin should be legalized is so that the government can regulate them to ensure that they're reaching certain levels of purity and not being laced with stuff. Shit like "regulating food and drugs to make sure they contain what they're supposed to and aren't full of dangerous pathogens" is one of the basic jobs of a state, and it's not paternalizing for the government to actually do their job to prevent people from literally being killed by contaminated products. IMO in the US they're actually falling far short of what they should be doing on that front, even without considering raw milk. Look at how poorly regulated supplements are.
You’re right that we often make the assumption that other people are responsible adults. However, it’s only an assumption and there are lots of exceptions. Most obviously, children, but also elderly people who aren’t as sharp as they used to be, various people with mental health issues of various kinds, and so on.
People who do technical support have a more realistic idea of what sorts of trouble nontechnical users can get themselves into. Multiple people have posted in this topic about helping elderly relatives and friends. Don’t let libertarian ideals blind you to what people are really like.
Some of these people are officially recognized as needing care, but many others aren’t. These are the people scammers prey on.
I don’t believe every device has to have all safety features. I do think that it should be the default, that the device you do your banking on should be pretty locked down, even for those of us who buy other devices to hack on. (And being able to unlock older devices to hack on is a good thing too.)
keepassxc had issues with the spec writers? Got any links?
It's the only bit of software that worked at all for my use cases. Which includes having full personal control of the backup and recovery of my own security tokens.
Wow, I'd missed those, thanks.
Bit shitty to be threatening open source implenentations with blocking, and bad mouthing them at security conferences, in favour of sending all your keys to Apple, or Google .
All this does is make me less likely to invest any time or effort in passkeys