15 ms·
You need to click on the link that is in the post: https://blog.google/technology/safety-security/one-step-closer-to-a-passwordless-future/ https://blog.google/
by mk89 3y ago
You need to click on the link that is in the post: https://blog.google/technology/safety-security/one-step-closer-to-a-passwordless-future/ https://blog.google/technology/safety-security/one-step-clos...
> Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone.
It looks like a token stored on your phone that will be used instead of your password to authenticate.
Apple did something similar: https://developer.apple.com/passkeys/ https://developer.apple.com/passkeys/ that is automatically sync-ed in iCloud Keychain, so on every apple device you own, you can use it.
More information here: https://fidoalliance.org/passkeys/ https://fidoalliance.org/passkeys/ and this explains finally how it works FIDO in general: https://fidoalliance.org/how-fido-works/ https://fidoalliance.org/how-fido-works/
So yeah it's sort of a token, but technically, it's a private key that is used to sign the challenge at login time.
EDIT: from what I understand, while this prevents from "stealing passwords" etc., there is still the risk that someone steals your private key (copy/paste your phone or ... well, steals stuff from iCloud Keychain) and tries to use that to sign the challenge. Did I get it right? Or what mechanism is in place to prevent it? It looks like this time we use biometrics first (to unlock the screen) and passkey later?
- deleted 3y ago[deleted]
- __MatrixMan__ 3y agoWhy not call it a private key then, we've been handling those since the 70's. They don't need to be rebranded, they need to be taught in high school with the same words we've always used to talk about them.
- esquivalience 3y agoWhy not call passwords private words? We've been using words even longer. The answer is that they're being used to pass an authentication challenge. Pass + key is no different.
- __MatrixMan__ 3y agoThere's already nomenclature for that too. Auth keys vs signing keys.
- Zetice 3y agoI think the real answer to your question is a) marketing and b) it’s more data than just a private key. It has a private key, but also some other things. Could be clearer for the tech folks though I agree.
- mr_toad 3y agoI guess because historically (before computers) passwords were often shared. Even now a password doesn’t technically need to be private.
- bqmjjx0kac 3y ago"Open sesame"
- 0xCMP 3y agoNeither does a passkey. They've designed the standard to allow sharing the passkey with others.
- JohnFen 3y agoWait, they have?
- CydeWeys 3y agoAre you sure you have the details correct here? This is not generally how public key cryptography works.
- 0xCMP 3y agoFor instance, with Apple you can AirDrop the Passkeys. https://support.apple.com/guide/iphone/share-passkeys-passwords-securely-airdrop-iph0dd1796bb/ios#iph461474bab https://support.apple.com/guide/iphone/share-passkeys-passwo...
- MyNameIsFred 3y agoThe simplified terminology is not for you or I as technologists. It is for the general consumer market. Yes, public/private key cryptography has been a thing for decades, but it has been out of reach for the consumer market. The whole passkey idea is to reduce the technical and cognitive friction to make it a viable replacement for passwords.
- pimlottc 3y agoGiven how poorly private keys have done in the end user marketplace so far, they definitely need to be rebranded.
- __MatrixMan__ 3y agoEvery time I notice a rebranding I assume they're trying to hide something from me. Maybe that's just me.
- krageon 3y agoIt is a fair assumption even in this case, the rebranding serves to hide the fact that private keys are used from you.
- deleted 3y ago[deleted]
- dwaite 3y agoIt isn't (just) a private key. It is part of a purpose-built authentication process that leverages private keys as a component. You cannot use the private key within a passkey for general purpose data signing, for example.
- deleted 3y ago[deleted]
- masukomi 3y agobecause there's a time based hardware component to it. this isn't just public key encryption. Think of it as a physical Yubikey but embedded in your ...whatever.
- xg15 3y agoI'm not completely sure, but my understanding is that it's basically the same principle as SSH keypairs, with the added twist that the user never gets direct access to the private keys. The keys are also per-device, so e.g. if you use your Google account from your phone, your laptop and your workplace PC, there would be three public keys associated with your account. Because the private key (in principle) doesn't ever need to leave the device, it could be stored in a TPM, Secure Enclave or similar chip. The device itself is also supposed to protect the key with some sort of local authentication, i.e. biometrics or a PIN. That stuff only happens locally on the device though and doesn't involve Google's servers in any way. Consequently, if you want to log in from a new device, you can't just copy over the key - you have to perform some complicated dance where the new device and an old device that you have already registered work together to generate a new keypair for the new device. If you don't have an old device, e.g. because you're a non-techie and only ever used your account on your phone and now your phone just broke? Though luck, I guess? Same goes for blocking a key: In theory, you can block access for each device individually - however, you need to be able to access your account using one working device in order to do so. (There is also the hilariously useless flow of "delegating" to a device, for when you're really really really want to check emails from your friend's phone but also have your own phone right with you in your pocket. It will not actually help you if you want to check emails from your friend's phone because you have forgotten your's. This feature sounds a lot like they needed something to respond with if someone asks about logging in from 3rd party devices - without making that usecase actually practical.) So I guess all that does make stealing the private key somewhat hard: Phishing is out of the question as the user can't access the key even if they wanted to. Even if you got hold if the physical device, you'd have to get the key out of the TPM. The bigger problems I see is that your account is now tied to your devices instead of, well, you: If someone steals your phone and manages to guess the PIN or get through the biometric auth, they have instant access to everything. On the other hand, if you have no registered device left, you're effectively locked out of your account. (All that assuming if passkeys were the only option for logging in. As of now, they still seem to plan with passwords as fallback, so that's just hypothetical)
- taeric 3y agoSounds like you are describing how hardware tokens are typically done? With this being an idea of how to move the token into the cloud? I can kind of see the reasoning on why the browser wants to do this. Every one of them has a "generate secure password" feature bolted on, now. And I'm not clear that any of them have a way to port passwords out to another source. Still feels a bit uneasy to me. Physical keys for property provide the kind of security that just doesn't cut it for virtual assets. Such that I'm having a hard time seeing any model without terrible failure cases. :( Super glad that isn't my day job. Good luck to them.
- ouraf 3y agoWell, guess it won't work for me. Rooted phone and prone to boot loops and hard resets whenever i get curious with some stuff. Every authenticator stored in the phone can't be recovered when you install a new ROM (google tries to send the authorization pop up to the previous version of the phone and, of course, it'll never get there) Guess that's the price i pay for using the hardware in a slightly different way than what google and the manufacturer wanted me to.
- Shank 3y ago> Rooted phone and prone to boot loops and hard resets > using the hardware in a slightly different way Honestly I wouldn’t classify turning a daily driver device into a semi-brick (if it boot loops and has to be hard reset regularly…) as “slightly different”. If you want to experiment that’s fine, but why would you subject your daily driver to that? Or, why not just have a phone for stable use / real world stuff, and a phone for everything else? To put it bluntly: you’re wildly out of touch with reality for most people. 99% of people who have a phone — even those people who install custom ROMs on their daily driver — either plan around having to deal with this stuff or have an escape hatch. Most people refuse to tolerate such an experience.
- ouraf 3y agoOk, i wasn't specific enough, that's on me. My previous phone was a Xiaomi. Part of the reason they're cheaper than competitors with similar hardware is because that thing is filled to the brim with useless ads, extra tracking way beyond just crash analytics for the manufacturer and the regular google stuff and even some useless "phone booster" app embedded in the settings. After waiting the two weeks so Xiaomi would allow me to unlock the bootloader (which is bullshit, by the way), i installed LineageOS. The problem is that the regular updates with security patches sometimes would cause a boot loop. Some times is something as simple as a system file becoming read only, sometimes no thread on XDA developers could guide me to the right solution, and then i just do a factory reset and start over. But aside from flashing lineage and an ad blocker, my usage is the same as anyone else: answer calls, use messaging apps, browse the web, play games and edit some documents when i'm far away from my PC. My current phone is a motorola, though, and while i think the official ROM is pretty disappointing (too many pop ups nagging me to sign up to motorola or check motorola apps), as long as i can flash magisk and an ad blocker, i'm a happy person.
- mastazi 3y agoSo it's like a private key but you can't access or manage it, as it's owned by Google/Apple/Microsoft? How convenient!
- bogwog 3y agoNot sure if you’re being sarcastic, but that really is convenient.
- ThunderSizzle 3y agoUntil it's not and they decide you shouldn't exist anymore.
- avidiax 3y agoPrecisely this. What happens when Google decides that your account is banned, and no, we don't have to tell you why, and we regret to inform you we have automatically reviewed this decision and it is final?
- bogwog 3y agoOwning the private key for your Google account isn’t going to prevent that in any way.
- internetter 3y agoMy reaction as well. From Google's FAQ: > Passkeys created on Android are backed up and synced with Android devices that are signed in to the same Google Account, in the same way as passwords are backed up to the password manager. I don't like this. Time will tell if Google's implementation will be open source, and if third parties can hook into the OS level integration. I certainly don't like the lack of emphasis on interoperability from the get go. I do not like this future.
- jacooper 3y agoAFAIK android will have an open API, iOS however is going to only support iCloud, classic monopoly. Also it seems that Linux is completely out of the picture.
- tuatoru 3y ago> You need to click on the link that is in the post So, a communication failure straight away. Does not bode well.