The passkey ecosystem is far from complete, but Google's implementation is now ready to use.
See full article...
See full article...
Passwordless Google accounts are easier and more secure than passwords. Here’s why.
- Thread starter JournalBot
- Start date
Firefox support timeline for Passkey support (still a while away, not just on MacOS):
Update: found a more recent timeline
Source: https://connect.mozilla.org/t5/ideas/support-webauthn-passkeys/idc-p/30123/highlight/true#M17028
Update: found a more recent timeline
Upvote
12
(13
/
-1)
I don't see how this would solve spear phishing with password replay attacks. Most phishing MITM just replays the input to the server and replays the output to the victim, usually with a redirect at the end. Those types of attacks still work against TOTP MFA devices too, so those aren't really the attacks people are trying to prevent here.
If we are talking about nation state actors, they are just going to target the tech support of whatever they want access to so discussing technology to prevent that is meaningless.
And no, I never said Google was storing passwords in an unencrypted database. That's not how credential stuffing attacks occur. Usually people re-use passwords in multiple locations and the weaker sites expose the same passwords that were used on the sites that take their back-end more securely.
I agree with your suggestions for rolling out, with one caveat - actually publish a white paper that doesn't dabble in theoreticals such as the FIDO one claiming that users "probably" will have a second device to restore if their first device is lost. And this same white paper also shouldn't just suggest that passwords are used as the fallback for new devices, it should actually lay out the plan to fully remove passwords -- because that's the end goal right? We should know the steps we are going to take before we get there.
Upvote
1
(8
/
-7)
The private key is only available to the secure element normally. It is synced but E2E encrypted. With most competent secure elements you can load the encrypted private key and then decrypt on device I’d expect. You can’t just run an OpenSSL command on it for example because the secure element has the private key and it controls what you can do. Sign (or encrypt) only usually.
Upvote
8
(9
/
-1)
I don't have any problem with the passkeys themselves, but I'm just a bit disturbed to discover that Chrome can that easily manipulate my Bluetooth adapter whenever and however it likes. Even on Ubuntu.
I disabled BT to see what would happen, and sure enough, Google complained that it couldn't reach my phone... and offered to turn BT on for me. That, at least, did not work. Yet. (I assume it does work that way on Windows, and possibly MacOS as well.)
To be extremely clear, again, this has nothing to do with the passkeys themselves; as an authentication standard, they're fine. I am just not in love with how much control the browser has over my hardware (because the more control it has, the more control an attacker who owns the browser has).
I disabled BT to see what would happen, and sure enough, Google complained that it couldn't reach my phone... and offered to turn BT on for me. That, at least, did not work. Yet. (I assume it does work that way on Windows, and possibly MacOS as well.)
To be extremely clear, again, this has nothing to do with the passkeys themselves; as an authentication standard, they're fine. I am just not in love with how much control the browser has over my hardware (because the more control it has, the more control an attacker who owns the browser has).
Upvote
28
(30
/
-2)
I do a factory reset on my phone and tablet roughly every 90 days.
I reformat the os drive of my computer, and install a new distro roughly every six months.
If I understand the way passkeys authenticates things, I'll lose all of my accounts within six months.
No thanks.
Upvote
-11
(3
/
-14)
You’re confusing yourself once again. None of the quote implies anything about deleting passwords. I hope they do delete passwords for their own accounts at some point but that’s realistically decades in the future if it ever happens, once most of the edge cases have been solved or gone away and when most of the rest of the internet has made passkeys a ubiquitous option.
Look at how long it’s taking to get 2FA rolled out for any more than a small fraction of the deep web!
So yes, I think a few Google blog posts saying ‘many devices don’t support passkeys yet’ and ‘we will apply closer scrutiny to password login activity because we believe those are the weak link’
is NOT the same as:
‘we plan to delete everyone’s Google account passwords in the near future’
Upvote
-12
(4
/
-16)
I'm all for the IDEA of using passkeys in general, but it does have some serious limitations... for myself, the lack of support for computers (MANY desktop PCs) without Bluetooth is a pretty big one. Additionally, the lack of Linux support is a big deal for me personally - hopefully someone will create a self-hostable passkey storage system (there would obviously need to be some way to add your self-hosted passkey server URL or similar when adding a passkey to a service).
Another big issue though is one I already have to deal with with 2FA (though I use and support 2FA generally) - I do a lot of technical support for older people, and sometimes need to do things remotely, on their behalf. With 2FA it's extremely difficult to log into someone else's account (Google, etc.) to change a setting, look something up, help them recover or reset a password, etc.. This is of course intentional and generally a good thing, but it does complicate technical support. Passkeys seem even worse for this purpose than 2FA, since at least with 2FA I can call them and ask me to read a code displayed on their phone, or tell them to tap whatever prompt is displayed.
Another big issue though is one I already have to deal with with 2FA (though I use and support 2FA generally) - I do a lot of technical support for older people, and sometimes need to do things remotely, on their behalf. With 2FA it's extremely difficult to log into someone else's account (Google, etc.) to change a setting, look something up, help them recover or reset a password, etc.. This is of course intentional and generally a good thing, but it does complicate technical support. Passkeys seem even worse for this purpose than 2FA, since at least with 2FA I can call them and ask me to read a code displayed on their phone, or tell them to tap whatever prompt is displayed.
Upvote
4
(8
/
-4)
- Add bookmark
- Featured
- #528
You won’t lose any accounts and you definitely have not understood the way passkeys authenticate.
Upvote
6
(9
/
-3)
Of course they don't plan on deleting everyone's passwords in the near future. Because they don't know how to get rid of password backups. But the messaging of their titles "Goodbye passwords, thanks for all the phish" and "Maybe next password day, you won't need to remember your password!" are very implicative of actually not needing passwords. Which is a disservice to users and gives the false implication that passkeys are more secure than passwords, even with password based backups being able to do 100% of what passkeys can do.
So again, the weakest link is password backups, without removing password backups, passkeys are useless from the standpoint of providing actual security benefits. If there is no known methodology to remove password backups, then what is the point of passkeys?
Upvote
23
(28
/
-5)
“Oh yeah I have hardware key and iCloud syncing so it works great for me and thus you must use it as well”
Tired of these tech bloggers assuming everyone else have the same “working” setup as his. I won’t be using these in the near future as much as I want to, because seamless support is not there yet, and breaking something somewhere will be bring more headache.
Tired of these tech bloggers assuming everyone else have the same “working” setup as his. I won’t be using these in the near future as much as I want to, because seamless support is not there yet, and breaking something somewhere will be bring more headache.
Upvote
8
(12
/
-4)
To be fair here, it’s Chrome itself - the compiled binary, not JavaScript - doing that. It’s still scary because a code break gets access, but that’s true of any binary - once you’re running native code outside a sandbox all bets are off.
Upvote
16
(16
/
0)
Passkeys are actually a huge benefit for your particular use case and it’s one thing that I’ll benefit from too (supporting aging family members).
They can have a passkey for their account saved on their system, and you can have a different passkey for that same account, saved in your system.
The main reason I’ll benefit is that they won’t become preconditioned to frequently giving out 2FA codes over the phone or tapping yes on a screen prompt.
Upvote
-2
(6
/
-8)
Well, shit, I change devices and OS much more frequently than that. Must have lost my passkey…. Oh … all of never times.
I’ve deleted FIDO2 Authenticators deliberately far more often than I’ve lost them, because I actually write code that works with them and tests them.
Upvote
11
(11
/
0)
This was true for what Apple calls “Face ID or Touch ID for the Web” – aka WebAuthn using the Secure Enclave – but it's more complicated for passkeys because those do store the private key in the iCloud Keychain but heavily encrypted and also protected with things like rate-limiting. Here's how Apple describes it in https://support.apple.com/en-am/HT213305:
Upvote
6
(6
/
0)
Perhaps I wouldn't have made such an assumption if I had ever seen anything at all to indicate that Thunderbird would have support for Passkeys any time soon. Given how long it took for OAuth support to get added, I think it was reasonable to conclude it wouldn't be a thing I could do in Thunderbird.
Incidentally I've tried the demo on passkeys.io, both Firefox and Vivaldi on Manjaro want me to plug in a security key. Whether that's a limitation of the browsers or the demo, I am not sure.
Upvote
6
(8
/
-2)
You only lose your accounts if you wipe all of your devices simultaneously, nuke your recovery codes, and don't set up any kind of backup or escrow system, or even simply have something like a password + Yubikey backup for your critical accounts. If you aren't intentionally trying to lose data, here's what the process looks like:
- Unenroll your device before you wipe it.
- Re-enroll it after you do the install by approving access from one of your other devices.
There is no step 3.
If you forget, the process looks like this:
- Enroll the newly-installed device using one of your other devices.
- Remove the old registration using one of your other devices or the one you just added.
Upvote
13
(13
/
0)
They actually have - if you know how to translate the marketing speak "Passkeys" into the technical spec: "multi-device credential" or "backup-eligible credential".
The current draft spec for the Webauthn is here: Webauthn
When you register a passkey, the website can see that it's a multi-device credential, and if the private key is backed up. In that case:
(Relying Party = Webserver, in their terminology, "Client" = Browser, "Authenticator" = Yubikey, for example, or the one built in to the phone or computer "Platform Authenticator")
So after you generate a passkey and back it up, the server can know and suggest that you remove your password.
Upvote
15
(15
/
0)
Sorry to contribute to this train wreck, but WHAT are these places saying “no thumbdrives”? I can’t think of any context involving personal devices where this makes sense.
Upvote
-18
(1
/
-19)
If I have a Passkey on my old Android phone, how do I transfer or set it up on a new Android phone?
Upvote
0
(2
/
-2)
You don’t even understand how passkeys are a strong mitigation against phishing and MITM attacks? Then why are you filling the comments with misinformation when you haven’t done basic research? This was all explained clearly in the articles you have been very vocal in the comments.
Also, you said earlier that passwords are rarely compromised at point of use and that credential compromises are mostly from dictionary attacks, credential stuffing and exposed unsecured password databases. Now you’re saying that actually there are phishing attacks that are successful even with TOTP, and the NCSC and CISA both state that phishing is still the prevalent attack vector, so I still say that you were wrong earlier and that passwords are still vulnerable at the point of use.
Nation states are not going to target the tech support of an online service like Google which includes end to end encryption and which notifies its users if it suspects a hostile intrusion attempt. That would be the worst thing they could do. They would get an encrypted blob of data at best, and risk that the target would likely be alerted and seek security advice.
I’m glad that you like my suggested roadmap but I was being sarcastic; what I suggested is actually happening now and what is planned for the future, as documented in this article…. But don’t waste your time waiting for meaningful whitepapers, for decades now they have been another term for ‘marketing fluff to send to the accountants and upper management’ and the target audience is the IT people who know just enough to be dangerous
Upvote
-5
(4
/
-9)
- Add bookmark
- Featured
- #542
It's not just dumped on people - this is an update to FIDO2, itself the second version of the standard. U2F was FIDO1; this is CTAP 2.2 ([edit: Corrected from my WAG of 2.4 that was wrong, thanks Still Incorrect!]), part of FIDO2/WebAuthn. This is really nothing complicated as that goes.... they've loosened up the Authenticator requirements so that the private key can be (must be...) copied securely, and added some Javascript features to make life easier. Passwordless logins? Always been possible with FIDO2. That's the neat part of it - FIDO1 could only be MFA. Adding a private key to your browser stored in the TPM or secure element? Always been possible, and was previously implemented in Chrome, Firefox and Safari. What's new is that it can be synced, and accessed via the BT/QR rigmarole. Previously, it was referred to (and flagged to web sites) as "platform specific keys", as opposed to the portable ones which were hardware devices. Now it's PassKeys.
Last edited:
Upvote
10
(10
/
0)
Is this requirement documented anywhere?
I ask because before FIDO had their metadata service to list compliant authenticators. According to the spec, they only list key protection types - and there's nothing between Software and the different hardware types.
Spec here: Metadata
See 3.2 Key Protection Types
Upvote
4
(4
/
0)
- Add bookmark
- Featured
- #544
Your points #1, #2, and #10 are just wrong – ask anyone who works in tech support how often they have to do password resets because someone forgot their password, left their caps lock key on (or mispositioned their hand on the keyboard), or fudge-fingered it enough times to get locked out. Yeah, yeah, I know you personally always hammer it out perfectly but trust me, anyone who gets helpdesk calls has a … less optimistic … view of humanity. I'll also add that I support a lot of blind users and password entry massively sucks for them because many sites have complexity requirements which are hard for screen reader users and if you aren't a proficient touch-typist saying it out loud isn't great. That's a niche but it's one that many people building authentication systems are legally required to support well, too, and it's one of the reasons why I'm interested in the technology since “Do you want to login with your passkey?” “Yes” is at least one order of magnitude faster and easier than any form of password + MFA for many those users.
Point #3 is true of WebAuthn MFA but always passkeys – something like a Yubikey works anywhere you have USB/NFC but you might need to set a PIN or use their biometric series keys for passkey implementers like Google.com which require more than a simple tap.
Points #5, #6, #7, and #8 are also true of all forms of WebAuthn – both MFA and passkeys. Point #4 is true except for the first time you enroll a device when synchronizing an existing key. After the first time you've synchronized your keys, you don't need a network connection. If you don't want to sync, you can also buy a couple Yubikey biometric keys which again work fully offline anywhere you have USB or NFC.
That leaves #9, which is bad practice and should be avoided if at all possible. Modern systems have things like role-based authentication, where people never share passwords but multiple people are allowed to assume a given role, or things like legacy or delegated accounts where you again never share passwords but give one or, even better, multiple people required in combination the ability to do something like reset your password or gain control of your files.
Just because something is new and you haven't learned how it works doesn't mean it's bad or to be avoided. Passkeys are a big change for most of us – .gov excepted since PIV/CAC goes back to the previous century there even if few other places adopted it – but they have a number of usability improvements in addition to the security benefits, and there's a clear path for building out some of the missing parts (e.g. I really want the ability to sync an Apple / Google passkey to a Yubikey so I could drop it in my safe just in case).
Upvote
-1
(7
/
-8)
The current implementation uses Google Password Manager:
https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html
Upvote
5
(5
/
0)
- Add bookmark
- Featured
- #546
The private key is not accessible. Why not look it up instead of repeating a falsehood over and over.
Upvote
-8
(4
/
-12)
I think I've answered this on another thread somewhere, but passwords aren't required as a fallback in a passwordless design. You can just drop them as an authentication mechanism.
You can still keep it as a "I've lost all my keys, lets start the recovery process" method, in the same way 'security questions' are for passwords, or you can choose any other method you like ("I've lost all my keys, email me a link and SMS me a code I need to type on the links forms" ... or if you're IT for a company "walk up to the IT service desk and present your staff ID"). You wouldn't call it a password at that point, you'd call it a "recovery key", and instead of letting the user choose it, you generate it when creating the account and tell them to save it/print it or they may end up locked out.
You'll still get some people who blow that too, and that falls back to either "tough luck" or "here's our 1800 number..." or whatever you want.
But at no point do you give people the option of typing a password that can be phished in to the normal login form - they're only typing in passwords in very rare special cases where they know to expect it because they've started the process of recovery because they've lost their keys.
Edit: Fix typo. I can wall up an IT service desk, and believe me, at time's I'm sure every one of us would want to, but I think walking is usually the more useful process
Last edited:
Upvote
15
(16
/
-1)
It's actually CTAP 2.2 and WebAuthn 3.
They finally published a working draft - it's here:
The QR code thingie ended up being called Hybrid Transport (section 11.5). There's lots of "cable" strings in the protocol surely because it was based on Google's version called "cloud assisted Bluetooth LE".
Upvote
7
(7
/
0)
Like when they find the post-it note stuck to your computer monitor?
Upvote
-1
(2
/
-3)
Thank you! This should be in the articles talking about passkeys, not on page 14 of a comments section.
Upvote
17
(17
/
0)
Sigh. Late to the party still. Google's making a dogs breakfast of it, which in no way surprises anyone, but they've got working stuff out there. Apple is across the board done. Microsoft rides on Google's coat tails (though to be fair, they do the Windows Hello part, that Google needs for it on Windows).
Any wonder I hate testing FIDO2 on Firefox (especially on Linux)
Upvote
3
(5
/
-2)
Not personal devices but companies and especially government. There are two concerns: the first is simply that USB storage is local storage and potentially risky — e.g. people have done tests where you can drop USB keys in the parking lot next to a building and some fraction of people will plug them into their work computer, which would be a great way to sneak malware into a secured network. The other is for any place which has data they want to avoid losing control of: if you can use a thumb drive, you can copy data on to it and take it out of the building where it can potentially become a disaster (intentional or not) — imagine if someone in HR wants to work at home and then drops the key with thousands of personnel records on it and you have to do a breach disclosure for all of them just in case someone malicious finds it.
The easiest answer in both cases is to block USB mass storage devices so you can allow things like keyboards and microphones but not storage. That still offers some attacks — a famous old one was https://lcamtuf.coredump.cx/plasma_globe/ — so places might go even further. It's been a while but a couple decades back when I was at a local security meetup with some people from the Navy SPAWAR facility, they said their protection system was a tube of epoxy: it was cheaper to pay someone to chisel it off while someone else watched a few times a year to replace broken keyboard or mouse than it was trying to figure out all of the possible ways someone could exploit something like USB, Firewire, etc. That's an extreme case but it is worth remembering that if you have any real cost to losing control of your computers or data it might be cheaper to limit how people can connect to the computers holding that data. I know people work in regulated industries who have certain things they can only do on locked-down terminal servers for the same reason — there's an upper bound to how quickly you could exfiltrate data if someone has to OCR a remote desktop session while they hold down the Page Down key.
Last edited:
Upvote
15
(15
/
0)
The account you are responding to seems to (possibly purposely) misunderstand that Google is somehow in the loop of using a passkey to login to another site. The words “Google passkey” in succession in a headline seems to have scrambled some brains to think this is a service provided by them making people dependent on Google’s good will or whatnot.
I’m half seriously starting to think some of the hysteria being enflamed here is from bot farms run by criminals protecting their business.
Upvote
-4
(6
/
-10)
Awesome! Thanks, corrected and credited in my original comment.
Upvote
5
(5
/
0)
Sure, of course you should follow your employer rules with their devices. Hot tip: if they superglued your usb ports shut, maybe you’re not supposed to add your personal accounts on there.
The OP seemed to asking about some other public place and I wanted to hear about some bonkers rule from some amusingly informed security theater pro.
Upvote
-13
(1
/
-14)
I don’t agree with you - registering an account with passkeys is effortless compared to setting up “enter username, next, enter password, next enter 2FA code/confirm prompt”. Signing in is totally effortless compared to juggling passwords and 2FA credentials.
Most computer illiterate people are far more comfortable with their phone than a laptop or desktop computer and using fingerprint or facial recognition biometric authentication comes more naturally to them to unlock the phone or access banking/messaging apps. In my recent experience, passkeys make all of this stuff easier.
For an example of the level of computer literacy of my family member who is using passkeys totally effortlessly on their eBay account: that same person recently asked me to investigate an issue with their laptop because the browser window had been too small for over a week - they did not realise that the edges and corners of a window can be left click dragged to change the size of the window…
Accessing eBay using passkeys on an iPhone and MacBook (both TouchID devices) was STILL easy for this person.
Upvote
0
(4
/
-4)
Good thing FIDO2 authenticators aren't USB storage devices. I think they're USB-HID. The one plugged into my laptop right now certainly seems to be.
Upvote
-2
(2
/
-4)
Apple is not done.
They have to implement an API to allow a third-party password manager to intercept the private key storage, or allow a third-party plugin to be an complete authenticator - Create keypair, Sign assertion, User verification, etc.
If Apple only allows private keys to be stored in iCloud, I'll have a hard time recommending passkeys to the group of users who uses iPhones and Windows computers. Those people will get stuck generating one passkey per ecosystem and/or hoping that account recovery works.
Upvote
4
(7
/
-3)
The article itself says "whatever syncing mechanism a user elects (be it from Apple, Microsoft, Google, or a third party)". So the trustworthiness of the intermediary infrastructure handling key syncing is an important question. The ecosystem handling the keys matters, and right now there doesn't seem to be a non-big-corporation alternative.
The conversation in the comments was also talking about broader passkey adoption and what that might look like, not specifically just logging into Google, so perhaps that was confusing? When this technology is getting started is a reasonable time to start thinking about potential implications. People in tech have already seen how badly private corporations owning key bits of infrastructure can get.
If Dan had focused on answering questions like SeanJW or a bunch of other users here instead of getting on a high horse about misinformation (when he initially got the Bluetooth requirements wrong in the article itself lol) things would have been a lot calmer.
Last edited:
Upvote
11
(15
/
-4)
Erm, just went through all the articles and not one of them explains how this prevents MITM attacks. If I have a website and trick you into visiting it, I do not see any reason why this would not be susceptible to MITM attacks.
Client <--> Malicious Server <---> True App
The malicious server contacts the app on behalf of the client, requests the signature from the client and then relays it back to the application. They don't need the private key to do this, they just need the application to request the key and the client to respond with the correct key. This mechanism can, to a certain extent, be mitigated server-side but that applies to passwords and passkeys.
The type of phishing this does prevent is the static credential harvesting website that pretends to be a login page but doesn't actually relay anything to the real site. And that also misses the point which is to your next paragraph.
"Point of Use" is in real time. Replay attacks are rare and can be mitigated on the web-application side. Credential stuffing is not "point of use" - it is used whenever the attacker wants to use it, not the client.
Phishing definitely is prevalent, never said it wasn't. I am saying that with password backups, passkeys don't help mitigate said phishing attacks because the backup falls victim to the same attack methodology as the old authentication mechanism.
Nation states definitely do target tech support pretending to be employees to reset devices/MFA. So no idea what you're going on about here.
Was fully aware you were being sarcastic. I was responding sardonically as nobody was showing the the plan to remove passwords (until page 14).
Upvote
0
(5
/
-5)