Tailscale doesn't want your password
tailscale.com
tailscale.com
So, how do you reset your password when you forget it? Well, it depends.
Some apps/sites just send you a password reset email. Apps/sites like those would reset your passkey the same way: they'd send you a passkey reset email, you'd click the link in the email, and they'd let you regenerate your passkey then and there.
Some apps/sites try to do something cleverer, e.g. requiring additional factors to reset (MFA), or appointing a "trusted contact" user who can confirm your password reset, or asking "security questions" that only you know the answer to. Those apps/sites would put you through the same process to reset your passkey.
"How do I reset my password when I forget it" is an infamous balancing act between user friendliness and strict security. The "reset my passkey" problem is exactly as hard, no easier and no harder, as the "reset my password" problem.
(Of course, it's possible to have a site that has no way to reset your password, and just assumes that you'll never forget your password. Similarly, those sites could have no way to reset your passkey. In that case, the problem is as you say: there'd be no way to recover your keys if you lost access to them.)
But I don't! I can write a password in any amount of low and high tech ways! I have them printed on paper in safe deposit box (my wife is bad with passwords, so this is safety if I should perish:), I have them in a password manager on USB sticks at home in a safe, I have them copied on my NAS and laptop and so on.
Whereas passkeys, it seems from everywhere I read to be far more fragile, far more locked in to specific perishable hardware device and a specific vendor ecosystem, and very limited or no ways to handle passkeys in a low tech way or as a file/artifact to be backed up. Basically they assume I live on and with my phone.
To put it bluntly:
Passwords are something I can use if I show up naked at a stranger's house. They can be with me in and through an emergency (physical emergencies exist! Computer geeks forget about those!). Or more commonly, I can use them to check my email or comms if I forget my phone at a friend's house.
Passkeys are... strictly worse?
This thread has urged me to write a post clarifying some of the misconceptions I always see:
https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
I'm not sure I really prefer passkeys less than passwords but I do think some of the "misconceptions" aren't really misconceptions, but realistic concerns about what happens in practice. It might be better to be up front about these than dismissive, because that's where the problems in practice develop.
A company will make it, vote with your wallet and buy the one that suits you.
I'm looking forward to BitWarden supporting Passkeys, for example, as that's my preferred way of using them.
If that means "install BitWarden on all of your devices. The devices will work with it and you can backup/export your key locally" that's fantastic, I'd love to see a guide on how to get that going on all of my devices. However, if that means "according to the standards, something like a BitWarden could do what you want it to do, if they built it, allowed export, and the devices all allowed integration. Alternatively, you replace your devices with ones that do." then I really don't care what the theory says could be done, Passkeys cannot actually replace my use of passwords at the moment.
Look at this comment, as the first example I found:
https://news.ycombinator.com/item?id=36237683
It basically says "Passkeys = USB keys", which is wrong. If you don't like the tradeoffs that specific authenticator makes, use another passkey authenticator type.
"Passkeys are strictly less secure" is just objectively wrong.
Maybe in theory. In practice, I couldn't even look at the passkey Google has created on my android phone. So you absolutely cannot write it down.
The fact remains that, if you want a Passkey you can write down, you can do that.
Once more, maybe this is possible in theory. In reality, I can't find any way to use apple's passkey implementation on my android phone.
One counter point though is that... if there is a new lifesaving technology, and even the somewhat IT literate / somewhat geeky / folks who WANT to understand it, are struggling... it may not be as simple and easy and safe. If I ask "how do I backup my passwords", I'll have 10 million folks answer "use a password manager, backup the file". When I ask similar questions with passkeys, the breadth,inconsistency and complexity of answers is as insightful as it is worrisome.
"Does that mean that passkeys can't be shared between users or devices?" is a 100% reasonable question.
"Passkeys are a step backward because they can't be shared between users or devices" is not really a question, it's an opinion based on imagination.
And passwords are just as complex. How do you securely share a login with another user?
Yes, there's complexity, but it's complexity born of a change in paradigm. The actual new thing is either equally simple or simpler than traditional passwords, once you factor in scenarios like backup, transfer, multi-device sync, sharing, etc. It's just different.
Why not? There are lots of great things in the world that are easy and a joy to use, but fairly challenging to learn the technical details of. The electricity grid, airplanes, microwave ovens, you name it. Tons of straightforward user experiences that take some work to understand.
I use a password manager with a full backup of the vault, so the answer to most of the parent's question would be solved by getting the vault back from backup. Except:
- passkeys are not yet supported by my password manager, so I'd have to wait for a while
- can I move Safari's passkeys to my password managers afterwards, like I did with passwords ? probably not ?
- can I move my password manager's passkeys to another one if I need to ? I have no idea.
That's where, at least for me, none of this is simpler than I think. The same way reset passwords is an absolute last ditch effort, I hope passkeys can be managed without having to get back to the service every time we change how we want to manage access on our side.
Like, I can keep all my passwords in a password manager. And then copy and replicate that database however I want to.
With passkeys, I'd need to set up and authenticate additional devices... for every of hundreds of accounts I have? Am I wrong? Like if I have an android tablet and iPhone and windows PC and a Linux PC (as I do) that's half a dozen setups for each and every account? And this is a good thing??
> With passkeys, I'd need to set up and authenticate additional devices
This is true, if you don't use a platform authenticator or password manager and only use hardware keys.
Also you don't really have to set up everything everywhere all at once - passwords still work and you can use phone passkey on PC via QR.
In the Apple ecosystem your passkey is / can be sent to your iCloud Keychain, which you can restore when you can a replacement device (and keep using on non-lost/stolen devices):
* https://support.apple.com/en-ca/guide/iphone/iph82d6721b2/io...
If you do not have access to a device with your pass key on it then using iCloud Keychain is probably not the best service to use for your use case of an Android device. Use one of the many other services that also provide Android support and passkey support. Then you can access that service and access your passkeys.
iCloud is one of many. Bitwarden and 1Password will both support passkeys, both have Android support.
If they registered to their email with a passkey, great.
Either way, passkeys seem to reduce the risk of the email being compromised.
You're definitely right that passkeys drastically improve the bottom line security for the least protected folks (which are probably the majority). It is a step in the right direction, for sure. But they also make things worse for me - someone who uses different random high-entropy passwords for almost everything except local sudo and unlock PIN codes. I want to use PKI instead of shared secrets, but when I try - it's extremely inconvenient, so I know at some point I'll just give up. This, and the fact that my bottom line is not moving up at all - it still remains the same, limited by recovery processes' security - is frustrating.
Lost everything. Been using Bitwarden ever since.
This is a bit hard to know what to search on. Where can I read more about the policy changes?
Isn't this the catch though (I haven't been following passkey work much)?
Every site knows users will absolutely forget passwords, so having a reset mechanism is a must. But I can imagine many sites thinking nobody will forget a passkey since it doesn't need to be remembered, thus hardcoding it in ways that make reset impractical.
For Passkeys, going through the recovery flow may indicate two possible things: 1) that you lost the Passkey and going through the recovery to replace it with a new one; or 2) that you merely want to log in on a different device where the original Passkey is not available.
This, of course, is going to work in practice - much worse designs had worked after all. But it's all logically unsound, and not really addressed by standard bodies or large implementers. It's not a big deal and there are ways to make it logical - but because it's not addressed it's gonna be a mess.
Sounds like email based login with extra steps then.
Even banking with device bound credentials is a hassle everytime you switch devices or you picked up the wrong phone.
I have some apps using login with Microsoft because users are logged in anyway in a corporate environment and it is practical to provide SSO. Here accounts might also be closed and access needs to withdrawn. Practical to do so centrally.
But for cleverness I still believe nothing beats a secret in your head. Quick, fast, secure. Oauth is a mess, so I doubt passwords will be outdated anytime soon.
If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”.
If you lose your phone and delete your existing login cookies you don’t get access again. If email or sms is the recovery method, you might not be able to login on a new device or IP without your phone. But if email was the recovery method it’s just the same as sms 2FA which is reasonably secure and fail safe for the average person because there is a trusted third party in the loop…
That's an uncharitable interpretation. A more charitable way to say this is:
You can choose between secure/uncloneable and less secure but more flexible. Passkeys let you make the choice and don't dictate it for you. Choose whatever better suits your use case.
EDIT: I've written a short post to clarify a few misconceptions:
https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
If it's the user, how do I as a user choose right now?
If it's the service implementing passkeys, why wouldn't they force a solution that's easier for them (less testing/less support/less maintenance, by forcing attestation to a specific list of providers), instead of letting users have an option?
Passkeys are an awesome solution to a difficult problem. But they are one bitflip away from eliminating user choice. Fix that problem, and I think folks here will jump on it in a hearbeat.
When you lose your device and reinstall the app. It asks you if you are recovering or a new user. If you select recovering your key. We will generate a new pub/private recovery key. Remember we are assuming you lost your phone. The app will then ask you to enter the phone number of the 4 people that will vouch for you. When you select those 4 people, a call is initiated to them where you must read off a code that the restoration server gave to you on your new device, they will then select that they are vouching for you. The idea is that these are your friends or people you trust. You have to convince them. Not just automated think. At that point their phone will send the pass key fragments to you (encrypted using your new pub key). When enough people give you the info you need. Your phone will decrypt with your recovery private key and then recover the backup private key.
It will then request the encrypted backup from the server. The server will provide it with the encrypted back at which point it will use the recovered private key to decrypt the backup and recover all pass keys.
Well, then this culture needs to be condemned strongly.
Perfect security leaves no room for user friendliness. The most secure system allows no users to use it. Only by reducing security do you gain user friendliness. The most user friendly (as in, triviality of use) system requires no security.
The art comes in when trying to create more usability whilst giving up less security, of course.
Passkeys are more secure than passwords. Thus, it's only natural they are less user friendly. If you don't "like" that, then stick to passwords. There's nothing to condemn, however.
The art side is where opinion lies.
But the passkey crowd is overtly aiming at eliminating passwords.
So for most people on HN (who also probably won't be successfully phished) they offer only new problems, yet if implemented and used widely they're probably a net positive.
It's a bit like the Covid rules. I am more than capable of avoiding other humans without new laws, but "normal" people seemed to need a lot of coercion.
Personally I'll give it a few years and see how passkeys pan out before I switch (if I get the choice).
We are screwed.
Passkeys and YubiKeys are different things. But generally it is recommemded to have a second YubiKey in a safe place and to register at least two keys on every service. Unfortunatly the implementations for using hardware keys are often pretty bad and require to activate alternate MFA which defeats the purpore of having a hardware token in the first place.
For backing up a yubikey. If you manage it you get a massive bugbounty. The whole purpose of a yubikey is to not be able to read the embedded key. Yubikey guarantees physical posession of the key itself if you can prove knowledge of the key within.
For passkeys: Only the authentication/creation process is specified. How passkeys are stored, shared, backedup etc is totally up to the implementing party. So Google and Apple will synchronize the keys using their existing password infrastructure.
In the end the only difference to passwords is: - It is always randomly generated - You can have multiple passkeys per service - The application managing passkey is required to verify that passkeys are only transmitted to the service they were created for (making them phishing resistant)
Passkeys are basically the point between passwords and hardware tokems like the yubikey. Safer than passwords and less safe than a yubikey but easily usabale by everyone.
Apparently Google's implementation stores an encrypted backup of the passkeys in your Google account [1]:
> A single passkey identifies a particular user account on some online service. A user has different passkeys for different services. The user's operating systems, or software similar to today's password managers, provide user-friendly management of passkeys. From the user's point of view, using passkeys is very similar to using saved passwords, but with significantly better security.
[...]
> In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup.
> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys. Note, that restoring passkeys on a new device requires both being signed in to the Google Account and an existing device's screen lock.
So, if you use Google to store passwords or passkeys, it would be a good idea to save backup codes for your Google account somewhere safe. (Like you should do anyway.)
[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...
Alternatively, if you're locked out of your Google account, these passkeys are also dead as the encryption keys are bound to the account. And passkey reset through email for instance would also probably out of question if it was your primary email account...
People should think long and hard about what services they assign passkeys with their Google accounts, it's a lot more binding than plain password or standard 2FA was.
Ideally, websites will support multiple passkeys per account. I think having both Google and Apple passkeys would be sufficient since I think I would be unlikely to be locked out of both.
Apparently Tailscale doesn't have multiple passkeys per account, but they recommend creating a backup admin account, and you could use a different kind of passkey for it.
I lost access to at least one account as a result and had to submit identity documents to recover the account.
I now make sure I have backup codes stored somewhere.
Interestingly, in the past couple of weeks, Google Authenticator can now back up to your Google account.
Was bought by Twilio, but still rocking.
I love the plugin for raycast.app for it
You set a master password and can login back with your phone number/master password in any device
Much easier to not fuck up 2FA with it when changing phones
Practically if the passkeys are stored in your iCloud Keychain, they are automatically synced across your Apple devices and the recovery mechanism is the recovery mechanism for iCloud.
Similar consideration for Google/Chrome and other password managers.
We wrote a relatively long blogpost about this + implementation and threat modeling considerations in case it's interesting: https://www.slashid.dev/blog/passkeys-security-implementatio...
Ditto for Yubikeys (which can be added as a passkey), you need more than one so if you lose it you can still access.
Every time you sign up for something you have to perform a complex rite: 1) sign up or add a portable authenticator (Yubikey or software token in something cross-platform like 1Password); and 2) run around the house, grabbing up all the different devices you have that aren't transparently synchronizing (so, something from Apple, something from Microsoft, something from Google, and don't forget that backup Yubikey you have in a safe too) and enrolling them on the same website.
I'm baffled how this obvious issue is not just unsolved at the start, but is not even addressed by any user-facing marketing materials. Every single demo stops at enrolling one single device, period. The word is that vendors will do you good magically letting you access that passkey from everywhere - and they missed that huge fucking asterisk after "everywhere". Because they won't - Google, Apple, Microsoft, 1Password, and probably everyone else have no incentive to do so, they want to stay in their respective ecosystems and no chance in hell they're doing any cross-platform interop with anything that not theirs.
Apple, Google and Microsoft would love this model. People suddenly swayed to stay within their ecosystem to log in to websites. "Oh shit can't login from here, gotta start Microsoft Edge to access this website" sounds exactly like what those corporations fancy.
Yubico and 1Password don't have a beef with it - someone wants a portable authenticator, they're gonna pay for it - it's not like there are many options anyway.
And only me - as an end user - is not exactly happy. Even though I do want to get rid of passwords and replace them with keypairs.
---
Add: This said, if you're at some conference attending a talk about Passkeys... Please consider raising this point and explicitly not letting it slide with the usual waiver of "nothing to worry about, $VendorName will sync the Passkeys across your devices". Raising awareness is important.
Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own? I don't. Do you think it is realistically (and not theoretically) possible to implement a new solution that would provide the security properties as good as sum of all individual fragmented options? I'm not sure. And even if someone spends enormous resources and makes it all real, there's still that issue of a Yubikey in a safe.
Sorry, but if N implementations require that inconvenient process I've explicitly outlined, having N+1 option still won't fix it.
And it's the standard's fault, not "the implementations aren't there yet". The standard had not addressed this, even though it's pretty much obvious this is going to be an issue on the very first day someone who isn't an ideal customer (100% lifetime loyal to one single vendor) uses Passkeys.
When I'm setting up SSH keys on a host I can either give it a list of all my keys, or CA certificate to trust, but I don't have to grab all the individual devices. Here, I must.
Attestation is another potential issue, but it's not a problem today.
Yes, given that I use my open source Solo 2 to log in to any Passkeys-supporting site already. It's not about whether they will support it. It's an open standard, you can use whatever you want.
Three arguments:
1. Redundancy and failover. Without backups, "if I'll lose access to that account" is not even a question, "when" is. Unless you have a second Solo 2 in your safe - some day, you will lose that account. You may be able to recover it, of course, but that's another story (a story of security properties of your account and ability to access it without having credentials).
2. Availability. If some device (e.g. an iPhone) won't support your Solo 2 (e.g. you don't happen to carry that Lightning-to-USB-type-A adapter) - you don't have access anymore, even if you have your key with you.
3. Convenience. You may log in only with your single Solo 2 key, but you'll probably want to be able to log in to your websites from your phone, without having to walk to your desk (even if for a few feet) to grab the physical key for every single new website.
I can think of a scenarios where you won't hit those limitations. The problem is, they're not some weird ass case for silly nerds - they're real situations that are gonna happen to your average Joe (but he, unlike nerds, won't really think about those until they happen).
It's an open standard that everyone are building siloed systems on. It's exactly as you have said - I'm not locked in to any single company, but if I have devices or programs from multiple companies that bundle different implementations and don't let others in, I don't have any means to make them interoperate.
This could change someday. Fortunately, there is no fundamental design issue that prevents it. But I'm talking about what exists today and how the standard is bad for not even trying to address it, despite this being a very obvious issue.
Most of the sites I worry about aren't commercial in nature. They aren't getting "sales".
But I'm not going to complain to any company-run websites about anything anyway, because the odds are overwhelming that they simply don't give a shit. That's been my experience over years, anyway.
Small human-run websites are a different matter. They tend to care quite a bit. But they're also the least likely to stop accepting passwords.
If only companies would've known this... Can you please start by explaining this to the infamously ass-backwards banking industry? ;)
Companies aren't willing to lose customers at scale, but they aren't doing anything for the customers if they won't lose them anyway. For most services, most customers except for some diehard ideologists would just bend over and begrudgingly go with the attested option. And a company won't bother using engineer's time if it's only a few people.
So minimum-value random internet blog is probably not going to require attestation - except if they have no idea about it whatsoever and will just use some off-the-shelf solution and enable it because it sounds more secure, without realizing the issue. Anything that has significant value will do as they please and customers may voice some unhappiness, but will obey. And as long as voiced unhappiness is minor (there are always other issues) it will be ignored as not something worth spending resources on (even understanding the issue requires some valuable time).
This is a bit like worrying that sites will block 1password and only allow LastPass. Why would they, even if they could?
With passkeys, if someone steals my physical device, then they have full access. That seems strictly worse to me. It's just beyond me how there's a plausible claim that moving to a single factor is better than two factor authentication, except that it gives Google and Apple more control over the internet by allowing them to lock people even more heavily into proprietary OS ecosystems.
Unless they also have access to your fingerprints, face or something to that effect, they do not have access to your device. Every time I create a passkey, I am required by the device to provide authentication. I'm not sure if this is a hard requirement because all my devices have PINs, passwords and fingerprints but I assume that your device needs to have some form of security for passkeys to even work. In 1Password's demo, I had to authorise every individual login call with my system PIN on Windows and fingerprint on Android
If you don't use biometrics and use a pin/password and the attacker has access to both your device and this information, then there is no difference to how it currently operates because the attacker already has all the info necessary to take over your accounts. If an attacker has your device AND access to biometrics, then you have bigger problems
The "traditional" security model of a password vault on a computer and a 2FA token on a smartphone requires both devices to be compromised, Theft of either device is pointless, and even the theft of both is often insufficient as the password vault usually requires a passphrase.
edit: after some digging (which was a lot more involved than it should have been) it seems like the current state is:
There is free software to set and manage a pin for a yubikey on Linux. Firefox historically didn't support yubikeys with a pin, but it seems like that was recently merged. Yubikeys still have a 25 site limit per device, and no sync across devices. As long as sites let you register multiple yubikeys as a backup, and support pins, then it's a reasonable workflow. I'm not convinced it's better than passwords + a yubikey for 2fa, but it seems like in practice it's probably not worse either. It still feels like, even if security is a motivator here, there's a lot of opportunity for Google, Apple, and MS to conveniently and "accidentally" cut free software users out of being able to access a lot of the internet with the move to passkeys, and I remain skeptical.
1. Unlock my device with a pin/fingerprint/face unlock
2. Unlock 1Password with this same mechanism
3. Unlock access to a passkey supported website/app using 1Password which will store my passkey for that website/app
Through all of this, an attacker would have to have access to my device and my device authentication mechanism for gaining access which still counts as 2 factor
> Unless they also have access to your fingerprints, face or something to that effect
Fingerprint scanners are a lot better than they used to be (back when they could be beaten by a gummy bear), but what about a picture of your face?
Biometrics should be thought of as passwords that can't be changed. Use them for convenience, not security.
Apple protects passkeys via FaceID or TouchID. If you're satisfied with biometrics as a 2nd factor, then there is no regression in your scenario.
Also that then leads to the situation that your passkeys are completely locked inside Apples ecosystem! (Or Googles, or Microsoft, or whatever...)
Do you know of any which currently only allow one passkey?
I'm not sure if it's true anymore, but Twitter for years only supported a single WebAuthn token.
https://aws.amazon.com/blogs/security/you-can-now-assign-mul...
Amazon’s shopping site also lets you set up multiple devices, but I’m not sure when they added that.
It sounds to me like passkeys are a simpler and more secure approach that apply within the existing context that requires unique complex passwords for every account.
In terms of solving those issues, a 1Password account configured on multiple devices with a secured accessible backup of the emergency toolkit has been a robust solution in my experience
Passkeys, not so much. They are opaque blobs which are never supposed to leave the manager.
It does not to me. It requires complicated cryptography/tools. Passwords are just directly usable information that are much easier to reason about and work with. I can ask a question about passwords and I can figure out the answer or soltuion for myself without looking up any standards, implementation details of someone elses software or wading through heaps of marketing bullshit.
Say I just want to temporarily share access to an account with someone? How? I know how with passwords. Give it out, change it later to revoke access.
Say I want to export access to just select few accounts (and not the rest) I'll be needing when doing X away from my devices to limit the possiblility of forced compromise. I know how with passwords.
How does backup and recovery work? Can I do it fully offline without invloving any third parties? Will I need anything other than a piece of paper? I know with passwords without looking anything up.
If it's anything, it's not simple compared to passwords. It may be better in a few aspects (or not) but it certainly is not simpler to think about.
The difference between password manager with unique passwords per account and this complicated crypto-thing seems very miniscule. You're either sharing a shared secret or you're proving a possession of a unique secret key per service.
The only difference is how things need to be handled if the service itself is hacked. If it only stores pubkeys, the user's secret keys can still be used for authentication. The problem with this thinking is that attacker may have swapped user's key on the server with his own, hijacking the account anyway. In any case this doesn't lead to compromise of any other services used by the user.
Also, FIDO2 can be used to force you to have to use a device you don't trully own for authentication, taking away your software freedom. Passwords can't be abused like this.
- the passkey is never transmitted anywhere when logging in, eliminating the largest attack vectors for stealing passwords
- you can no longer manually type the passkey in on random devices that don't have your password manager on it
it's basically a really really long password you don't know with some added security guarantees.
if you are not already doing this, then it requires adaptation to a world where you do not know your passwords and they are stored in a vault. this does mean ironing out account recovery for the account the vault is associated with. passkeys don't change that, though.
This answers a question about them that I've been unable to find a clear answer for anywhere. My passwords are all randomly generated and stored in my password manager. It's cumbersome to type them in on some device without my password manager and I don't do it often, but at least I have the option!
I really don't like the idea that my passwords/passkeys are some thing to just be abstracted away to the point that I have no idea where they are or how to access them manually if needed.
The biggest difference is that websites seem to trust a passkey as both a password and a 2FA token at the same time. So security-wise it essentially means giving up 2FA altogether, as passkeys are about as secure as a password manager.
So for anyone with a password manager and 2FA tokens, passkeys are a downgrade.
Yubikeys require a PIN, and the key is wiped if you enter it wrong ten times. Nobody stops you from making a hardware key that requires a long password to access it. You can do whatever you want, the standard doesn't care how you want to secure your keys. The standard just asks for a key at enrollment and then asks you to sign something with that key at signup.
Anything after that is up to you and your choice of device.
EDIT: I've written a short post to clarify a few misconceptions:
https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
This is a huge problem, though. My password manager has no online component, and only runs on my phone. On purpose.
When I use it, the password manager shows me the password that I need, and I type it in manually.
I could change to a different method, but then I lose a lot of flexibility. I can no longer log into things from machines other than my own.
Things like Yubikey address some of this, but then I can no longer log into machines unless I have sufficient physical access to plug the key in.
To be clear, I'm not arguing that any of this means passkeys aren't desirable, but I am saying this to point out that passkeys are not functionally equivalent to passwords, and passkeys do restrict some kinds of use.
Obviously, there are some necessary assumptions made, about security of the passkey implementation, DNS security and so on.
>if you are not already doing this, then it requires adaptation What doesn't?
>ironing out account recovery for the account the vault is associated with Agreed. This is currently the weakest point in web security in general.
I'd also like to mention (for everyone else reading this) that a unique set of credentials is generated per account, so this cannot be used to track you. Also, it's an open standard and open imolementations exist. It is bot reliant on google/yubico/"big tech". They're pushing it because it works.
Basically you need to trust more vendors of security solutions than before, isn't it?
Plus you cannot access your accounts from any random device without an intricate security setup that eats at your time and messes with the device.
As in you cannot borrow your friend's laptop for 5 min to check your email any more. You have to set up your keys on said laptop and then remove them, which makes it a 2 hour affair?
>Basically you need to trust more vendors of security solutions than before
Yes and no. You may have to trust the vendor of your hardware key, or you can get one that has open source firmware, like NitroKey.
Regarding the number of trusted parties - it depends. To have a account that use passwords, you must trust them to handle your password well. You can mitigate this trust need somewhat by using a password manager and strictly using unique passwords (and ideally usernames and emails too!), but this now requires trust in your password manager. Again, OSS solutions like BitWarden, KeePass and pass make this less of an issue. My point is, if you are handleing your passwords well (ie you are using a password manager), you are not really required to trust more parties, only change which ones. Furthermore, WebAuthn is stabdardized, so unlike with password managers, there's less room for "creative" programmers to make mistakes (like lastpass did).
Regarding DNS security,
I meant that highjacking a company's domain, be it trough compromising their account with their registrar or by non-validated or even non-existant DNSSEC can enable attacks. This is true of other forms of identifocatin though. I just want to be fair and not oversell this tech as a silver bullet. If all things are done right however (like they must be with other forms of id.), this does significantly increase security.
>borrow your friend's laptop for 5 min to check your email any more
In general, no. Assuming they run a reasonably recent version of Chrome and Windows/Linux/Android* (I don't have apple so idk), it will work driverlessly.
You may be surprised to know this, but it's fundamentally a fairly old technology at this point. Hardware keys have been supported in some capacity by systems for over 10 years now, and WebAuthn essentially just standardised what was already there. It was a fairly easy adjustment. At this point in time, I don't know of any hardware key being sold that does not support this nor any common OS (again, besides Apple stuff, they should supported but I cannot test it.)
*Ah, yes, Android is a wierd one. Technically it's not yet in android, but it's been in the Google Play services for years now. But thechnically, there are android devices without those (like mine).
What will work driverlessly? The generating of new keys that still will take an hour?
Also excuse me, but did you just say Chrome? I should send Google my browsing so I can use passkeys?
Edit: forgot to mention their AI bans with no appeal process. Do you really want your sole login means in there?
WebAuthn. So, registration and authentization. I'm not exactly sure if which standard deals with changing PIN, but it worked everywhere I tried it out of the box.
>OMG did you say CHROME??!!!
Yes, how dare I... It was an example. I don't use Chrome either, but not many people do use other stuff, so that's why I mentioned Chrome specifically.
Currently, the support is best in Chrome and some other Chromium-based browsers. I personally tried Brave, which worked flawlessly everywhere. Firefox (which I personally use) works with standard WebAuthn, but some big players (Google) seem to have older implementations predating the standard, so it doesn't work with some clients (Firefox) yet. I've watched a conference some time ago where they said they're working on it™.
If you want to know how exactly it stuff works, Mozilla has a nice and easy to comprehend description on their developer site. It's one search away (in your preffered search engine).
>The generating of new keys that still will take an hour?
Are you trolling? No. Also, only nonces are generated for each new _credential_, so you don't need to store so much data on the key. You should be more worried about how long it will take to do the authentization exchange, which takes under a second from my experience.
Please just read the Mozilla website.
I'm not talking about the CPU time needed to generate the bits...
Aren't the keys device specific so you need to generate new keys on a new device? It's being touted as a security feature. I'm guesstimating that at 1 hour of the user clicking through various interfaces.
But anyway, my concern is passkeys are adding too many dependencies on devices/providers. Giving me a list of possible devices/providers does not address my concern.
If you're worried about making a brand new passkey because you're logging in from scratch, that means you need some other kind of authentication to start the process. And that's solidly outside the scope of passkeys, so it's hard to say how difficult it would be. (But if you have an alternate login method, a good system wouldn't force you to make a temporary passkey, it would just let you check your email and log out.) (Also it shouldn't take more than a minute to do key creation/deletion in any reasonable implementation.)
Yes, the keys are device specific. This is a feature and the reason why it's more secure. If it could be backed up (exfiltrated), it would not protect you in case your device is compromised, which is one of the design goals. You could probably work around this by using an emulated key (which is what Apple does I think?), but that would obviously eliminate this key security feature.
> I'm guesstimating that at 1 hour of the user clicking through various interfaces.
I see, sorry, I missunderstood.
Again, it's just like changing a password or a TOTP secret. Unfortunatelly, no standard can fix bad UX design, but I sympathize. Silver lining is that even cheaper hardware keys are built like a tank, and software is... well... software.
> my concern is passkeys are adding too many dependencies on devices/providers.
Which is reasonable. The question is, is the dependency worth the security benefit? It seems many major device makers/service providers think so.
> Giving me a list of possible devices/providers does not address my concern.
Well, I can't do anything about that, can I? Nor can anyone else.
I think this is, again, a question of priority. TLS is now essentially a dependency for using the web at large, but it wasn't in the 90s. I'm sure that is of concearn to some people, but most agree it's a net benefit.
The thing is, I was mentioning DNSSEC as a "full disclosure". Any attack enabled by non-validated DNSSEC on passkey applies to any other form of verification too. I just wanted to make sure I'm not overselling the technology, it's not a silver bullet, but it's orders of magnitude better than anything else.
There is no value to DNSSEC, which is why virtually nobody seriously uses it.
You get a new device, create new passkeys, and re-enroll into the online service again.
> And, for Yubikey, how do you backup?
See above.
> Do you need multiple Yubikeys?
Yes.
> Do you need to manually make a copy of every keys? How do you know if the copy is synced with the main one?
Apple's and Google's solutions both sync the passkeys via their cloud services. You cannot sync passkeys to Yubikeys, AFAIK.
Apple does some additional trickery to synchronize credentials between devices, but they get away with this because their devices have contained dedicated silicon for sensitive data management for years[1]. They have some user-facing documentation on how their passkey implementation is synchronized between devices without any secret disclosure here[2][3].
[1]: https://support.apple.com/guide/security/secure-enclave-sec5...
[2]: https://support.apple.com/en-us/HT213305
[3]: https://support.apple.com/guide/security/keychain-data-prote...
No one claimed it's a hardware security token, but the private keys are stored in iCloud Keychain, which is end-to-end encrypted. Apple cannot access your private keys even if iCloud is compromised by an external attacker or employee.
If you're curious about the security engineering, you should watch the "Synchronizing secrets" part of this Black Hat talk from 2016: https://youtu.be/BLGFriOKz6U?t=1353 or you should read the "Synchronization security" section of the "About the security of passkeys" support doc: https://support.apple.com/en-us/HT213305
I does not make sense to use a proprietary internet connected application on your machine and worry that that the servers might be nefarious.
Apple has no access to keychain data: https://support.apple.com/en-us/HT213305
Which again, seems like the worst of both worlds.
You login to iCloud which gives your device write access to iCloud storage. The device creates a private key inside the TPM, and uploads the public key. When you add a new device, one of your existing devices has to use its hardware key to sign your new devices key. It also must be signed by a second key derived from your iCloud password (so you). Apple doesn't go into the details on this, but I believe the originating TPM also signs the key with a chain of trust that goes back to Apple itself.
The keychain is encrypted locally and exported to iCloud. The key used to encrypt the keychain is also encrypted using the public keys of all trusted device keys in iCloud that have both a signature from another trusted device and from you.
As a user you can also just open up Keychain Access on a Mac and ask it to generate a CSV export of your entire iCloud keychain - which is how you would go about migrating to another password manager.
Apple just extended their Credential Provider API such that passkeys can now be synced using external providers, meaning password manager apps can save and offer passkeys on iOS, iPadOS, and macOS. So you can choose to sync your passkeys with whatever your favorite password manager is.
See this page: https://developer.apple.com/passkeys/
And Google announced a similar API a month or two ago.
See the section titled "Passkey support for Android apps" on this page: https://developers.google.com/identity/passkeys/supported-en...
For example in the case of email, you generaly dont worry about google reading your email but we should definitely be concerned if gmail allows send & recieve from only few domains or providers it chooses.
Does that service also have to trust the OS developers? Correct me if I'm wrong, but I'm under the impression that services can decide whose passkey implementations to trust.
Seems like that should be up to the user, not the service.
Of course they can, just not from the stored cloud data. But that's just software. One little patch and your cloud sync is without E2E.
[1]: https://support.apple.com/guide/security/escrow-security-for...
This is a personal belief based on chatting with Apple and Google employees. You don't have to agree.
Compared to using, say, KeepassXC with a unique, secure password per vault. Now you can sync on iCloud or google drive, but neither Google nor Apple can decrypt the vault; the keepassXC maintainers presumably could make a malicious update (which you'd still have to accept, since the updates aren't forced on you), but that would also affect the security of everyone using KeepassXC (and potentially be much more harmful to the economy and society as a whole than the government is willing to accept in order to get intel on an individual person of interest)
It's a know bug, but the fact that it still exists really shows how much the devs care about making it a really rock solid alternative. I've never had this issue with Google passwords, 1password or any other provider.
I've already been doing manual backups. In addition, there is a feature to make a copy of the database before writing that I've just turned on. And the "Use alternative saving method -> Directly write to database file (dangerous)" option is supposed to prevent this issue from happening with cloud storage.
I wasn't in any way arguing KeepassXC is a layperson-friendly way to manage authentication credentials, just that it gives you the most security from the big identity providers (Apple, Google) selling you out for political or selfish reasons.
Of course, there's probably only so much I can do here. Apple could presumable ship an update to their OS that allows them to access a user's database while it's unlocked, or to keylog the master password.
A yubikey might be the only thing that can really protect you here.
Have you chatted with the Apple and Google CEOs? How about with the future Apple and Google CEOs?
Please, educate me, those who upvoted it.
The nice thing about this is it means you can invite anyone into your network without requiring them to have a Google/Apple/Github account. They just need a phone. It also means you can be much more confident inviting these people because they are unlikely to get phished due to a crappy password.
One of the common complaints in HN comments about Tailscale is they don't want to trust Google/Apple/Github/etc for various reasons. This removes that need.
To nitpick, you can't use just tailscale, you need to use tailscale and some authentication provider.
I've seen a blog post describing a very elementary better way of storing IP addresses upvoted and praised.
I've seen people agree and fawn over the idea they were using a flat JSON file everywhere initially.
Then they somehow discovered a 20 year old DB, and some people treat it like the second coming of Christ.
None of this is to insult Tailscale, or their works, or their blogs. People love it and it's obviously a nice product.
The fandom here around them and what gets upvoted and praised just seems cultlike at times.
(Or, maybe passkeys are bad, I don't know, but we need to have a conversation in order to find a better solution.)
I sure hope not.
I am 100% in favor of alternative solutions for those who struggle with passwords, but I also want the option to continue to use passwords.
https://github.com/bulwarkid/virtual-fido/
https://github.com/keepassxreboot/keepassxc/pull/8825
https://github.com/psanford/tpm-fido
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/fido2-c...
Slightly off topic: did Apple just make it super easy for law enforcement to unlock your phone & passkeys as part of iOS 17?
> ”Apple ID. Securely sign in to your iPhone using a nearby device or any email address or phone number listed in your account.”
If you don’t have your phone as your second factor or can’t use phone today to reset password, then I don’t expect you’ll be able to login via that mechanism.
Not entirely sure how to prevent recovery using a phone number. I wonder if this means setting up a recovery key instead? Been considering doing this anyway.
The only way I'll get passkey logins for my work account is if Microsoft force it as a 2FA method for enterprise. I won't hold my breath.
Doesn't that mean they know your username and password? How does that happen so easily.
This became so tiresome that I disabled MFA. Here's a hot take: if your MFA solution fatigues people to the point they disable MFA, you have a problem.
Also, I'm wondering if the OP might be referring to passwordless "Approve this login request" notifications rather than plain old MFA, where someone just needs to enter your email address and hope you approve the login request. Not sure if MS does this, but I know other apps that do.
This solves the problem of accepting the wrong login by mistake
> Fortunately I'm attuned enough to decline them.
There is only something to decline if they know your password.
Regarding MFA-fatigue, this is mitigated by asking the user to enter the same number into Authenticator that is displayed on the login screen. So that takes away the chance of accidentally approving an MFA prompt.
I get these pretty frequently on my work machines as I reuse my passwords and they have already leaked. At least that was my assumption.
I don't think they're actually available on AzureAD. That thing tends to lag like crazy in actual security features. FIDO support is relatively newish. IIRC it was generally available around the end of 2022. Only recently, you no longer have to register a phone number for password reset (which is different from login, mind (SSPR)).
> they enable the tried and tested and ultra secure method of SMS based 2FA with a password
This isn't actually that much worse than the MS recommended way of using their crappy authenticator. They even allow passwordless sign-in with that thing! The prompt doesn't tell you anything useful apart from "login with <account>?". Now, at least, they prompt you for a number you see on screen. It doesn't help with phishing, but at least you know the request comes from what you're doing, not someone else, since it also tended to drop any request if another one was pending.
I assume Microsoft felt the need to dumb this down so it's easier to just approve it with a click of a button, then after they realized this is bad (that pretty much anyone with a bit of security experience predicted) they now changed this to "input code on second device", instead of just reverting to the default behavior.
Why?
Passwords are outdated in the same way key locks ok doors are outdated and all they did is have someone else manage federated authentication.
I am so exhausted at screaming into the void over this topic. You all do whatever crap you want just know that whatever you do, if it isn't at least 2FA it is as shitty as passwords. New and secure just means threar actors haven't adopted to it yet. You know the nice thing about old shitty security? There is decades of work and lessons learned on how to make it work nice.
Keep your silverbulletd and reinvented wheels and give me knowledge based factor (password,passphrase,pattern,etc...) and a completley separate NGC like FIDO2 and credential recovery options that don't involve email or yet another set of credentials. Now, that hard security implementation will actually keep me secure but these lazy bullshit security anti-patterns force me to depend on some bullshit 3rd party vendor, compromise on my privacy and still have me be one step away from total pwnage.
All tailscale has convinced me is that they think passing the buck to someone else or getting in on a hype is in the best interest of their users as opposed to investing in layered and reliable security.
I do see the appeal for passkeys but I think short term it's probably going to be a support nightmare. The messaging around this is also quite confusing for example. Way too technical to explain to normal users what this even is or how it works and what they need to do.
Also, as others have pointed out, while this is more secure than relying on passwords (given users can't be relied upon to follow most of the sane recommendations for these), it doesn't remove the need for multi factor authentication. A lot of passkey implementations basically rely on some variation of biometrics. Those aren't exactly hacker proof. And of course phones get stolen and lost all the time. Which creates the need for some recovery mechanism as well as a way to revoke passkeys.
Can we please stop the bandwagon for a moment and inquire about the downsides of Passkey?
My worry is the actual implementation, where platforms might lock you into their cloud as the sole provider simply by not implementing interoperability...
This isn't that uncommon. Things like disk encryption also do this (e.g. bitlocker)
So ... a password?
Also in this scenario you've been robbed. It's quite possible that either they took your printed out passkey also since it was in your wallet, or you're not at home where you can get the pass key from your file cabinet or safe.
Hey it's asymmetric crypto that generates a key/cert pair for every site you register at. Neat. Why not just say so?
I'm getting shades of "passwords are so insecure, passphrases are secure" here.
Sites of course could use the device public key extension of the WebAuthn protocol, to rely on more than a private key copied intransparently between devices, but I wonder, who will even know about it and actually use it. Google has stated they support the extension, but I cannot find a statement by Apple. A question whether DevPubKey is supported by Apple is unanswered on the Apple Developer Forums.
Now if only they supported this for setting up the entire account too, as opposed to additional users only. I hope that's coming.
If I understood the docs correctly, it looks like they allow signing up with custom oidc provider.
May be worth looking into it if your only concern with their service is delegating access via big tech.
It installed flawlessly on all of my machines (Linux and Mac), and now I can route to all of them wherever I am. It configures DNS correctly, it routes traffic correctly, and all of my internal machines at my house are routable when I'm out in a coffee shop or library or hotels. It's been more than a year and it's operated flawlessly, never needing maintenance or restarting, it survives connection resets and is completly robust. I just love it.
Disclaimer: No affiliation other than being a happy customer.
(On-topic, I would prefer them to to take my damn password please.)
I've used iCloud, Google Chrome, Lastpass, and 1password, and they all break consistently in a few scenarios. Three that come to mind are:
- SSO or other systems where multiple logins are linked to the same account on different host names. The password manager will require you to essentially create a separate entry for the new site that becomes disconnected from the original.
- Having multiple logins for the same site. This breaks especially with services that use a multi-stage login, but in general it breaks frequently. If you have kids or parents whose accounts you manage, password managers will invariably ask to update the wrong password, or attempt to auto-fill the wrong password regularly.
- Sites that request you enter the old password at the same time as you enter your new password for verification when changing a password. Password managers can't figure this out, and as a result whenever I have a password manager generate a new credential, I also make sure to copy it to a temporary location until I've verified that it was saved. Typically, because you entered the old password on the password change page, that save doesn't go through.
BitWarden has its problems but generally I find the experience pretty good - indeed far superior to the other services you mentioned. The ability to use “secure notes” and the convenient way that has been implemented in BW has allowed me to be fine in all the scenarios you’re mentioning.
Of course, you’re right, you still have to copy the password in somewhere, but ultimately I feel like that’s a lower threat if properly handled than what I used to do (shitty insecure passwords).
The other thing is I barely ever use the browser extension for the password manager. All of the browser extensions I’ve tried other than BitWarden have been janky and even that’s only ok. Still, try BW I like it way better than lastpass and 1password.
Does anyone know of a good resource / tutorial / example / best practices on building login/signup systems in web apps with Passkeys?
Also, what's browser support like? I'd love for some simple system to just replace PassportJS and all those confusing systems.
While they can be designed to have the secrets cloud synced (just lile how you can sync your ssh private keys), there's nothing preventing them from being implemented in other ways, like having them backed by a third party password manager or even a pyhsical token like a yubikey.
Of course, this depends on the software (OS, browsers) actually respecting and supporting that interoperability. But that's not really a limitation of the underlying tech.
Third party authentication providers are a single point of failure, and usually they themselves require a password to authenticate you anyway.
If your gmail password is hacked, then effectively all your accounts on websites that use Google auth are also hacked.
Passkeys appear to also be handled by central services? At least that appears to be the case with Apple, according to the link in the post:
https://developer.apple.com/passkeys/
I personally think having a browser-managed "private key" (the same kind used for ssh auth) would be better, but now as a user you have to manage the multiple private keys you have associated with an account; a totally confusing concept for the average user.
I don't think it is true that passkeys require a third party, but can someone else confirm?
What about devices that have no camera?
So now we need hardware and software to generate passwords we don't even know.
I don’t trust any of those, and it’s weird that anyone does.
Plenty of use cases where performance doesn't really matter, and getting it working is orders of magnitude easier than wireguard. I've been using it for about a year now, and I rarely notice it even exists.
I suppose for an org using Microsoft AzureAD via OIDIc - passkey auth would be on the Microsoft side of the fence?
1Password does not support PassKeys.
They have announced the intention to, but outside of beta releases it's not there yet.
Yay.
> In marketing material, the terms passkey or Passkeys are preferred over related terms such as FIDO or WebAuthn, because they are less likely to cause confusion.
Yeah. Nowhere does it say what it actually is or how it's related to the other standards. Not confusing at all.
This sentence doesn't quite make grammatical sense to me. Is there a typo or two here, or am I missing something?
There's a lot going on in there!
> Passkeys allow you to go passwordless: rather than a password that can still be phished, you get a strong credential that syncs securely across your devices, using your chosen password/passkey manager.
OR
> Passkeys allow you to go passwordless — rather than a password that can still be phished, you get a strong credential that syncs securely across your devices, using your chosen password/passkey manager.