How does this work with checking my emails on a public computer in a library, for example? Somehow my private key needs to be shared with the library pc?
Comment on Google will now make passkeys the default for personal accounts
a_fancy_kiwi@lemmy.world 8 months ago
Someone else correct me if I’m wrong but it works similar to PGP.
Background info:\
- Your device generates two keys, a private key and a public key
- The public key can be given to anyone and the private key stays with you
- The public key is used to encrypt data and the private key is used to decrypt it
Usage:\
- You sign up for a service with your email and click submit
- In the background, a private key is generated and stored in iCloud Keychain, Google Passwords, or a 3rd party password manager (so all your devices can access it). A public key is also generated and given to the service
- Now you try and login. You enter your email and click login
- In the background, the server encrypts a challenge, token, or some piece of data and sends it to your device
- Your device decrypts that piece of data
- At this point, your device either sends the decrypted data back to the server in exchange for an access token or maybe you decrypted the access token (not sure exactly how that will work)
- Now you are logged in
Nolegjoe@lemmy.world 8 months ago
a_fancy_kiwi@lemmy.world 8 months ago
Not necessarily. I can’t imagine they’d want you to login to your iCloud or Google account on a public computer. It will probably work how Microsoft “Authenticator” works or how when you try logging in to iCloud or your Google account when you have 2FA turned on:
- Type in your username and click submit on the library computer
- The service on the computer tells you to look at your phone
- In the background, the service sent an encrypted challenge to your iCloud account
- All your devices receives a notification asking if that’s you trying to login
- You pull out your phone, click yes
- In the background, your phone decrypts the challenge and sends it back to the server
- The server verifies its you who is trying to login and logs you in on the library computer
No sharing of keys necessary
Nolegjoe@lemmy.world 8 months ago
If that’s the case, then a bad actor could spam someone’s phone with notifications. All they’d need is a username.
Or, like my mum, you don’t read what the notification says and just hit ‘OK’. Now you’ve let someone into your account without realising
a_fancy_kiwi@lemmy.world 8 months ago
Shit. Good point. According to this blog at 1Password, Bluetooth can be used to have one device verify another for a service. So I guess if the public device has Bluetooth, it’s possible 🤷♂️
Kusimulkku@lemm.ee 8 months ago
Wouldn’t the private key stay in your phone and you’d be exchanging a challenge and a response?
JasSmith@kbin.social 8 months ago
As you point out, the single point of failure is access to the passkey repository. Of course, this will usually be 2FA, so much more secure than simple passwords which people usually employ.
One major issue, IMHO, is vendor lock-in. I’ve no doubt Apple is going to make migration away from iCloud a huge pain in the ass. It’s just another way they’re going to make it difficult to leave their ecosystem.
I’m also worried about backups. People lose access to their Google and Apple accounts routinely for any and no reason at all. Will these keys be stored in the cloud? If so, access to EVERYTHING is just a capricious random algorithm away from being lost.
I wouldn’t touch any passkey system which doesn’t provide a seamless way to migrate away especially if I’ve lost access to my Apple/Google account.
hedgehog@ttrpg.network 8 months ago
Having a seamless way to migrate away is itself a security risk, since that method could be used by attackers to compromise the key store. The migration path for any of the major players (Apple, Google, Microsoft, Yubikey) involves logging into each site you used a passkey with, adding a new one from your new passkey store, then revoking the old passkey.
Password managers that store Passkeys may handle this differently, though, and are your best bet if you want migration flexibility.
JasSmith@kbin.social 8 months ago
The method you describe is untenable for 99.9% of the population. If that is truly the only way to migrate, then this move to passkeys is a catastrophe for security. In the coming years, millions of people are going to be permanently locked out of important accounts. Accounts will be written about the clearly flawed implementation of passkeys by Apple and Google, and a whole generation of people are going to shun passkeys forever. Myself included. This is a nightmare for vendor lock-in. I can see why Apple and Google are so ready to implement this.
timbuck2themoon@sh.itjust.works 8 months ago
I’m really over people calling backups a security risk.
There’s a reason bitwarden, 1password, last pass, etc etc. allow you to export your passwords. They also all allow you to do so in an encrypted file (iirc for all, I know a few do.)
hedgehog@ttrpg.network 8 months ago
Accessible keys are a security risk, regardless of how you feel about it. If a key is accessible on the system then any exploit with elevated read permissions can steal the entire key store. By leveraging hardware features that let you add and use a key but prevent reading it, you mitigate that risk. There’s a reason that on Yubikeys, secrets are write-only.
Bitwarden, 1Password, and other companies who build password managers are able to operate with higher expectations of their users. Their users opted into using a flexible, secure tool, and as such, they can provide riskier options to their customers. They know that providing a TOTP solution in their application doesn’t force their customers to use it when doing so would be outside their risk tolerance.
That said, every password manager that I know of - Apple’s, Google’s, Microsoft’s, Firefox’s, as well as dedicated password managers - has an export tool. But this doesn’t mean that all of those providers value having flexibility. I’d argue that in many cases it just means that they recognize that a password alone isn’t trusted enough to warrant concealing it. Given that you have to know the password to enter it, there’s much less value in concealing it from the end user. Since passkeys don’t work that way and do have that value, it makes sense for providers, if they are opting to prioritize security, would choose a less-flexible solution that most of their users don’t care about.
If the big providers did offer a more flexible alternative, enabling exports, to advanced users, those users would necessarily have reduced security and they would have to opt into that ahead of time, since later the secrets would be inaccessible (theoretically - depending on how the syncing is implemented it might be feasible to intercept them. My assumption, since syncing is within a given ecosystem only, is that when synced they are encrypted with a public key that only their secure hardware can decrypt). Also, having such an option would require a different code pathway when interacting with the secrets store, which would mean more potential code that could have bugs.