Passkeys do marginally improve security against MITM and phishing attacks, but they are primarily for protecting the lowest common denominator from themselves: people who re-use passwords and/or don't use a password manager.
If you use multiple devices throughout the day, registering passkeys in all of these systems becomes a big headache with O(m*n) complexity, so putting the passkeys in a password manager is the only realistic solution. But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for. I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
> how do I log in on a device that I don't own?
This is solved by passkey-implementing software and devices (with Bluetooth) allowing you to log in with a QR code (Webauthn via CTAP hybrid transport). iOS and Android support this, and it’s generally not a locked-down thing if other devices wanted to do it too.
The only use case left is in “how do I login if all my devices are stolen/fall into a body of water” in which there really isn’t an answer beyond “get (a|your) device back, sign back into your password manager, use that to get back into critical accounts”.
The website should display a qr code you can scan with your phone that allows you to then login, unfortunately a lot of sites don't implement this, and some don't implement backup codes. This isn't the fault of passkeys per se, but of poor implementations.
Steam does this. If I want to login, it shows a barcode I can scan with the app and it logs me in without needing to enter my login information. Phone needs internet access, doesn't need to be on the same network as the device I'm logging in on.
If you're not happy connecting your phone to the network, then how likely is it that you would you be willing to enter your login details on a machine you don't control?
The poorest country I'm familiar with is Zambia, where about 90% of the population have a mobile subscription.
The number of people sharing GP's concerns for reasons of poverty rather than because of their personal security posture will be vanishingly small.
They still exist, though. And in my experience people in vulnerable positions have somewhere between zero and one phones at any given time, without necessarily any good continuity between them.
What if you just can't have internet on your phone? Like if the computer is connected via Ethernet and there's no wifi network you can connect to? What if you're abroad and have no roaming? And the ultimate question about a person that the modern world can barely conceptualize - what if you have a dumbphone? Or what if your smartphone is lost or stolen or dead and you need to access some account? That last one has happened to me, and I sure am glad I know the key passwords that I need for survival.
These may seem like nitpicks, but there's probably a thousand rare scenarios like these that exist. You inevitably have to consider them when you're moving from punching in letters and numbers that you remember in the normal, low-tech way to a complex networked two-device workflow.
If my phone is lost or damaged, I would buy a new, cheap Android phone and sync my passkeys to it. But I am curious why one would need to login to a website in order to survive? If one did have say a severe medical condition that somehow required a website in order to manage, I guess I would concede that maybe passkeys aren't the best way to secure such a life-sustaining website.
> But I am curious why one would need to login to a website in order to survive?
They use bank like Ally or Discover with no physical branches.
They use a mortgage provider like Rocket mortgage with no physical branches.
They use a medication delivery service with no physical customer facing pharmacies.
They have an employer that only facilitates reimbursement for expenses via online tools.
etc...
I guess "survive" has a sliding scale, but if I lost access to critical accounts... my life is going to FUCKING SUCK in a non-trivial and very impactful way almost immediately, on many fronts.
And if your answer to that problem is "well, just call them"... then we're right back to the point the article is making: "An account’s security is still dictated by the weakest recovery method"
Passkeys aren't a meaningful improvement in security - assuming you do actually have decent password hygiene like a password manager.
If your phone is lost, how are you going to sync your passkeys to your new cheap android? In a passkey-only future, you cannot login to your Gmail account without your passkey, which is only on your phone, which you've now just lost.
What am I missing? Either we retain passwords as backup for a lost or stolen device - in which case, all the security concerns are still there - or we only use passkeys, in which case we've added a clear nonrecoverable point of failure in the system.
What confuses me is that for a long while we told people to not write their passwords on a sticky note, to not write them in plain text somewhere.
Then we introduce all these "security" mechanisms that make it literally impossible to recover an account without backup codes.
Where do you store the backup codes? The average person, if they store it at all, will store it on a plain text file or in a sticky note.
Except that this creates a much more brittle system. Systems are safe when they are routinely tested/used. If you routinely have to enter your password, you are aware you need it. If you don't need your password, and you never have to enter your backup codes, you won't feel the importance of them until you actually need them.
It's the whole "I have backups" vs. "the backups actually work" problem except it's pushed onto the users who have zero technical knowledge.
FWIW my break-the-glass actual use of backup codes is for access to my password manager.
Everything else which has ever given me a backup code... gets stored in a secure note in my password manager.
It is just another knowledge-based factor. It is one that they are reasonably sure you aren't spreading around the internet. It is one that the site gets to pick rather than the user. But in reality, they are a often just a way to try to reduce some support and identity verification costs.
The path to get to the password manager is the case where the backup codes truly matter, because without them there may not be a way for support to restore access. Those codes may be your only way of regaining the master encryption key.
But that also winds up being part of the trade-off of security vs user friendliness. Some password managers are way easier to get back into.
Doesn't being able to sync your passkeys by entering your conventional password somewhere eliminate the whole point of passkeys? It just shifts the point where you can enter the password to recover your data to a less convenient place.
When I said "survival", I meant it in the "being able to make do with few resources in a time of crisis" way, not that you will literally die if you can't access an account. Losing a crucial device without a fallback of being able to log in somewhere else quickly can mean immediately losing access to payments (the most crippling, especially if you're not home), being stranded in an airport or even not having an identity document (in countries with digital ID systems). Any of these happening can lead to enormous losses in time, money or quality of life, depending on when and where this event hits you.
What? Did you read the thread? I never said passkeys can only exist on phones. The whole conversation is about "how do I log on with passkeys if something happens to my trusted device?". The parent comments talked about just using your phone, I'm saying there's lots of situations where someone might not have access to either a phone or an internet connection for it. And when this happens, you really don't want to be left without a way to access all vital digital services.
> I'm saying there's lots of situations where someone might not have access to either a phone or an internet connection for it. And when this happens, you really don't want to be left without a way to access all vital digital services.
And when that happens I'm usually glad my credential is a passkey on my keyring, as chances are if I don't have my phone and I haven't auth'd on to some computer I almost certainly don't have access to my password vault. But hey, my passkey works just fine without my phone. And I can trust that once I unplug my authenticator and log out of that session, there's no long lasting credentials left behind. I don't get that with passwords.
You're asking way too much foresight in this thread I guess. There are some people who have lived lives without any series of unfortunate events, they can't even imagine what the world can serve up.
If nearby (some country) any credit card or even my ID card will get me home. I can walk into a branch of my bank and - with some waiting and paper work - I should be able to get enough cash to get myself home.
Abroad I’d head to the nearest consulate of my home country. Might be difficult to get to if it’s in a far away city. Hard to prepare for abstractly.
But the problem is that you can't really backup passkeys and because people are frankly frequent tricked into using them, they have no good recovery options.
I know plenty of people who only have a phone, no other devices. They don't backup that phone, they should but they don't. They don't use a password manager either, maybe they should, but they don't.
My issue with passkeys are that they are designed for a reality that don't exist, or at least only exists for people who are already doing a lot to secure their devices.
They are designed for a wealthy technologically inclined user with a very stable lifestyle and trusted resources and connections to other people. You know, the exact people who developed them.
> But the problem is that you can't really backup passkeys
The individual passkey? Maybe not. But I don't really need to backup the passkey, I can just have backup passkeys or other backup authenticators, including complicated stored one-time passwords.
To answer your earlier hypothetical, I'm out traveling and I'm mugged. Well, hopefully, I'm not mugged in the part of the travels where I'm carrying truly everything at the moment, and I can just go back to the hotel room and re-auth with a device I saved there Problem solved, no big deal. If I lost truly everything while I'm out, I'd do as suggested elsewhere here and call home to get a trusted friend/family member to read me off the one time password saved at home or whatever.
> My issue with passkeys are that they are designed for a reality that don't exist
The reality of passwords being hijacked is absolutely a reality of today and is a constant issue for tons of people.
> I know plenty of people who only have a phone, no other devices.
And I really don't get why we can't also teach these people to also have a little token they use that can also be a part of their online identity. And sure, for certain kinds of accounts have appropriate levels of recoverability, but for the normal authentication workflows its so much better in so many ways.
>They are designed for a wealthy technologically inclined user with a very stable lifestyle and trusted resources and connections to other people. You know, the exact people who developed them.
And here you go posting
> I'd do as suggested elsewhere here and call home to get a trusted friend/family member to read me off the one time password saved at home or whateve
If you read what I posted you see why you live at a particular place of privileged and are seemingly incapable of putting yourself in another persons position where these things do not hold true.
"If you are a white male earning over 100,000 a year in a stable relationship with living family members, excess savings in the bank, in a stable first world country everything is going to be fine and the rest of you can get fucked" --what you keep repeating in different ways.
I mean I was pointing out that you were being racist and sexist from a position of privilege without realizing you were doing so. A kind of systematic failure caused by not realizing our choices as developers has real world impacts on the less privileged.
You're being racist and sexist by assuming wealthy westerners or those in stable relationships or those being able to call home to family are white males. If that's not racist I don't know what is. I don't think it takes being a white male to be able to call home to family when traveling internationally. You're assuming a point of view is invalid due to someone's race and gender.
Quit being racist and projecting identities on people.
This is about people who would have a hard time recovering digital identities. I imagine there were lots of white males fleeing war in Europe who probably struggled to get access to accounts backed with things like passkeys and other forms of 2FA. But I guess to you their struggles don't matter.
Its almost like you including gender and race was just your own projections of your own hatred for a particular group. You should probably think about things when painting people with such a wide brush of "white males" when trying to paint people in a derogatory fashion.
I spent a chunk of my life homeless. Don't project some identity on me that's not valid, or that I just totally lack some perspective due to your assumption of my race or gender. Its not a fair thing to do, its literally racist and sexist.
You could have tried to make your point without throwing in racist and sexist comments by just saying "wealthy western software developers" or whatever.
Great, now I just need to get back home to use my uncompromised accounts (which would have still been protected by my device as long as they're not NSO Group, but whatever). Gee, it seems my tickets back home were taken with my stolen phone! Not to worry, they sent me an email confirmation, so all I need to do is log into my passkey-protected email on my friend's phone and have them download my ticket in addition to theirs, or print it at a public computer. Oh wait
As long as you still have your passport, which you’d need for international travel anyway, you can get your boarding pass at the airport without any hassle.
Wouldn't I have the same problem with passwords? I would lose my phone and be unable to two factor log in to my Gmail account or bank from someone else's device?
With 2FA? Yes. 2FA is almost just as stupid and almost just as bad for regular users as passkeys are, but it got adopted due to historical loophole - by far the most popular form was TOTP delivered via SMS, then "authenticator" apps, both of which keep the code transferable - you can receive it on one device, transfer to yourself or someone else (which is a feature, not a bug) via any channel, and get it to work. Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).
I have over 2,000 accounts. The majority of them have unique passwords. I can count the services that have passwords that I know on one hand, with quite a few spare fingers.
> Passkeys were created specifically to close that loophole.
Credential sharing? I have a family share with passwords and passkeys in it. Passkeys most certainly didn't stop this. They did add friction to having a user being duped to share their password to someone claiming to be tech support, since you can no longer request plaintext secrets be sent over arbitrary channels.
> Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).
SMS is an ugly user experience and more importantly is expensive. Now a lot of services do emailed codes when they don't have a regulatory reason to require SMS - an even worse user experience, but less expensive.
We have authenticator apps which use a standard OATH setup, and quite a few platforms which have integrated support to try to sand over the worst part of the UX. Unfortunately they just didn't become popular, and OATH fails the same regulatory requirements that emailed codes fail.
No, it's fine. Most common example, I log in to my bank, they send an SMS, I copy the code and paste it into the web site. Works fine and I don't have to pick up my stupid phone, like I would if I used an authenticator app instead.
"and more importantly is expensive."
Not for me. The bank made several billion dollars last quarter, don't think it's a big problem for them, either.
Most common example, I log in to my bank, they say they sent an SMS, I sit there waiting to access my account, then 20 minutes later the SMS finally actually gets delivered after I've given up and left to do something else. Rinse/repeat.
Or another example, someone hijacks my SMS'es, and then they log in as me.
SMS sucks. SMS is insecure.
The amount of times I've experienced customers complaining about SMS 2FA not working well despite it being on their carrier failing to deliver the messages in a timely fashion really showed me how terrible it is.
Dunno what to tell you. Several possible points of failure there. Maybe your bank's system for sending SMS just sucks. Maybe you're in a place with poor mobile network coverage (which is a real problem for SMS 2FA, I agree, having lived in a place with nearly none for several years).
But for me, where I live now, with my bank, and my phone carrier, it works great. Never had a problem that I can think of. Typically, the SMS arrives within seconds. It's the least annoying and most reliable 2FA method I use.
I'm not that worried about potential security issues. Sure, it's a possible problem, but pretty low on the list of things to worry about.
The least annoying and most reliable form of 2FA I use is tapping the touch sensor, doing a biometric face unlock, or typing in my PIN on the device I currently have in my hands. Its miles less annoying and way more reliable.
Glad that works well for you. Does not work well for me. I do not care for laptops except when necessary and have come to loathe my phone. Everything important is done with desktop computers that do not have cameras or touch sensors, so biometrics can't work.
In general, I do not have a "device... currently have in my hands" and having to pick one up and unlock it is annoying.
"Good news then, this also works on desktops, even ones without cameras or touch sensors."
All of the 2FA methods forced on me by my employer and most online services that require it require a phone app. So no, it doesn't work on a desktop.
No, that's not the way it went. I joined the conversation, such as it is, to respond to the guy who said "SMS is an ugly user experience" to say no, it's fine.
I haven't shifted any goalposts: I've basically just reiterated to you that I think it's fine and better than the alternatives. Not a word about passkeys from me.
"SMS is an ugly user experience"...compared to passkeys.
It's not fine that SMS messages get delays. It's not fine that it requires a cell phone plan. It's not fine that it requires you to have cell service. Its not fine because it's insecure.
So many times I've had coworkers and clients frustrated they are pushed to letting their employer force SMS 2FA on their personal numbers. When they could just use passkeys these days baked into their work machines and not have those problems.
Settle down. I responded to the statement "SMS is an ugly user experience and more importantly is expensive" to point out that from my perspective, neither one of those things is true. The "user experience" is fine and to me, the cost is zero.
Then you decided, for some unknown reason, to jump in and... do something, but I'm not sure what. Seems like you're trying to convince me that my own view of my own experience is wrong somehow but — and one might think this would be obvious, but apparently not to you — that's not gonna work.
I think there exists a vein of contempt for anyone not fully embracing our bold new world, so many implementers etc. get the double bonus of alienating and frustrating all of the non conformers
Steam does this. If I want to login, it shows a barcode I can scan with the app and it logs me in without needing to enter my login information. Phone needs internet access, doesn't need to be on the same network as the device I'm logging in on.
I assume the QR code contains a token for the device, which is used by the app to authorize the login and the server automatically logs in the client on the device with the matching token.
Seems a lot safer to me than using my login credentials on a potentially unsafe device.
There's a whole set of fallbacks built in to the standard, including Bluetooth, local network connections, and going via a relay server. All of them eventually end up with your device signing something and handing that back to the browser on the other device to complete the authentication flow.
I cannot speak to how accurate your description is, but this description sounds like there are multiple weak points and multiple attack vectors that open this up to increased risk of compromise, undermining the very security stance it's supposed to provide.
The spec is quite thorough and well thought out in this regard. Despite what it "sounds like" when described, it is very secure, even with a variety of implementations. What is far weaker is that most sites that offer passkeys also offer a multitude of fallback recovery options.
AFAIK, the "scan this QR code" method of signing in with a passkey on a phone on a device w/o the passkey requires Bluetooth. There's some type of handshaking that goes on in order for you to prove you're in physical proximity of the device you are logging in on, to prevent phishing attacks.
Since I might have made someone mad... to clarify, as I understand it, Bluetooth is absolutely required for this "Scan the QR code" flow to work. However, it's also possible the actual authentication traffic to travel over a different pathway (wifi, cellular), but the bluetooth part is always required though to prove proximity. So on e.g. a library computer without Bluetooth enabled, you would not be able to log in with a passkey on your phone.
3. Communication (over websockets or a direct L2CAP channel)
The challenge is that a devices without bluetooth (at least today) don't have another common way to wirelessly judge proximity. A desktop/laptop without bluetooth likely either doesn't have NFC, or has bluetooth disabled by policy and would likely have cross-device passkeys disabled by policy as well.
Is this why I keep getting notifications that such-and-such a website wants access to devices on my local network? I've been denying those left and right lately and didn't understand what on earth they needed access to that for.
Android 17? If yes, then that's because they added a new permission specifically to block apps from LAN access, then bundled it together with "nearby devices" because the concept of "local network" is apparently too difficult for normies to understand or something.
The fact that nearly every passkey implementation is lacking in a variety of very impactful ways... is a very good reason to _not_ use passkeys.
When every passkey interaction is a different variety of user interaction nightmare, it's not very convincing that it's a good idea in the first place
> The website should display a qr code you can scan with your phone that allows you to then login...
A malicious website can display a QR code too. I think this "feature" could cause some of the security issues that passkesys were intended to solve.
I use Keepass and the free tier of Dropbox, to keep my passwords strong and available across multiple devices. (Dropbox not required, you can store the database on a thumb drive.) Backups are no problem.
Keepass (or KeepassXC) stores other data as well, including the correct URLs for sites. So my workflow is simply to click the URL from within Keepass, copy the username and password, and paste them into the login screen. So easy even an adult can do it! (Humor attempt)
For convenience, Keepass database can be unlocked with either a password or biometrics (your fingerprint).
(Not affiliated with Keepass, just a happy longtime user.)
That QR code from a malicious website will not actually communicate with the malicious website with authentication from the correct origin, most QR code phishing scams do not actually use passkeys but rather fall back to trying to get the user's fallback login information (if any). By spec, if the domain does not perfectly match the domain where the passkey was originally created, the phone (or passkey provider) will fail to find a matching passkey. And the domain is derived, not provided by the QR code data (it's all in the spec).
Basically, it's very hard if not basically impossible to spoof a QR code to access the real passkey via a malicious site. (caveat, without already having compromised something like the user's DNS, maybe? Even then the site would likely fail the cryptographic checks.)
The phishing protections of passkeys also works against "malicious QR codes". Which is a great example of why passkeys are kind of good, you stop needing to worry about a lot of attacks.
Yes, the passkey flow QR code contains a public key, and a local key exchange is done over bluetooth to prove proximity. That is used to set up a confidential channel.
That means attackers need more than to display a QR code, they also need a local presence (radio).
> > What if the computer you want to log in on doesn't have Bluetooth?
> Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.
What if the computer you want to log in on doesn't have a WiFi chip?
It doesn't have to be an old computer; for instance, the desktop computer I built last year uses a wired gigabit Ethernet connection to the router right next to it, and doesn't have (or need) any WiFi or Bluetooth chip.
They're cheap enough if you lose one it's not the end of the world. Goes on your keyring. Doesn't require esim management. Use NFC swipe/usb-plug-in + pin to use.
The problem isn't the cost of replacing it, the problem is - how do you log in when all your passkey-bearing devices just got flushed down the toilet?
How is that different from accidentally deleting your keepass database? Or forgetting your password? I think it’d be easier for me to forget than find myself trying to flush all my hw tokens…
Same way. A majority generally have a old phone that was already signed in to google. Or if they remember only Apple ID and password (one very difficult password) + sms. They can login on to a new phone.
Everything is SYNCED immediately.
What if you have a ransomeware that destroy everything on the same day your house and all backups burn down. And you cant get it from immutable backups as you wrote that decryption key in paper. And the bank will not allow you to access it as the govt deported you elsewhere.
I can back up my FIDO2 (non-)resident keys too. In the end it's just a piece of HW with some secret material inside. non-resident FIDO2 keys are easier to back up, because the master secret seed is fixed and shared for all origins and there's nothing stored on the key.
I can get another hw key (if one of mine breaks, which I, surprisingly enough, have not yet managed to achieve)
And since I have at least two at all times, the possibility of one of them breaking changes… not much really.
Paper can burn or get tossed, backups files can go corrupt, and I really don't understand what is that extra risk hw keys introduce…
There is at least one valid (in my opinion) reason to not like hw keys though: they cost real money to acquire, so you probably want an extra margin in your budget for the unlikely case they indeed decide to break.
> Also... Is flushing your whole keys down the toilet a problem you run into often?
It's a potential catastrophe I'd like to avoid if possible, but the catastrophe is not inherent to any other key I have.
House key: Make new copy for 10 USD. Alternatively, get a locksmith to unlock the door and change the lock. Even more alternatively, break a window or door. I still get into my house.
Car key: Make a new copy for >10 USD. Alternatively, call roadside assistance and get them to tow me somewhere I can get a new key. More inconvenient, still very possible.
TOTP 2FA and passwords: Password databases can be backed up, and so can TOTP seeds. It's inconvenient to do so, but I can at least still just leave copies around everywhere I can, so that it's extremely unlikely that I'll be completely locked out.
Yubikey: Making copies is literally impossible, so I'll need to buy two or three keys from the get go, and get them all out every time I need to add a new key. This is a huge inconvenience that no casual user will ever do (they might do 3-2-1 if it was set-and-forget, but Yubikeys aren't). If I don't do this, I lose permanent access to my accounts. There is no safety valve built in to the system. If I lose my key, I'm fucked.
But a majority don't do that. For them let them use passkeys. If the possibility is once in 10 years then I am happy to do that. A majority is happy to do that.
And yes, Google or Apple - dont say you should not keep passwords in your database and sync it with dropbox. DIY.
Copy pasting my other comment from an earlier thread
FIDO2 USB Security key -> Bitwarden (With master password) -> Every other method (topt/password)
I have 3 FIDO2 USB Security keys, One I carry with my persons at all times, one that stays with my main machine at all times and an offsite backup that is sitting in a friend's server, if my house burns down, I can either physically collect the key or use USB-IP to authenticate back into bitwarden and enroll a new key. (Actually all 3 are at home right now but that's ok)
what do you do when you forget your password? and what is the relative frequency of the average user forgetting a password vs flushing their authenticator device down the toilet?
I recommend a reciprocating saw with a metal cutting blade to get them into small enough pieces. Do not try to flush them all of the pieces at the same time. It's not just about whether they fit or not, they also need to be light enough for the water current of the flush to carry them all the way through. Otherwise, they may end up in the water trap and hinder your future use of the appliance. For small partial blockages, it may be possible to consume some extra fiber in order to be able to "sweep" some of the metallic remnants along, but this will void both your warranty and your bowels.
I am a doctor -- and a lawyer and an orbital mechanics specialist, as well as a highly respected behavioral therapist -- so you can trust my advice. Also, feel free to consult an AI on this topic; it would make for an amusing benchmark.
This is a legitimate problem, and one of the few cases where a third party login provider makes sense, at least for non-critical “apps”. If both tokens can be authorized to that provider, then you don’t need to enroll any more tokens for apps using that provider. The difficulty is creating a trustworthy provider system without weakening security (the provider shouldn’t be able to login without you) that doesn’t collect information about you and which can’t lock you out from all your accounts.
I’m not sure what work has been done on this since Mozilla Persona. I certainly wouldn’t want Google and Apple, or governments, to be the sole gatekeepers.
Why would you choose that over a synchronizing passkey manager?
A third party OAuth provider puts you at the mercy of the service provider, the other can work fully on your client side even if the app provider were to disappear tomorrow.
The only advantage I can think of is that you have a centralized place to revoke credentials in case your password manager does get compromised.
"A third party OAuth provider puts you at the mercy of the service provider" This is they key issue with trusting a third party to manage my passkeys, they can also BLOCK them and lock me out. An exception is if the passkeys are synced to all your devices and cannot be remotely wiped. I think this is how Apple works.
I didn’t think of this in the moment, but you’re right, this is an even bigger risk than compromise. There’s regularly a thread here about someone getting locked out of their cloud accounts, and now we’re going to gate everything behind those same accounts? Horrible idea.
The problem with hardware tokens is that they 1) Only store a limited number of logins, 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss
This two fatal flaws are what limits their usefulness to enterprise SSO and perhaps some other limited uses where the organization has the ability to replace tokens. (Even in a distributed enterprise, enterprise SSO may not be a good fit for hardware tokens, if they can't get replacements out to employees fast enough).
> the problem with hardware tokens is that they 1) Only store a limited number of logins,
1) It's one passkey used over and over, so it only takes 1 slot.
> 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss
2) With SSO used across enterprise exactly like you're talking about, works fine without having to reregister over and over. Been using this and have implemented it myself for years.
3) much cheaper than a phone with a much cheaper recovery path
4) no path is a free lunch, you're always going to be making compromises somewhere, it's the nature of security - it is adversarial
> it's the nature of security - it is adversarial
Yes, this is the issue. People don't like how adversarial security people act, and how they force things onto people. It's fine if a corporation wants to have some internal policy since they're the ones eating the cost if an employee can't work or whatever. Less so if individuals are forced into these wonky setups for no benefit (e.g. now I have to run and maintain and backup a Vaultwarden server just to log into my HSA, which is absurd).
>This is solved by passkey-implementing software and devices (with Bluetooth) allowing you to log in with a QR code (Webauthn via CTAP hybrid transport).
Ok but how do I share my Netflix or Spotify accounts for example with those?
In general you shouldn’t - Netflix[0] really should get proper invite-based family sharing, and Spotify’s subscriber agreement has a section that defines Premium as a “Single-user Paid Subscription” and thus can’t be used by multiple people, legally (and you might be at risk of getting banned if they detect it)
However, passkeys can and are available to be shared via password managers. They’re not locked to the secure chip on the device where they live usually. iOS’ Passwords app has a share button and 1Password lets you share passkey-containing items.
In fact, the QR code login feature makes it even easier to do a one-time sign in to your account for a friend, if you don’t want them to be able to login to your account indefinitely.
0: Netflix doesn’t support passkeys because their main audience is people signing in via smart TVs and whatnot, which largely don’t support CTAP or Webauthn in general)
Me: Invents more new ways of being problematic for the company spreading the ideas to millions of others decreasing their profitability to almost nothing.
Me to company: Damn, guess you shouldn't have been an asshole about it, kind of backfired on you.
The responsible product owners will already have bounced 18 months prior after tweaking the stats to falsify the customer satisfaction rate and grabbing their bonus on the way out.
The same way you share them now: sharing the account name and password and doing whatever you currently do to deal with any 2FA they occasionally toss in.
If they also allow passkeys as an alternative form of login that doesn't need 2FA you can use those to make the account sharing more secure.
When setting up sharing with someone first change the password to something else, and then share the account name and password. After they log in the can add a passkey to the account on their device or devices.
Then you can change the password back to your real password. When they want to use the account they login with their passkey.
If the service doesn't accept login passkeys but does allows passkeys for 2FA, you have to use real password sharing, but at least they can have a passkey for 2FA which may be easier than how you know handle 2FA.
How do people handle 2FA with account sharing? If the site uses TOTP you can give them the QR code that you received back when you made the account (you do save a screenshot of such QR codes for backup, right?).
But how do you handle SMS 2FA, which seems to be far more commonly offered than TOTP?
For email 2FA I suppose you could set up a filter on your incoming mail that forwards any incoming code emails to the people you shared with, and hope that the time limit on the code is long enough for this to work.
2FA is lowkey designed to reduce paid account sharing. It's always those services that are so eager to get people 2FA'd. Microsoft Minecraft account is the hardest thing to log into, and they even perma locked tons of people out.
TOTP is unfamiliar or hard to use for most people, so they use SMS. Most sites don't support TOTP either.
Even if you use TOTP, it's not designed to be shared, for example look up what hoops you need to jump through to export a single TOTP code in Google Authenticator. And they used to not even have that option; they told you to set up multiple TOTP codes on each website instead. Even on 1password I had to look up a tutorial on how to import a TOTP code cause the menu is in a very non-obvious and deep spot.
I've shared with non-tech people a few accesses with TOTP codes and it's just a WhatsApp message away "hey dad, enter 12345 when asked".
Sign in with a QR code is dangerous though because at that point theres very little stopping QR phishing and forwarding the bluetooth request to your browser. See the most common Discord scam.
> forwarding the bluetooth request to your browser.
This isn't a thing. Discord's QR Code scanning is entirely a feature they made unrelated to passkeys or bluetooth. Passkey auth using a QR code has a step that verifies the proximity of both devices using BLE.
In the same vein as 2fa, going up to a fresh computer and trying to log into anything is now a nightmare. Every service has a 2fa that somehow loops into another provider that also has 2fa.
And some 2fa, if not many, make accounts weaker. Apple's solution to get around 2fa is to put in SOMEBODY ELSES phone number that I trust, as a backdoor. It's an insane solution. And its normalized, and nobody questions it.
Yeah, many do not even allow you to enter in a custom question, which would be marginally better--at least for users who care about security.
Then you'd have the option to craft a question which is (A) personally memorable (B) specifically phrased to avoid ambiguity, (C) not public or guessable, and (D) unique to a service.
* "Where is your first pet buried?"
* "While on vacation, The Noodle Incident happened in which city?"
* In what year did you first see Example Band live in concert along with Alice and Bob?"
drtz · · focus · HN ↗
If you use multiple devices throughout the day, registering passkeys in all of these systems becomes a big headache with O(m*n) complexity, so putting the passkeys in a password manager is the only realistic solution. But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.
The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for. I've accidentally set up passkeys just by clicking an okay button a few times in the past and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).
judge2020 · · focus · HN ↗
This is solved by passkey-implementing software and devices (with Bluetooth) allowing you to log in with a QR code (Webauthn via CTAP hybrid transport). iOS and Android support this, and it’s generally not a locked-down thing if other devices wanted to do it too.
The only use case left is in “how do I login if all my devices are stolen/fall into a body of water” in which there really isn’t an answer beyond “get (a|your) device back, sign back into your password manager, use that to get back into critical accounts”.
201984 · · focus · HN ↗
limagnolia · · focus · HN ↗
201984 · · focus · HN ↗
Yokolos · · focus · HN ↗
roryirvine · · focus · HN ↗
stonogo · · focus · HN ↗
roryirvine · · focus · HN ↗
The number of people sharing GP's concerns for reasons of poverty rather than because of their personal security posture will be vanishingly small.
arcfour · · focus · HN ↗
rcxdude · · focus · HN ↗
kps · · focus · HN ↗
Only 85%¹ of the population are over the age of 4. Smart kids they've got.
¹ <a href="https://populationpyramids.org/zambia" rel="nofollow">https://populationpyramids.org/zambia
stonogo · · focus · HN ↗
tavavex · · focus · HN ↗
These may seem like nitpicks, but there's probably a thousand rare scenarios like these that exist. You inevitably have to consider them when you're moving from punching in letters and numbers that you remember in the normal, low-tech way to a complex networked two-device workflow.
limagnolia · · focus · HN ↗
horsawlarway · · focus · HN ↗
They use bank like Ally or Discover with no physical branches.
They use a mortgage provider like Rocket mortgage with no physical branches.
They use a medication delivery service with no physical customer facing pharmacies.
They have an employer that only facilitates reimbursement for expenses via online tools.
etc...
I guess "survive" has a sliding scale, but if I lost access to critical accounts... my life is going to FUCKING SUCK in a non-trivial and very impactful way almost immediately, on many fronts.
And if your answer to that problem is "well, just call them"... then we're right back to the point the article is making: "An account’s security is still dictated by the weakest recovery method"
Passkeys aren't a meaningful improvement in security - assuming you do actually have decent password hygiene like a password manager.
epihelix · · focus · HN ↗
What am I missing? Either we retain passwords as backup for a lost or stolen device - in which case, all the security concerns are still there - or we only use passkeys, in which case we've added a clear nonrecoverable point of failure in the system.
AlienRobot · · focus · HN ↗
Then we introduce all these "security" mechanisms that make it literally impossible to recover an account without backup codes.
Where do you store the backup codes? The average person, if they store it at all, will store it on a plain text file or in a sticky note.
Except that this creates a much more brittle system. Systems are safe when they are routinely tested/used. If you routinely have to enter your password, you are aware you need it. If you don't need your password, and you never have to enter your backup codes, you won't feel the importance of them until you actually need them.
It's the whole "I have backups" vs. "the backups actually work" problem except it's pushed onto the users who have zero technical knowledge.
dwaite · · focus · HN ↗
Everything else which has ever given me a backup code... gets stored in a secure note in my password manager.
It is just another knowledge-based factor. It is one that they are reasonably sure you aren't spreading around the internet. It is one that the site gets to pick rather than the user. But in reality, they are a often just a way to try to reduce some support and identity verification costs.
The path to get to the password manager is the case where the backup codes truly matter, because without them there may not be a way for support to restore access. Those codes may be your only way of regaining the master encryption key.
But that also winds up being part of the trade-off of security vs user friendliness. Some password managers are way easier to get back into.
tavavex · · focus · HN ↗
When I said "survival", I meant it in the "being able to make do with few resources in a time of crisis" way, not that you will literally die if you can't access an account. Losing a crucial device without a fallback of being able to log in somewhere else quickly can mean immediately losing access to payments (the most crippling, especially if you're not home), being stranded in an airport or even not having an identity document (in countries with digital ID systems). Any of these happening can lead to enormous losses in time, money or quality of life, depending on when and where this event hits you.
nightski · · focus · HN ↗
vel0city · · focus · HN ↗
tavavex · · focus · HN ↗
vel0city · · focus · HN ↗
And when that happens I'm usually glad my credential is a passkey on my keyring, as chances are if I don't have my phone and I haven't auth'd on to some computer I almost certainly don't have access to my password vault. But hey, my passkey works just fine without my phone. And I can trust that once I unplug my authenticator and log out of that session, there's no long lasting credentials left behind. I don't get that with passwords.
Aren't passkeys great?
pixl97 · · focus · HN ↗
You get mugged.
They take your phone and keyring.
They can't do anything with it since it's locked, but you don't have it.
Aren't passkeys great?
jazzyjackson · · focus · HN ↗
I have a backup key at home
Mission accomplished
rcxdude · · focus · HN ↗
pixl97 · · focus · HN ↗
dwaite · · focus · HN ↗
I have not yet done an actual test within Japan, however.
realityking · · focus · HN ↗
Abroad I’d head to the nearest consulate of my home country. Might be difficult to get to if it’s in a far away city. Hard to prepare for abstractly.
mrweasel · · focus · HN ↗
I know plenty of people who only have a phone, no other devices. They don't backup that phone, they should but they don't. They don't use a password manager either, maybe they should, but they don't.
My issue with passkeys are that they are designed for a reality that don't exist, or at least only exists for people who are already doing a lot to secure their devices.
pixl97 · · focus · HN ↗
They are designed for a wealthy technologically inclined user with a very stable lifestyle and trusted resources and connections to other people. You know, the exact people who developed them.
vel0city · · focus · HN ↗
The individual passkey? Maybe not. But I don't really need to backup the passkey, I can just have backup passkeys or other backup authenticators, including complicated stored one-time passwords.
To answer your earlier hypothetical, I'm out traveling and I'm mugged. Well, hopefully, I'm not mugged in the part of the travels where I'm carrying truly everything at the moment, and I can just go back to the hotel room and re-auth with a device I saved there Problem solved, no big deal. If I lost truly everything while I'm out, I'd do as suggested elsewhere here and call home to get a trusted friend/family member to read me off the one time password saved at home or whatever.
> My issue with passkeys are that they are designed for a reality that don't exist
The reality of passwords being hijacked is absolutely a reality of today and is a constant issue for tons of people.
> I know plenty of people who only have a phone, no other devices.
And I really don't get why we can't also teach these people to also have a little token they use that can also be a part of their online identity. And sure, for certain kinds of accounts have appropriate levels of recoverability, but for the normal authentication workflows its so much better in so many ways.
pixl97 · · focus · HN ↗
>They are designed for a wealthy technologically inclined user with a very stable lifestyle and trusted resources and connections to other people. You know, the exact people who developed them.
And here you go posting
> I'd do as suggested elsewhere here and call home to get a trusted friend/family member to read me off the one time password saved at home or whateve
If you read what I posted you see why you live at a particular place of privileged and are seemingly incapable of putting yourself in another persons position where these things do not hold true.
"If you are a white male earning over 100,000 a year in a stable relationship with living family members, excess savings in the bank, in a stable first world country everything is going to be fine and the rest of you can get fucked" --what you keep repeating in different ways.
vel0city · · focus · HN ↗
Also, you're posting incredibly racist and sexist statements here. Why does race and gender matter here?
Stop being racist.
pixl97 · · focus · HN ↗
vel0city · · focus · HN ↗
Quit being racist and projecting identities on people.
This is about people who would have a hard time recovering digital identities. I imagine there were lots of white males fleeing war in Europe who probably struggled to get access to accounts backed with things like passkeys and other forms of 2FA. But I guess to you their struggles don't matter.
Its almost like you including gender and race was just your own projections of your own hatred for a particular group. You should probably think about things when painting people with such a wide brush of "white males" when trying to paint people in a derogatory fashion.
I spent a chunk of my life homeless. Don't project some identity on me that's not valid, or that I just totally lack some perspective due to your assumption of my race or gender. Its not a fair thing to do, its literally racist and sexist.
You could have tried to make your point without throwing in racist and sexist comments by just saying "wealthy western software developers" or whatever.
tavavex · · focus · HN ↗
realityking · · focus · HN ↗
staticman2 · · focus · HN ↗
pixl97 · · focus · HN ↗
TeMPOraL · · focus · HN ↗
With 2FA? Yes. 2FA is almost just as stupid and almost just as bad for regular users as passkeys are, but it got adopted due to historical loophole - by far the most popular form was TOTP delivered via SMS, then "authenticator" apps, both of which keep the code transferable - you can receive it on one device, transfer to yourself or someone else (which is a feature, not a bug) via any channel, and get it to work. Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).
dwaite · · focus · HN ↗
> Passkeys were created specifically to close that loophole.
Credential sharing? I have a family share with passwords and passkeys in it. Passkeys most certainly didn't stop this. They did add friction to having a user being duped to share their password to someone claiming to be tech support, since you can no longer request plaintext secrets be sent over arbitrary channels.
> Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).
SMS is an ugly user experience and more importantly is expensive. Now a lot of services do emailed codes when they don't have a regulatory reason to require SMS - an even worse user experience, but less expensive.
We have authenticator apps which use a standard OATH setup, and quite a few platforms which have integrated support to try to sand over the worst part of the UX. Unfortunately they just didn't become popular, and OATH fails the same regulatory requirements that emailed codes fail.
f30e3dfed1c9 · · focus · HN ↗
No, it's fine. Most common example, I log in to my bank, they send an SMS, I copy the code and paste it into the web site. Works fine and I don't have to pick up my stupid phone, like I would if I used an authenticator app instead.
"and more importantly is expensive."
Not for me. The bank made several billion dollars last quarter, don't think it's a big problem for them, either.
vel0city · · focus · HN ↗
Or another example, someone hijacks my SMS'es, and then they log in as me.
SMS sucks. SMS is insecure.
The amount of times I've experienced customers complaining about SMS 2FA not working well despite it being on their carrier failing to deliver the messages in a timely fashion really showed me how terrible it is.
f30e3dfed1c9 · · focus · HN ↗
But for me, where I live now, with my bank, and my phone carrier, it works great. Never had a problem that I can think of. Typically, the SMS arrives within seconds. It's the least annoying and most reliable 2FA method I use.
I'm not that worried about potential security issues. Sure, it's a possible problem, but pretty low on the list of things to worry about.
vel0city · · focus · HN ↗
f30e3dfed1c9 · · focus · HN ↗
In general, I do not have a "device... currently have in my hands" and having to pick one up and unlock it is annoying.
vel0city · · focus · HN ↗
Good news then, this also works on desktops, even ones without cameras or touch sensors. But sure, keep moving goalposts.
f30e3dfed1c9 · · focus · HN ↗
All of the 2FA methods forced on me by my employer and most online services that require it require a phone app. So no, it doesn't work on a desktop.
vel0city · · focus · HN ↗
Which, while I can't speak to your specific employer, tons are moving to support passkeys. Largely because forcing these apps suck and SMS sucks.
f30e3dfed1c9 · · focus · HN ↗
No, that's not the way it went. I joined the conversation, such as it is, to respond to the guy who said "SMS is an ugly user experience" to say no, it's fine.
I haven't shifted any goalposts: I've basically just reiterated to you that I think it's fine and better than the alternatives. Not a word about passkeys from me.
vel0city · · focus · HN ↗
It's not fine that SMS messages get delays. It's not fine that it requires a cell phone plan. It's not fine that it requires you to have cell service. Its not fine because it's insecure.
So many times I've had coworkers and clients frustrated they are pushed to letting their employer force SMS 2FA on their personal numbers. When they could just use passkeys these days baked into their work machines and not have those problems.
f30e3dfed1c9 · · focus · HN ↗
Then you decided, for some unknown reason, to jump in and... do something, but I'm not sure what. Seems like you're trying to convince me that my own view of my own experience is wrong somehow but — and one might think this would be obvious, but apparently not to you — that's not gonna work.
kyleee · · focus · HN ↗
enriquto · · focus · HN ↗
Are you talking about your phone here?
roryirvine · · focus · HN ↗
But, again, if you don't trust your phone then how likely is it that you will be prepared to trust a public computer?
Yokolos · · focus · HN ↗
I assume the QR code contains a token for the device, which is used by the app to authorize the login and the server automatically logs in the client on the device with the matching token.
Seems a lot safer to me than using my login credentials on a potentially unsafe device.
limagnolia · · focus · HN ↗
jerkstate · · focus · HN ↗
cpburns2009 · · focus · HN ↗
cesarb · · focus · HN ↗
1. It might be on a voice network but not on a data network; for instance, if you don't have a data plan.
2. Modern smartphones are actually a hybrid of a traditional cell phone and a traditional PDA, and you might be using it for the PDA part.
jon-wood · · focus · HN ↗
thwarted · · focus · HN ↗
sgerenser · · focus · HN ↗
LocalPCGuy · · focus · HN ↗
sgerenser · · focus · HN ↗
sgerenser · · focus · HN ↗
dwaite · · focus · HN ↗
1. Initiation (QR code, NFC in draft)
2. (Proximal) negotiation (BLE key exchange)
3. Communication (over websockets or a direct L2CAP channel)
The challenge is that a devices without bluetooth (at least today) don't have another common way to wirelessly judge proximity. A desktop/laptop without bluetooth likely either doesn't have NFC, or has bluetooth disabled by policy and would likely have cross-device passkeys disabled by policy as well.
MrMetlHed · · focus · HN ↗
TeMPOraL · · focus · HN ↗
dwaite · · focus · HN ↗
The browser delegates passkey plumbing up to the core platform typically, so it already should have the appropriate permissions.
alienbaby · · focus · HN ↗
RHSeeger · · focus · HN ↗
When every passkey interaction is a different variety of user interaction nightmare, it's not very convincing that it's a good idea in the first place
judge2020 · · focus · HN ↗
Passkey QR codes are only WebAuthn via CTAP hybrid transport (with BLE verified proximity)
wpollock · · focus · HN ↗
A malicious website can display a QR code too. I think this "feature" could cause some of the security issues that passkesys were intended to solve.
I use Keepass and the free tier of Dropbox, to keep my passwords strong and available across multiple devices. (Dropbox not required, you can store the database on a thumb drive.) Backups are no problem.
Keepass (or KeepassXC) stores other data as well, including the correct URLs for sites. So my workflow is simply to click the URL from within Keepass, copy the username and password, and paste them into the login screen. So easy even an adult can do it! (Humor attempt)
For convenience, Keepass database can be unlocked with either a password or biometrics (your fingerprint).
(Not affiliated with Keepass, just a happy longtime user.)
LocalPCGuy · · focus · HN ↗
Basically, it's very hard if not basically impossible to spoof a QR code to access the real passkey via a malicious site. (caveat, without already having compromised something like the user's DNS, maybe? Even then the site would likely fail the cryptographic checks.)
Ferret7446 · · focus · HN ↗
dwaite · · focus · HN ↗
That means attackers need more than to display a QR code, they also need a local presence (radio).
xp84 · · focus · HN ↗
judge2020 · · focus · HN ↗
cesarb · · focus · HN ↗
> Only if they’re a bit old. Nowadays WiFi chips double as Bluetooth chips on newer platforms.
What if the computer you want to log in on doesn't have a WiFi chip?
It doesn't have to be an old computer; for instance, the desktop computer I built last year uses a wired gigabit Ethernet connection to the router right next to it, and doesn't have (or need) any WiFi or Bluetooth chip.
RHSeeger · · focus · HN ↗
reaperducer · · focus · HN ↗
That's a technocratic reply, not one that is useful in the real world.
As noted by the person you're replying to, it's not his computer. It's a public library.
Most computers in non-residential settings will have various features locked down, including Bluetooth.
esseph · · focus · HN ↗
They're cheap enough if you lose one it's not the end of the world. Goes on your keyring. Doesn't require esim management. Use NFC swipe/usb-plug-in + pin to use.
pavel_lishin · · focus · HN ↗
remix2000 · · focus · HN ↗
pavel_lishin · · focus · HN ↗
faust201 · · focus · HN ↗
Everything is SYNCED immediately.
What if you have a ransomeware that destroy everything on the same day your house and all backups burn down. And you cant get it from immutable backups as you wrote that decryption key in paper. And the bank will not allow you to access it as the govt deported you elsewhere.
megous · · focus · HN ↗
remix2000 · · focus · HN ↗
And since I have at least two at all times, the possibility of one of them breaking changes… not much really.
Paper can burn or get tossed, backups files can go corrupt, and I really don't understand what is that extra risk hw keys introduce…
There is at least one valid (in my opinion) reason to not like hw keys though: they cost real money to acquire, so you probably want an extra margin in your budget for the unlikely case they indeed decide to break.
esseph · · focus · HN ↗
Telaneo · · focus · HN ↗
It's a potential catastrophe I'd like to avoid if possible, but the catastrophe is not inherent to any other key I have.
House key: Make new copy for 10 USD. Alternatively, get a locksmith to unlock the door and change the lock. Even more alternatively, break a window or door. I still get into my house.
Car key: Make a new copy for >10 USD. Alternatively, call roadside assistance and get them to tow me somewhere I can get a new key. More inconvenient, still very possible.
TOTP 2FA and passwords: Password databases can be backed up, and so can TOTP seeds. It's inconvenient to do so, but I can at least still just leave copies around everywhere I can, so that it's extremely unlikely that I'll be completely locked out.
Yubikey: Making copies is literally impossible, so I'll need to buy two or three keys from the get go, and get them all out every time I need to add a new key. This is a huge inconvenience that no casual user will ever do (they might do 3-2-1 if it was set-and-forget, but Yubikeys aren't). If I don't do this, I lose permanent access to my accounts. There is no safety valve built in to the system. If I lose my key, I'm fucked.
faust201 · · focus · HN ↗
And yes, Google or Apple - dont say you should not keep passwords in your database and sync it with dropbox. DIY.
Rest of us want convenience.
vablings · · focus · HN ↗
FIDO2 USB Security key -> Bitwarden (With master password) -> Every other method (topt/password)
I have 3 FIDO2 USB Security keys, One I carry with my persons at all times, one that stays with my main machine at all times and an offsite backup that is sitting in a friend's server, if my house burns down, I can either physically collect the key or use USB-IP to authenticate back into bitwarden and enroll a new key. (Actually all 3 are at home right now but that's ok)
notatoad · · focus · HN ↗
vel0city · · focus · HN ↗
sfink · · focus · HN ↗
I am a doctor -- and a lawyer and an orbital mechanics specialist, as well as a highly respected behavioral therapist -- so you can trust my advice. Also, feel free to consult an AI on this topic; it would make for an amusing benchmark.
pavel_lishin · · focus · HN ↗
ndriscoll · · focus · HN ↗
esseph · · focus · HN ↗
lxgr · · focus · HN ↗
I suspect that most people that ostensibly do this actually only enroll one for non-critical accounts and then depend on some fallback mechanism.
iamnothere · · focus · HN ↗
I’m not sure what work has been done on this since Mozilla Persona. I certainly wouldn’t want Google and Apple, or governments, to be the sole gatekeepers.
lxgr · · focus · HN ↗
A third party OAuth provider puts you at the mercy of the service provider, the other can work fully on your client side even if the app provider were to disappear tomorrow.
The only advantage I can think of is that you have a centralized place to revoke credentials in case your password manager does get compromised.
iamnothere · · focus · HN ↗
UltraSane · · focus · HN ↗
iamnothere · · focus · HN ↗
lxgr · · focus · HN ↗
lxgr · · focus · HN ↗
limagnolia · · focus · HN ↗
This two fatal flaws are what limits their usefulness to enterprise SSO and perhaps some other limited uses where the organization has the ability to replace tokens. (Even in a distributed enterprise, enterprise SSO may not be a good fit for hardware tokens, if they can't get replacements out to employees fast enough).
esseph · · focus · HN ↗
1) It's one passkey used over and over, so it only takes 1 slot.
> 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss
2) With SSO used across enterprise exactly like you're talking about, works fine without having to reregister over and over. Been using this and have implemented it myself for years.
3) much cheaper than a phone with a much cheaper recovery path
4) no path is a free lunch, you're always going to be making compromises somewhere, it's the nature of security - it is adversarial
ndriscoll · · focus · HN ↗
Yes, this is the issue. People don't like how adversarial security people act, and how they force things onto people. It's fine if a corporation wants to have some internal policy since they're the ones eating the cost if an employee can't work or whatever. Less so if individuals are forced into these wonky setups for no benefit (e.g. now I have to run and maintain and backup a Vaultwarden server just to log into my HSA, which is absurd).
[deleted] · · focus · HN ↗
[deleted]
darkwater · · focus · HN ↗
Ok but how do I share my Netflix or Spotify accounts for example with those?
judge2020 · · focus · HN ↗
However, passkeys can and are available to be shared via password managers. They’re not locked to the secure chip on the device where they live usually. iOS’ Passwords app has a share button and 1Password lets you share passkey-containing items.
In fact, the QR code login feature makes it even easier to do a one-time sign in to your account for a friend, if you don’t want them to be able to login to your account indefinitely.
0: Netflix doesn’t support passkeys because their main audience is people signing in via smart TVs and whatnot, which largely don’t support CTAP or Webauthn in general)
pixl97 · · focus · HN ↗
Me to said companies: I will do what I want.
brendoelfrendo · · focus · HN ↗
pixl97 · · focus · HN ↗
Me to company: Damn, guess you shouldn't have been an asshole about it, kind of backfired on you.
mahboi · · focus · HN ↗
LevGoldstein · · focus · HN ↗
tzs · · focus · HN ↗
If they also allow passkeys as an alternative form of login that doesn't need 2FA you can use those to make the account sharing more secure.
When setting up sharing with someone first change the password to something else, and then share the account name and password. After they log in the can add a passkey to the account on their device or devices.
Then you can change the password back to your real password. When they want to use the account they login with their passkey.
If the service doesn't accept login passkeys but does allows passkeys for 2FA, you have to use real password sharing, but at least they can have a passkey for 2FA which may be easier than how you know handle 2FA.
How do people handle 2FA with account sharing? If the site uses TOTP you can give them the QR code that you received back when you made the account (you do save a screenshot of such QR codes for backup, right?).
But how do you handle SMS 2FA, which seems to be far more commonly offered than TOTP?
For email 2FA I suppose you could set up a filter on your incoming mail that forwards any incoming code emails to the people you shared with, and hope that the time limit on the code is long enough for this to work.
mahboi · · focus · HN ↗
Velocifyer · · focus · HN ↗
mahboi · · focus · HN ↗
Even if you use TOTP, it's not designed to be shared, for example look up what hoops you need to jump through to export a single TOTP code in Google Authenticator. And they used to not even have that option; they told you to set up multiple TOTP codes on each website instead. Even on 1password I had to look up a tutorial on how to import a TOTP code cause the menu is in a very non-obvious and deep spot.
darkwater · · focus · HN ↗
mahboi · · focus · HN ↗
epihelix · · focus · HN ↗
deaton · · focus · HN ↗
judge2020 · · focus · HN ↗
This isn't a thing. Discord's QR Code scanning is entirely a feature they made unrelated to passkeys or bluetooth. Passkey auth using a QR code has a step that verifies the proximity of both devices using BLE.
basch · · focus · HN ↗
In the same vein as 2fa, going up to a fresh computer and trying to log into anything is now a nightmare. Every service has a 2fa that somehow loops into another provider that also has 2fa.
And some 2fa, if not many, make accounts weaker. Apple's solution to get around 2fa is to put in SOMEBODY ELSES phone number that I trust, as a backdoor. It's an insane solution. And its normalized, and nobody questions it.
Terr_ · · focus · HN ↗
basch · · focus · HN ↗
its just three additional passwords.
should you type the same brother name in each time? should you even answer with a name?
don't get me wrong, they were insane, but they can be repurposed.
samspot · · focus · HN ↗
Terr_ · · focus · HN ↗
Then you'd have the option to craft a question which is (A) personally memorable (B) specifically phrased to avoid ambiguity, (C) not public or guessable, and (D) unique to a service.
* "Where is your first pet buried?"
* "While on vacation, The Noodle Incident happened in which city?"
* In what year did you first see Example Band live in concert along with Alice and Bob?"
basch · · focus · HN ↗