Passkey is some sort of specific unique key to a device allowing to use a pin on a device instead of the password. But which won’t work on another device.
Now I don’t know if that key can be stolen or not, or if it’s really more secure or not, as people have really unsecure pins.
Man, the amount of fearmongering and anti-Google rhetoric in this thread makes me sad. Passkeys are almost entirely a good thing and are supported by many big and small companies.
No, it won’t lock you into Google, it’s an open web standard. Google will have an Authenticator, Apple will, and third parties will spring up to support it as well. And there’s no lock in, you can get a new passkey when you want to switch devices or providers.
No, someone who gets access to your device can’t get access to everything if you have basic security hygeine. Secure your passkeys with a secondary password or use biometric authentication.
Yes, it’s almost a straight upgrade to text passwords. They are immune to phishing attacks and other social engineering tricks, and you don’t need to remember long strings of numbers and letters anymore.
Do your research people, sheesh.
This is starting to really get on my nerves, and I feel like discourse on the fediverse is worse; basically the attitude is that if it’s not FOSS and self-hosted, it’s shite. That attitude is fucking grating for the rest of us.
This and if any business anywhere manages to reache a significant level of success — and has the nerve to charge money for their service — it’s a sign that capitalism doesn’t work and corporations are inherently evil.
I just assume it’s an age thing.
Big tech have done this to themselves
An online authentication system is quite literally the one central thing your whole digital life depends up on. If it’s broken, it can completely f’up your life and remove you from existence in the digital space. So there is extremely good reason to be skeptical when big-company tries to force you into a new thing. Especially when said big-companies have a history of f’n things up on purpose (remember G+ forcing real names on everybody and bundling previously unrelated accounts into one monolithic one?). Or take HTTPS, which was sold us with “bringing more security”, when what it actually did was kill large chunks of the open and self-hosted Web.
Are you seriously arguing against HTTPS?
Yes. It’s one of the major reasons why the Web turned into a cooperate controlled hellscape. Note, I am not arguing against encryption, just against HTTPS crappy implementation of it. It’s also going to get even worse with QUIC.
HTTPS is definitely not a major reason the web turned corporate. It has its problems for sure though.
Look at Gemini if you want an example of a decent web ecosystem that has HTTPS as a requirement for the protocol.
Gemini benefits from two things that the web has lost:
- small size: just like the web was once small, Gemini is still too small for any copos to consider it as an option to push their content or services although I believe there has been some small examples of this being tried.
- simple browser spec: Gemini benefits from having a number of browsers, none of which implement anything as interactive or insecure as JS(mime types other than gem text tend to be opened by other applications) and no one browser is influencing the spec for their own goals. This means all Gemini content is static once loaded by the client. No injected ads, no scraping of data and no hijacking of the tech by private companies.
Am not buying the idea. It sounds great on paper but in reality it doesn’t feel better. So idea is you have private and public keys, like many other forms of encryption out there. Private is stored on your device, and public is stored on account holder, like Google. Since keys are mathematically linked anything signed with private key can be verified by public key and vice-versa.
This is great technology and has been proven for decades now. It essentially means your device and account holder can exchange data without anyone ever finding out your private key since it never leaves your device.
However, issues. Keys are backed up somewhere and still depend on password, be it pin or regular old password. Recovering lost key means using password still. That means attack vector has just shifted and they won’t try to steal your key but social engineer their way into phishing your original password, making the whole thing a bit pointless.
Another things that worries me is the possibility each device will have its own key, although they claim transferable. Depending on what data is used to authenticate and prove device is owned properly this can be used to fingerprint users. For example IMEI or some other unique id, etc. Something that’s not easily done with passwords.
Biggest one is the fact it will negate two factor authentication. Verifying code on your phone and knowing password is difficult to exploit since it requires a lot of effort… possession of the device and knowledge of password. But with passkeys, there’s no password to remember and everything boils down to owning a device. They are then relying on the OS and device itself not to leak sensitive information. Not something I’d rely on.
Also, private key being backed up on Google means should they ever leak data someone can get everything they need to access your account. Private keys being protected by simple pin or password means nothing and would probably be easily broken due to simple nature of the protection.
Am not convinced this will see such high adoption as so many are claiming it will have.
Most hardware today has what’s called a TPM. It’s a physical hardware chip that can store certificates in a way that can’t be extracted.
It’s way more secure than someone stealing a cer file.
I know what TPM is, am not talking out of my ass here. But chain is only as strong as its weakest link, which is backup certificates somewhere protected by a pin or simple password. If it still requires password to access certificate, than you have moved issues from one place to another. What good is iron front door when you leave your windows open.
It doesn’t feel better? Good thing security doesn’t care about feelings. The fact is it is more secure no matter what it feels like. Privacy is maintained since you use a new key with each site. There is no IMEI or anything like that in the passkey spec. Social engineering ranges from more difficult to impossible depending on if you use a synced, local software based, or hardware based passkey system.
You have a lot of incorrect assumptions. Read https://support.apple.com/en-us/102195 and https://fidoalliance.org/passkeys/#faq.
You have a lot of incorrect assumptions
No I don’t. You either misunderstood what I wrote about or don’t understand how whole process works. There’s no denial that signing in with passkeys is more secure. Technology has been there for a while and it’s proven. But that’s only one part of the whole process.
However, even the site you linked states:
When a user is asked to sign in to an app or website, the user approves the sign-in with the same biometric or PIN or on-device password that the user has to unlock their device (phone, computer, or security key). The app or website can use this mechanism instead of the traditional username and password.
Problem is in biometric or PIN on device. Which is what I talked about, you replace 2 factors with a single point of authentication. No matter how secure data exchange between site and device is, getting hold of your device means there’s a potential to losing access.
They claim second factor and password can be fished, but so can your PIN, and it’s even easier since it’s usually short. Whole security idea they are proposing is removing human factor completely from the authentication process. Which in general is not a bad idea to get rid of bad habits people have but at the same time, those bad habits are just relocated elsewhere. There are number of YouTube videos showcasing how easy it is to bypass lock screen patterns and PINs. Not to mention huge amount of people who simply don’t want to have any sort of security on their phone.
They claim passkeys are multi-factor in essence, but that’s not true. Whole point of multi-factor authentication is to make it harder to posses all things needed to exploit the data. Access to ATM requires card and pin, one thing you posses other have in your head. OTP works the same way, user/pass for web and then device you posses generates one time password. Having everything in one place is like locking your door and leaving the key beneath the door mat. Key can be as elaborate as it wants to, if someone lifts the door mat, whole security goes away.
Use a pair of hardware tokens and a long pin if you want maximum security. If you want to use a sync-able software token do that and set a strong pin.
You like long passwords? Go ahead and put one on your passkeys. You don’t have to use a short pin.
It is two factor. Something you have, key in TPM or hardware token, and something you know: the PIN. Or if you choose to enable biometric it shifts to two things you have the: key and your face/fingerprint.
Remember you only have limited attempts to guess the PIN and biometric auth is subject to configurable timeout conditions before the PIN is required.
Any security conscious person will use a strong PIN. Many will choose to use biometrics as well for convenience. Most people are still setting their password to Sm3llyK@t42 on every website. A protected key and a 4-digit pin/finger print is a huge leap in security.
But that’s the whole thing we are trying to solve here. We are trying to eliminate human factor and by extension bad habits people have when it comes to security. So expecting people to use good passwords and pins for keys will be the same as expecting people to have good passwords for accounts. Perhaps even worse because of claims it’s better security so people might even relax more.
Also timeouts with pins and passwords mean very little once someone has your device. This is why I don’t consider it good two-factor. PIN might be in your head, but nothing is preventing someone brute forcing it. Once you image the device you can do whatever you want. With credit cards, you’d need ATM to keep doing it and lockout is a serious problem there.
It’s a step in right direction for sure, but I’d prefer if keys didn’t depend on PIN or password.
But that’s the whole thing we are trying to solve here. We are trying to eliminate human factor and by extension bad habits people have when it comes to security. So expecting people to use good passwords and pins for keys will be the same as expecting people to have good passwords for accounts. Perhaps even worse because of claims it’s better security so people might even relax more.
I feel like it’s 2001 and I’m trying to convince my users to switch from passwords to RSA keys for SSH. Yes there are potential weaknesses. Yes it’s still much better.
Also timeouts with pins and passwords mean very little once someone has your device. This is why I don’t consider it good two-factor. PIN might be in your head, but nothing is preventing someone brute forcing it. Once you image the device you can do whatever you want. With credit cards, you’d need ATM to keep doing it and lockout is a serious problem there.
Even if all we’ve done is reduced potential attackers from everyone with an Internet connection to people with physical access to the device we’ve still massively increased the average user’s security. And we’ve done more than that.
Also unless you can clone the device somehow hitting max guesses and losing access just like an ATM is part of the design.
It’s a step in right direction for sure, but I’d prefer if keys didn’t depend on PIN or password.
I lost track of your suggestion over the weekend but what was your suggestion for second factor other than a pin or password?
I didn’t have one, I just disliked the idea of having all that’s needed for auth in a single device which can be lost.
Thanks for the civil discussion. While my views haven’t changed I have learned a lot about possible objections from informed people.
Let’s hope this new auth standard is implemented responsibly by all the major parties and that weak passwords and phishing become relics of the past.
deleted by creator
I have a long list of questions about PassKeys and none of this articles explains them well enough.
- Does Android have it build in AOSP or Google Play Services?
- Would it be possible to actually see your private key on Android? Like export them to a file?
- Does they work without third party service? Can it be just me and the service I am logging in, or does it require my servers from PassKey provider (like Google, Bitwarden, 1Password) to work?
- Can it be used offline? For example, can an offline device create token that second online device could use for login? (Like TOTP codes).
- Does they work on other Internet services than the Web? In other words, does they work purely over HTTP and webviews or can they be in future used to login in for ex. SSH servers?
Nothing of that?
You don’t need to export or know what is the key.
The key is different for each device.
You don’t need to export or know what is the key.
But is it possible in the implementation of Android/iOS?
Backups are a thing. With SSH keys I have different key for every device too, but as they are stored in an accessable file (as all computer data should be) they are backed up with the rest of the system.
So first, no, all the files should not be accessible : There are special not “files”, but keys, like the key used for this method. These keys pose a huge security risk of they are leaked somehow. The key can be something used to encrypt the device/disk, encrypt a connection, and other things associated with encryption.
And because of that security risk, they are often stored in a special chip or simulated chip (like the simulated tpm 2.0 on pc cpu), and not just “stored” so any malware or who knows what can access them just by reading the drive.
Second, the key is never transfered. When you connect to another device, that other device will get another key. Or maybe could it be backed up somehow in case of recovery on another phone? But that would defeat the entire purpose of this.
How Google can do to allow you to connect to another device if the first one is lost, not sure. But it would certainly either ask for a password and a 2fa method.
i tested it on another device, it looks like it gets the passkey from the source device (not from cloud), i had to input the original device’s unlock pattern for it to work
And it’s expected as you still had that device. And it’s not the same key, a new key has been created for that new device. Now if that device cannot be accessed?
deleted by creator
The problem with Google’s passcodes:
- I don’t use Google account on my phone. In a rare occasion I need to access gmail outside of my home, I just log in via a browser, either on my phone or work computer or wherever.
- My home PC has no authentication whatsoever. The three physical locks on my apartment’s door is the access control. Couldn’t lug it around for authentication, anyway.
- I have no other devices that could be used for this passcode thing, and my phone is usually laying around somewhere, probably shut off with empty battery.
In fact, I have not bothered even with 2FA for google accounts. At this point these are just “garbage collection accounts” for spam and youtube subscriptions/playlists, anyway.
i don’t own a ‘device’ to use for this. i don’t even want one.
While I would agree this sounds more secure, I’m always worried about people getting further locked in to Google’s products.
Hopefully this system won’t take accounts “hostage” by requiring you use Chrome to log in to them, but it’s Google, so…
EDIT: I’m wrong, passkeys are stored per-device and can be shared between devices using an open standard. Here’s a video explaining the basics. It addresses my concern at around the 2:50 mark.
Passkey is an open standard. It’s not Google specific.
Use a yubikey, that doesn’t vendor-lock you to an OS ecosystem. They make one with nfc so it’s not a pain to use with your phone.
I’m not sure if this is universal or specific to the last site I tried to use my Yubikey with as a passkey, but it only would allow it to be used as 2FA, not actual passwordless authentication.
I assume this is because Yubikeys don’t create a secret for each individual website I suppose? Not exactly sure about that one.
The site likely didn’t support passkeys. But passkeys are basically webauthn passwordless login, and per the yubikey docs they support that.
See https://www.yubico.com/authentication-standards/fido2/ and https://fidoalliance.org/passkeys/#faq for more info. See also https://support.apple.com/guide/iphone/use-passkeys-to-sign-in-to-apps-and-websites-iphf538ea8d0/ios specifically the bit about adding a passkey to a physical key.
Google definitely supports passkeys, and they were one of the sites that did this. I’ve just replied to another comment regarding this. I wonder if the Yubikey 4 (I’m not sure how to tell which one I have, since they look about the same) just doesn’t support passkeys, which would be… unfortunate.
It’ll be even more unfortunate if there’s a weird mix of sites that support the Yubikey as a passkey and some only support it as a passkey. My Pixel is supported as a passkey, but Firefox on Linux doesn’t support this - only on Windows and macOS. I believe Chrome/Chromium does, which is equally as frustrating as my Yubikey possibly not supporting passkeys.
Strangely enough, Google lets me “add” my Yubikey as a passkey, but then does not let me sign in with it due to it not being “recognized”. If I remove it as a passkey, and only use it as a 2FA token, attempt to sign in and use the “Enter your password” option, it will then let me use the key after I’ve entered my password as a second factor.
So it seems Google has removed the error (or its not triggering anymore) as they will have been one of the first sites I tried to create a passkey for, but it still does not let you use it as a passkey.
The credential needs to be set as discoverable and some other stuff to work for passwordless login (the token must store site specific data)
You would need to reregister it as passwordless to not just use it as 2FA after having entered a password (meanwhile standard 2FA with webauthn don’t store anything on the token, the website sends encrypted credentials to the token which only the token can decrypt and then authenticate with)
Per Yubico’s specs on the Yubikey 4, it does not support FIDO 2 resident credentials, meaning it does not support Passkeys.
Compare to the specs of the Yubikey 5C NFC or Yubico Security Key C NFC, which both have this section:
FIDO2
The FIDO2 application allows for secure single and multi-factor authentication, and can store up to 25 resident credentials. These credentials, which are protected by a PIN, enable passwordless login, where the YubiKey, unlocked by a PIN and authorized by touch, can log you in to your accounts without entering a username or password. The FIDO2 application is FIDO certified.
See also Yubico blog post with an FAQ about passkeys:
How are passkeys different from YubiKeys?
They’re the same, and they’re different.
They’re the same because YubiKeys have had the ability to create these passwordless enabled FIDO2 credentials (passkeys) since the YubiKey 5 Series became available in mid-2018. Currently, YubiKeys can store a maximum of 25 passkeys. We are evaluating increasing this in the future because of the likely increase in fully passwordless experiences across the web that require them.
They’re different because Platform created passkeys will be copyable by default using the credentials for the underlying cloud account (plus maybe an additional password manager sync passphrase), whereas passkeys in YubiKeys are bound to the YubiKey’s physical hardware where they can’t be copied.
I wouldn’t run out right now and buy a Yubikey to store Passkeys given the 25 key limit and the likelihood that Yubico releases a new key that supports storing far more of them, but if you do, the $25 Security Key series is the cheapest option.
Interesting, I’ll probably just have to wait till either Bitwarden supports Passkeys, or wait till Firefox on Linux supports cross-device Passkeys (so, my phone for example) as yeah a 25 key limit is not likely to be worth purchasing an upgrade for just yet.
Both the website and your physical security token must support the right type of webauthn credentials (the token has storage for a certain number of slots with “discoverable credentials”).
Passkeys is a variant of the same which is bound to your device’s own TPM / SE security chip or equivalent, plus a synchronization feature for backups.
Mot likely it won’t need to have chrome. However maybe Google services may be required.
However it is also very likely, if a device cannot support such feature, it will only require a password and 2fa.
