Does this basically means there is one "master password"?
Passkeys: The beginning of the end of the password
181–190 of 1001 posts
Re: Passkeys: The beginning of the end of the password
#182Earlier quoted context omitted.
You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just…
> the scenario where your password manager is running on the same device as the one where the user is performing the login Android will provide an API for that scenario (i.e. on-device third-party authenticators) in the near future [1]. Hopefully, iOS will do the same. [1] https://developers.google.com/identity/passkeys/supported-en...
Yes, I'm waiting patiently in the wings. Sadly when I asked Apple's Passkey team about supporting this, they said it wasn't on the roadmap (though they carefully didn't say never, it still doesn't instill much hope). Once this missing piece becomes a required part of the standard, I'll stop holding my breath and get super excited about passkeys.
Re: Passkeys: The beginning of the end of the password
#183WebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards. At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures. I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requ…
My cynical assessment of Passkeys is: If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere. This isn’t a theoretical risk. You’ll see lots of people complain about this online. Also, Passkey providers now get sweet sweet metadata about your accounts around the web. But yeah, authn is hard to do right. Equally, asking your users to fall into $BIG_PROVIDER’s arms seems wrong. My pe…
Agreed. This whole thing seems incredibly user hostile. At the very least, there should be severe legal recourse (criminal liability and also large, material-to-earnings statutory damages) if one of these providers intentionally locks you out of a third-party account.
That third party account should be treated like your personal property, and them denying you access to it should be treated like their CEO breaking into your house and stealing your stuff.
If they don't want to take on the liability, and it kills the passkey spec, that's fine with me. The current system avoids the issue by allowing people to store credentials in a decentralized way.
Re: Passkeys: The beginning of the end of the password
#184The linked security blog post[1] has a lot more of the technical details and can clear up some of the questions/confusion that people have added in the comments. [1] https://security.googleblog.com/2023/05/so-long-passwords-th...
Those guys should not work in identity and access areas. Period. Only one reason says everything: they provide no support. Customers will be left in the cold, minus all their belongings.
But they may separate into several companies to avoid conflict of interests, if they prefer, this time with proper support and everything. Or they can be forced to do so, if they are too stubborn and will continue running their dystopian playbooks.
So, the situation is not strictly technical, it's much deeper than that. A blog post won't make a dent.
Re: Passkeys: The beginning of the end of the password
#185WebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards. At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures. I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requ…
Personally I don't want to be dependent on a third party like Google or Apple for my identity. That's never going to be acceptable.
If they just accept normal Yubikeys (and multiple at a time for redundancy) that'd work for me but this passkey stuff where the vendor gets to decide things and I don't fully own my credentials is just wrong IMO.
I wonder if there's a fully self hosted passkeys option?
I'm also opposed to attestation. With TOTP I can use any app I want and back up my keys however I like. But Fido gives a lot of control to websites, they can choose what kind of authenticators or apps to accept. This can make it too easy to get locked into vendor solutions because they are the only ones every website trusts.
Re: Passkeys: The beginning of the end of the password
#186WebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards. At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures. I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requ…
My cynical assessment of Passkeys is: If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere. This isn’t a theoretical risk. You’ll see lots of people complain about this online. Also, Passkey providers now get sweet sweet metadata about your accounts around the web. But yeah, authn is hard to do right. Equally, asking your users to fall into $BIG_PROVIDER’s arms seems wrong. My pe…
> If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere.
Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co. ("roaming authenticators" in WebAuthN/FIDO parlance).
Unfortunately, only Android is planning to offer [1] a first-party Passkey provider API, because that's what I'll probably be using 99% of the time (finding my external authenticator for every login is frustrating).
> Also, Passkey providers now get sweet sweet metadata about your accounts around the web.
To my knowledge, both Google's (for Android) and Apple's sync backends are end-to-end encrypted. I'm not sure if that includes the metadata as well as the private keys, though.
[1] https://developers.google.com/identity/passkeys/supported-en...
Re: Passkeys: The beginning of the end of the password
#187Auth is as secure as the weakest link - in the case of this it's your email and/or customer service To put it another way, it's not really any more secure than passwords. Sure, there's a lower risk of password breaches, but if you're the target audience for passkeys, you probably also use a password manager with unique passwords per site (even if that manager is the one built into your browser and synced across your…
> Auth is as secure as the weakest link True if you are being specifically targeted, but there are whole classes of vulnerability that you are better off not having even if you have less than perfect opsec. To take an extreme example, my personal server may have an unpatched vulnerability that a determined attacker might exploit, but that doesn't imply I might as well share the same password across all my accounts.
> that doesn't imply I might as well share the same password across all my accounts
Irrelevant to the argument I made. My argument already assumes you're using unique passwords, since it's made quite simple these days.
Re: Passkeys: The beginning of the end of the password
#188I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/ . Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear o…
What you describe sounds awesome. Is it still something people could use? If the WebAuthn protocol gains broader support because Google/Apple are pushing passkeys then anything that speaks WebAuthn should be a viable option, right?
Disclaimer: I own 2 NFC rings :)
Re: Passkeys: The beginning of the end of the password
#189This looks and feels like passwords with extra steps... I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built. What happens if i lost all…
Passwords can be both stolen (they are valid for multiple authentications) and are susceptible to phishing/MITM attacks.
TOTP/HOTP solves the first problem by making the credential provided during authentications single-use, but they're still susceptible to phishing/MITMs (since you don't know where you're entering your OTP).
WebAuthN solves both.
> What happens if i lost all my devices due to a fire?
Passkeys are synchronized to your device ecosystem vendor by default (i.e. Google or Apple, and soon also third-party password maangers on Android), for better or worse.
Re: Passkeys: The beginning of the end of the password
#190This looks and feels like passwords with extra steps... I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built. What happens if i lost all…
The solution, for you, is a cloud synced passkey manager, possibly a custodial one. A password manager with strong passwords is weaker than a password manager with passkeys, because passkeys use asymmetric crypto and passwords+2fa involve exchanging a shared secret over an insecure channel at some point (yes I'm considering 1-sided TLS an "insecure" channel here). Trust the security experts when they say passkeys are…
> The solution, for you, is a cloud synced passkey manager
This is in fact the only possible solution you get on iOS, and the default solution on Android.