I’ve been using a password manager for all my passwords for years. Moving from “store a password” to “store a passkey” isn’t that big of a difference. The main thing for me seems to be that you can scan a qr code to authenticate another device, a workflow that I will probably end up using. It’s certainly easier and more secure than manually typing a 20+ character password into an untrusted device.
Yeah im sure people will use googles passkey storage, or apples passkey storage, but that was already happening with passwords too. Passkeys isn’t going to change that. Third party password managers are already adding support for passkeys. And OS support for third party passkeys is already there on mobile.
Personally I’m looking forward to passkeys. Just going to make my life a little bit easier. I’m going to continue using a self hosted vaultwarden instance. It already supports passkeys on desktop, and I’m eagerly awaiting mobile support for autofilling them. Hopefully that comes soon.
The big problem I have with passkeys is that, as currently implemented by ~everyone, they eliminate true second-factor authentication. I haven't seen an implementation yet that allows me to have something I know, and something I possess.
Passkeys are effectively SSH keys under the hood. All implementions I've seen are two-factor as far as the user is concerned: the server challenges the client to prove they own a private key, and the private key is encrypted client-side under a password, PIN, or biometric.
> Passkeys are effectively SSH keys under the hood.
Yes, that's the common rebuttal. It's resistant to MITM and phishing, but it's still not two-factor.
If you store your passkey on a yubikey with PIN, I suppose it's two-factor in the sense that you need the key and a PIN, but you can only store so many passkeys that way.
But why is 2FA superior? I understand that a yubikey seems more secure than the secure enclave of a computer, but that's a very specific factor (yubikey could incidentally be a single factor actually).
It's not so much that it's "more" in the sense of more of the same, like, e.g. requiring 2 different passwords. That's a waste of time. But 2FA makes the attackers job much more difficult. If someone steals my password or compromises a key, then they still need to hijack my SIM for SMS or steal my phone to get a code from my authenticator app. That's 2 completely different kinds of shenanigans that need to be successful.
How would a key compromise look like? A server-side key compromise just gives you public key material, which is useless. A client-side key compromise gives you an encrypted private key, but you've completely owned the client at that point so you've won already regardless of how weak or strong the authentication method is.
Traditional server-side 2FA (e.g., "give me a password and a 1-time code") is superfluous in a passkey world, because it's ultimately just a hack to make up for the fact that password-only auth is weak. Key auth is incredibly strong, so a server-side 2FA challenge doesn't buy you much.
The advantage of a physical second factor is that you need the physical second factor.
Put all of your passkeys in a single repo (as most people will), and you're literally putting all of your eggs in a single basket. Better hope nobody gets ahold of that basket.
The “something you know” is what handicaps passwords into being weak - they have to be easy to remember. And they have to be unique per service- because the website has to know the password too and websites get hacked. Because of this people basically have to use password managers. Because otherwise they set every password to “cat123” or “spring2024” etc.
And if people are generating good passwords and storing them anyway- we may as well store digital keys instead.
My password manager is still protected by a good password + 2FA. Passkeys will be protected by this as well. On my phone there is biometric that can replace the password as well.
How secure your passkeys are comes down to how protect them. But it’s definitely an improvement over passwords.
> My password manager is still protected by a good password + 2FA.
So yeah...your second factor is an actual second factor.
I completely get the argument that passkeys are an improvement for most people. But if you're already using password + pw manager + 2FA, it seems to me that you're a good bit more secure than a passkey alone.
It's an improvement over passwords as long as two things are true:
1. Open source implementations will be indistinguishable to a 3rd party from the big tech versions (so that services can't refuse to authenticate devices that haven't been locked down), and
2. The private key can be extracted from the device by the user and backed up.
All the implementations i've seen do both, you "HAVE" your phone, and you "ARE" yourself because touchid, faceid, passkey was used to unlock the key on the phone/bitwarden/whatever your using the passkey on, you still have to unlock the vault on the device you have to use the passkey
There's really no need to rotate it because the biometric is only used locally. Your private key is kept encrypted at rest on your device, and a biometric (or PIN or password) is used to decrypt it during the passkey "do you have the correct private key?" authentication challenge.
The remote server only sees the result of the "do you have the correct private key?" challenge, not the biometric/PIN/password unlocking the private key that happens locally.
Agreed - if you want true "thing you have", it needs to be a standalone hardware token, and it needs to be fundamentally impossible to extract the key from it. Otherwise, its key just becomes another "thing you know".
No they aren't; not unless access to that phone (including accessing the 2FA functionality) is in turn protected by a passcode/passphrase that you "know".
From what i've seen every passkey implementation requires the device + a password or touchid or faceid to actually unlock the passkey authenticator... thats 2 things... the device key vault + your face
The whole point is to not equate "password" with "touchid/faceid". The former is "something you know", and the latter are not. In the US, it's legal to get access to someone's finger or face. It's not legal to torture someone to reveal a thought.
"Something you know" means something in your head that other people can't access, and that is protected by the 5th amendment. The image of your face is not; it's something other people see every day. So it's not "something you know".
This article states clearly the case for Passkeys: passwords are vulnerable to phishing attacks. Phishing attacks are effective, anti-phishing training doesn't work (even for technically savvy users), and hardware tokens are too cumbersome; meanwhile, people already have a capable second factor device they carry around, and it's silly not to use it.
I don't know how much HTML email really has to do with phishing (successful phishing attacks are multimodal and tend to exploit browser chrome as much as anything else), but regardless: it isn't going anywhere, and even if it were the primary cause of phishing, the engineering failure would still be in the authentication system, not in the email presentation system; being able to control a layout on a screen simply shouldn't result in account takeover.
> Phishing attacks are effective, anti-phishing training doesn't work (even for technically savvy users)
This is overstating the case. I've never been successfully phished. Many people have never been successfully phished. Yes, phishing exists, but it's not an excuse for big tech companies to take away all user freedom. "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
I think passkeys are fine in concept — replacing passwords with site-specific cryptographic keypairs — but the demands of the big tech companies go too far above and beyond the basic concept. For example, here are statements from the person in charge of passkeys at Apple:
> If you can drop a single device in a lake and lose your credential, it’s not a passkey. Passkeys are backed up and synced across your devices to deliver a great and safe user experience, while also eliminating phishing. If it’s device-bound, it’s not a passkey. :) https://hachyderm.io/@rmondello/111188643228872151
> A reminder to attendees of Authenticate and people everywhere that “device-bound passkey” is an oxymoron. Passkeys are a phishing-resistant password replacement, usable by people of all levels of technical sophistication, built in to smartphones. If a credential is not resilient to device loss, and it doesn’t sync across devices, calling it a passkey will confuse your users who will expect a durable, resilient credential. https://hachyderm.io/@rmondello/111252067006418583
To me, these statements are both paternalistic and frightening. You have to understand what they mean by "synced" and "phishing-resistant". The big tech companies are taking these superfluous requirements to extreme. In essence, the attitude is that users can't be trusted with anything, and so users can't be given any control. This attitude is anathema to me.
All of my passwords are SSH keys are regularly backed up to multiple storage locations, including offsite. However, I take care of backups myself, manually. I don't use any cloud syncing service. I don't trust them, for a number of reasons, I don't want to use them at all. If I have to use a cloud sync service with my credentials, that's a nonstarter.
Moreover, as far as I can tell, when the big tech companies say "phishing-resistant", what they actually mean is that it should be impossible for the user to manually export and examine the private keys, because that would theoretically allow phishing. To my knowledge, FIDO still hasn't agreed on export/import methods, and it's very telling to me that they were willing to ship passkeys without this feature, which I would consider essential. My suspicion is that the "solution" they eventually come up with is some sort of "trusted" list of service providers, who can export/import between themselves without giving users direct access to the keys.
There are much bigger problems in the world than phishing. We can harm ourselves in so many ways: driving a car, riding a bike, crossing the street, smoking cigarettes, drinking alcohol, eating bad food, using a chainsaw, opening the front door for strangers, or any combination of the aforementioned. Thank god that cars aren't locked down yet, though I expect that "security professionals" will demand that it be done someday for our own good. Freedom is dangerous. Yes, freedom means that users can be phished. And it means that passwords can be lost. But the absence of freedom is even more dangerous, and I'll fight to the death to preserve my freedom.
It is not overstating the case, I don't think. Large security teams have done population-level studies on this. You feel like "freedom means users can be phished". That's fine, private companies are going to make different choices on the freedom/security spectrum than you'd prefer.
> It is not overstating the case, I don't think. Large security teams have done population-level studies on this.
If it were that easy, then wouldn't everyone have been phished by now? I've certainly received plenty of scam emails myself, and I think it's safe to assume almost everyone else has too.
> private companies are going to make different choices on the freedom/security spectrum than you'd prefer.
It's not that simple, because we don't have a free market. Three big companies — Apple, Google, Microsoft — have nearly the entire consumer market share for both operating systems and web browsers, and they're colluding to eliminate passwords. If they succeed, then I as a private individual and a private company (self-employed) will not be able to make a different choice than those three big private companies. None of us will be able to make a different choice.
I think the reasonable assumption of serious security teams is that past some number of people with access, and absent phishing-proof authentication, the probability of a successful phishing attack approaches (and probably rapidly approaches) 1. You can dispute this, but security teams are going to disagree with you, they have the data, and your freedom/security spectrum doesn't mean anything at all to people making corporate access control decisions.
I get that you're not talking about corporate access control, but rather your feeling that you're downwind of those decisions as a consumer, because Google and Apple are embracing the findings of corporate security research. I don't know what to tell you about that. If a friend asked me what they should do to secure their online accounts, I'd tell them to make sure they were using Google Mail, and to make sure they had Passkeys enabled.
What are you going to tell your friend if Google and/or Apple unexpectedly, permanently locks them out of their account, with no possibility of appeal, because they triggered some kind of false positive in the "security" algorithms?
These are real things that happen, as real and harmful as phishing.
And yes, I'm talking about free consumers rather than corporate drones. Of course, in a corporate environment, you're not likely to get permanently locked out unless you're fired, and you won't experience personal data loss, because corporate data isn't yours in the first place.
I'm going to tell them that that's much less likely to happen than them getting owned up, and that the outcome of them getting owned up is much worse than the outcome of having a problem with Google or Apple. I know† lots of people that have been owned up, and zero people who have had the problem you're describing.
I'm also going to tell them to beware of technologists, who have rooting interests that are more about industry politics and big picture principles than about user safety. I'll tell them that people lobbying against the increasing influence of big tech companies on security are going to lose that fight anyways, so there isn't much point in staking any of their personal safety on the debate, even if they do believe in it (in reality: very few of them will care).
Regardless: just as a connoisseur of Internet nerd argumentation: if you're going to come at Passkeys, you need to do better than "the Unix greybeards were right about HTML email", because (a) no they weren't and (b) it obviously wouldn't matter if they were.
> I'm going to tell them that that's much less likely to happen than them getting owned up, and that the outcome of them getting owned up is much worse than the outcome of having a problem with Google or Apple.
Citation needed.
> I know lots of people that have been owned up, and zero people who have had the problem you're describing.
Anecdotal. My personal experience is the opposite.
> I'm also going to tell them to beware of technologists, who have rooting interests that are more about industry politics and big picture principles than about user safety.
You don't think I care about user safety? To the contrary, I care deeply about it. I just don't believe that paternalism and infantilizing the public increases public safety; rather, I believe it creates the very conditions that make the public ripe to be exploited.
> you need to do better than "the Unix greybeards were right about HTML email"
I have no idea what you're talking about. This is a straw man argument.
Ah, ok. Given that we're deep in a thread, I assumed you were talking about my arguments.
In any case, that one paragraph in the article wasn't even intended as an argument against passkeys, since the HTML email ship sailed long ago (though I still use plain text religiously).
What? Just because passwords are flawed doesn't make passkeys the answer. The article does not say passwords are perfect. It says the current implementation of passkeys that has been created so far is worse.
1. Normally I run everything on my own devices, use 1Password, 2FA, etc, but rarely I need to use a locked down device and manually and painstakingly enter 100+ character passwords and 2FA keys. Installing anything on the device is out of the question, but I need to use a web browser and auth using these credentials. Copy and paste and externally using any devices to connect with the system is prohibited.
How does doing a FIDO2 dance work in this scenario?
Passkeys have a fallback flow where they show a qr code you can scan from the screen of the device you want to log in to. Requires bluetooth though to prove you are "near" the device. I guess that's also disabled on these hypothetical locked down devices?
And yet all the non-technical folks you give this advice to will look at you like you have two heads. This is completely unreasonable unrealistic user-unfriendly advice
Many people use shared computers at our local library. I can afford a nice quiet office and big monitor at home, but many people cannot.
I imagine they either memorized their passwords, wrote them on a piece of paper, or stored them on an (air gapped from the library machine) cell phone.
There is a keyboard and mouse attached to the server already, but few if any services run, and if they do they're fairly locked down, or in some degraded state.
It's not a server I need to access often in this way. But I think these necessary-but-limited-use scenarios will be interesting should passkeys really catch on like passwords did.
This is covered by the cross-platform scenario. It's not super elegant, although I'd say it's easier than typing 100+ random characters (and also trusting that the locked down device doesn't have any key logging?). Lots of providers have their own FAQ, but here's one: https://www.corbado.com/passkeys/faq#:~:text=Passkeys%20have....
why does this need a technical solution? Just type in the password. Presumably if the system is important enough to be airgapped and needs a 100+ character randomized password (without copy paste and without hardware keys), it is important enough for you to spend the time to memorize and type in the passwords.
Otherwise, it is just security theatre if you won't even spend the time to make absolutely sure that 1) you are typing into an authorized device that won't log your key strokes, and 2) that using any other "assistance" mechanisms represents a breach in the security of this system.
Just friggin memorize it and type it in. For me, I memorize my bank password and PIN even though it's very complicated. This information is important enough for me to commit the time and not cheapen out by "relying on a tool". Of course, I keep it in my password manager as a record, but in daily use I absolutely do not say to the teller: oh I need to look it up. I recite to the bank my passphrase and other id confirmation by memorization, I know it even better than my own phone number.
If you need multiple people to log in, each person should have a different password, only memorized by that person alone.
If the person can't memorize it, I would say either change the design of the system or fire this person because "they had one job: to memorize and type in this password".
> You can save passkeys on your own network if you use Bitwarden or if you want, write your own solution.
And then google or whoever will block login because your device attestation flag (part of the spec) doesn't say the right version of Chrome or Android. Maybe the website just won't let you login with firefox anymore "because hackers use it".
Don't worry, Apple zeroes out their flag (for now) so you'll just have to pretend to be an Apple device to get in (for now). Assuming the service in question doesn't have an axe to grind with Apple anyway.
Android passkeys return `fmt:none` as well if you ask for an attestation certificate.
Its pretty weird to claim that this is a big lock-in risk when both of the major players are not supporting attestation certificates for consumer use cases.
And the one well known site (vanguard) that was requiring an attestation certificate no longer does.
How exactly does this work? I have Bitwarden and Firefox on Linux. I have been unable to get Passkeys to work at all, using either Bitwarden or my YubiKey. Is Firefox just not supported?
> The only reason why Big Tech have hyped up Passkeys this much
I can't think of any other reason Big Tech (and small tech, and medium tech, government, and the list goes on) would want to eliminate passwords, an insecure concept, to replace them with a form of proof of ownership.
> [not pasting full quote because ...] "And developers and users... ― Google"
> No, they do not! - Author
Certainly, many developers hate all of the reasons outlined by the quote from the ethereal identity known as the "Google". Many users hate them for the same reason, too, but for some reason the author doesn't believe that developers or users dislike the UX, security, or liability of passwords (the Author, here, is apparently speaking for upwards of 8 billion individuals -- as one of them, I can certainly make up my own mind, thanks).
> Passkeys also makes you more vulnerable to seizures of electronics and keys.
This is why it is important for devices, like the iPhone, have a quick way of putting themselves into a 'locked, require pin/pass' mode. Or just don't enable Face ID/similar biometrics for a 'master' password.
> And when it happens to you, Google will let you know that they reserve the right to terminate your account for any reason or no reason at all.
The ethereal Google can look at you funny and decide they will lock your account without any reason. I'm not sure what makes this situation any different. People commonly use their Chrome account, or Microsoft account, etc. in conjunction with the OS/browser's password manager. With passkeys, they're effectively in a _no worse_ state than they are today. If you want to argue about backups, these are likely the same individuals who wouldn't know why you'd need a backup to begin with.
FWIW, I agree that there shouldn't be vendor lock-in with any form of identity, but there doesn't seem to be a challenger that is willing to bring something forward that eliminates both the security nightmares that are passwords as well as being highly portable with no vendor tie-in which finally, is easy to use. Big Tech found "secure" and "easy to use" which is what users are going to flock to.
I could not disagree more strongly. Giving large corporations (and governments effectively) the power to control my access to 3rd party resources is totally unacceptable.
> I got a Nitrokey3 to use as a hardware token, and ended up not being able to access my country's e-gov facilities, because L1 certification required.
What will likely happen is that many services will only accept passkey managers that have been blessed by big tech and locked down to the user. You're not going to be able to authenticate with your bank using an open source implementation.
Level 1 (I think they're talking FIDO?) is the bare minimum level. If Nitrokey aren't certified, there's plenty of open and proprietary keys not owned by "big tech" that are.
Well, currently, you can export your passwords between your new password managers. You may be able to do that with passkeys.
Also, passwords don't have rejecting [optionally, for now] non FIDO certified devices as a part of the spec. You'll have to use a Trusted(tm) passkey manager.
Fair enough — I've never done a bulk dump of my usernames/passwords, but I can understand how that's a problem for who do (until there's a common passkey interchange format, at least). One aspect of passkeys that may offset the impact of this is the ability to have multiple passkeys for an account, which isn't possible with passwords.
> Also, passwords don't have rejecting [optionally, for now] non FIDO certified devices as a part of the spec. You'll have to use a Trusted(tm) passkey manager.
Sorry, I may not be parsing this correctly: Are you saying that security requirements for pass[word|key] managers is bad? Or are you saying that they're bad because it means open-source solutions can't support passkeys, as @Ridj48dhsnsh suggests?
AIUI the concern is that you will only be able to use Passkeys that are held on devices that have been blessed. You will never get your custom solution blessed, so your access to your bank and government services will become dependent on being in good standing with Google. If your Google account gets deleted or your phone gets remotely deprovisioned, you will be unable to authenticate, and any attempt to create a "backup" against this situation that is fully under your control will be blocked by the attestation requirements.
> Users don't have the same life experience as security people and sometimes a user simply do not know how to verify a link on e.g. his iPhone.
Later...
> My password is mine. I control my password. I own my password. I am not dependent upon some third party closed proprietary operating system or device to handle my security. I would rather have a piece of paper with all my passwords written down, stored in a drawer at home
So the general public apparently lacks the ability to verify the url in an email, but _do not_ lack the ability to safely control their password? You completely ignore the ability of the site administrator to safely control your password by the way.
Altruistic as it may be to be anti-Big Tech, they are pushing the needle forward on cybersecurity. Looking at Apple, they invested millions into a special biometric device that ensures the fingerprint cannot be retrieved by *anyone*.
Also, I missed the part of this article where a quote was identified that hardware keys are for the entire population of the world? We do not roll keys out to every single employee - you're right about that. It's an interoperability nightmare. We do roll keys out to critical staff though. CEOs, COOs, high profile figures, critical service admins, etc. These folks are already trained and understand exactly why this initiative is so important; usually because they themselves have been targeted already.
Hardware keys are a great thing. I'm frankly getting really exhausted reading about how every new solution must be engineered to fit every single human of planet earth's needs. Its simply not designed with them in mind because they're simply not ready yet. It is what it is.
Nuclear power plants don't air gap controls because they hope the same system is used by Walmart down the street. They do it because their risk is... well... nuclear. Hardware keys in tech are no different.
My current workflow when I sign up for a website is to save my login and password to my password manager. This works across all platforms and browsers, and I use both Mac and Windows along with using both Safari and Firefox.
If I choose the passkey option Passkey stuff comes up on Safari and I’m 80% sure that means I can’t use that passkey with my PC? I don’t know how to make sure my passkey isn’t lost by switching devices.
Then what do I do if I use an embedded web browser like the one on a Steam Deck or Meta Quest? With my current workflow I can just reveal the credentials and type them in in a worst case scenario that my password manager can’t be installed on that device.
I have no idea what I am supposed to do, and this is even true despite the fact that I am aware that my chosen password manager supports passkeys.
If this is the learning curve the average person is supposed to contend with I am hesitant to migrate because something this difficult to figure out will never be mainstream.
I would welcome any of you to tell me how this is supposed to work.
Passkeys are at the beginning stages of support both from the perspective of platforms (OSes, browsers, passkey/password managers) and websites. e.g., Firefox is still figuring out how to support passkeys from OSes and passkey/password managers (e.g. https://connect.mozilla.org/t5/ideas/support-webauthn-passke...) and will likely (this part is just speculation) support Firefox sync as a passkey manager eventually.
This is why there is no major website that is requiring users to drop passwords yet. Nor am I aware of any that allow users to even choose to drop passwords yet.
> If I choose the passkey option Passkey stuff comes up on Safari and I’m 80% sure that means I can’t use that passkey with my PC? I don’t know how to make sure my passkey isn’t lost by switching devices.
If you're saving your passkeys to a credential manager (i.e. password & passkey manager), once there is support from Firefox and your credential manager of choice is plugged into any prerequisite APIs, you will be able to use your passkeys between Windows, Mac, iOS, Android, Safari, Firefox, etc.
Devices like Steam Deck, Meta Quest, smart TVs may require additional support added. I'm not super familiar with the platform, but Steam Deck should be fully capable of supporting passkeys through hybrid flow. If it is running a chromium browser and has Bluetooth support, it would be trivial to add support for hybrid flow with a phone as the authenticator (that is: the phone has the passkey and signs a challenge with Bluetooth assistance). Smart TVs already have in place methods to login using a local smart phone, tablet, or laptop (which would use the passkey). I can't speak for Meta Quest because I have literally no idea how that platform works.
---
As for the median user globally: the median global user has 1 device: their smartphone. Passkeys are so simple in that case. These users likely are not using any credential manager other than the one built in. Each of these major platforms (except maybe for some Chinese OSes that I'm not familiar with) already has recovery mechanisms in place for when users lose their device.
The next largest group has 2-5 devices, with basically all of them able to work just fine using the phone as a hybrid authenticator.
You are not a simple case. In fact, anyone that chooses to use a non-platform credential manager is not a simple case.
There are many reasons to secure logins with passkeys, but all of those reasons seem to be beaten by the costs of rolling it out. After all, breaches are someone else's problem. The company? They get a pittance fine, then carry on.
The people responsible? they get bonuses.
The only reason pass keys are being pushed so heavily is because they are another step in the direction of the customer/user having absolutely zero control over the hardware they own, and the software they use. If you doubt this, ask yourself why there's no way to look at your passkey in android? I haven't checked ios but I'll be surprised if it let's you just look at your own passkey.
Yes, pretty much. As the owner you should be able to look at the secret, copy it, publish it, whatever you want. At least with USB keys it is opt in. With passkey I'll be forced to give up my ownership because there are literally no viable options other than Google and Apple for smartphones.
This has a very "technically correct" feel to it, which doesn't actually translate into anything useful in the real world. If you think the very existence of HSMs threatens the concept of "ownership over your hardware", then I guess that's a view.
> With passkey I'll be forced to give up my ownership because there are literally no viable options other than Google and Apple for smartphones.
I use a password manager that supports passkeys so overall I don’t care.
However, I have two gripes with passkeys:
(1) the workflow for getting a passkey is all over the place; I wish it was more uniform, and
(2) diagnosability is crap. The QR-code-approve-on-your-phone workflow has never once worked for me (Brave on MacOS + iPhone)
The update at the bottom of the article is the most damning in my opinion. You can host your own, but unlike a password there is no promise that your self-hosted version will be compatible with a service.
I run a free, open source login provider[0] and have been keeping a close eye on passkeys. I think this article gets a bit too much into FUD territory. While big tech control over passkeys is certainly something that should be watched closely as we move forward, all signs currently are that the system will be relatively open to third party developers, including open source solutions.
That said, I have other concerns, especially when it comes to decentralized and self-hosted apps. The main problem is that passkeys don't offer any sort of an identity handle to use for granting access to someone who doesn't already have a passkey registered with your system. For example, if I have a self-hosted photo server, and I want to give a friend access to an album, I can simply grant access to friend@example.com. As long as they can prove they own that email address they can access the album. I'm not aware of any way to do this with passkeys. But big tech won't be equally affected. Google photos for example ties your passkey to your gmail address, so their users still get the convenience of semi-global user search and the extra security of passkeys.
IMO we need something more like Mozilla Persona that ties a global identifier such as an email address to a key pair. I'm curious if we could build a protocol around OpenPubkey[1] for this purpose. There may be a way to add this to passkeys but I suspect not given how tightly each passkey is tied to the domain it's created for.
I'm in on anything that prevents the "best practice" of entering new passwords that have esoteric standards of "strength", twice, BLIND, on a crap cellphone "keyboard".
The dots/stars for "password" type input fields might have prevented shoulder surfing in the days of wide-field-of-vision CRT monitors, and typing passwords twice on a real keyboard might have helped decrease people typing something they didn't mean, but it's all irrelevant in the age of narrow field LED cellphones held close to the face, using much smaller fonts.
The dot thing is actually a holdover from the days of printing terminals, where, if something wasn't done to hide them, passwords would be on paper in a trash can.
If you're going to drop secret masking, it at least needs to be optionally still available. Modern cameras can capture quite a lot od what's on today's bright, high contrast, high resolution, wide viewing angle screens from surprisingly far away.
Unless we're going to use a dark cloth on our phones as if they were an old view camera, I think secret masking still serves a purpose on phones.
Yes, they protect you from shoulder surfing, all twice in your life, where that may have been a factor. Otherwise, they are just an implement to the user, at this point.
None of my relatives care about remembering passwords, not even those more technically inclined. They create the password, and 30 seconds later forget they even did such a thing.
Someone even lost access to their iPhone 8 because after replacing the screen, they got a "This device is locked". But they could not remember their iCloud email and password, they didn't need to remember it. The phone worked fine for years without it. Now it's a perfectly functioning phone, but locked and useless.
The difference between "account" and "email" is also lost on them. Not a week goes by before someone needs to access a new site they need to register, and I get the same:
I already have this "gmail" thing, why do I need to create another gmail??
(because they have to use their email as the "username")
And this is the norm! Most devs creating these systems don't understand this.
A passkey sounds marvelous to me, it finally uses the thing that should be the password: the person itself. That is what a password should say after all:
yes, this is me, the person that owns this account
why do I need to tell you this mumbojumbo words and symbols to know that it's me? you have my face and finger data, match them please.
But that's only if it seamlessly supports biometrics like FaceID/TouchID/BrainwavesID-or-something, otherwise it will be just as useless.
> you have my face and finger data, match them please.
No thanks. A kidnapper or the government also has access to my face and fingerprints. As tech changes, usable biometric data will likely be captured by 3rd parties from a distance as well.
I'll stick with something that I know and at least have some limited constitutional protection from being forced to divulge.
That's not what passkeys are though. The server isn't validating if you have a matching face. The server is only checking if you have the private key that corresponds to a public key registered to your account. The private key lives on your device, and may be encrypted under a PIN, password, or biometric. In all those cases, the decryption operation is strictly local.
Let's say some crook makes a convincing copy of your face. With passkeys, that's still not enough to log in. They have to have your private key too.
I mean... bitwarden has passkey support already, so your not really beholden to google/microsoft etc for storing and generating keys as well so your not just stuck to using the MS Windows or Apple storage :S
They don’t currently but they say the feature is coming. All the passkey features in Bitwarden are very much half-baked at the moment as it is brand new.
On mobile you can’t even use the passkeys yet. They show up on mobile but no way to use them.
Genuinely curious: what's the use case that's solved by being able to back up a passkey?
Why is it not solved by simply registering multiple passkeys for your account context? Is it just friction of having to set it up multiple times per account?
Part of the concern is the friction of setting up on the order 100 accounts on an order of a dozen different devices over the next few year (I hadn't thought of that until you mentioned it), but its mostly that I don't trust any of the authentication providers to not accidentally lock me out of my own account.
Anyway, the immediate concrete use case for me is the same as being able to back up my password list:
If I lose all my devices (or, more likely, some cloud provider does what Google Drive did last week), then I can restore from the backup. Also, I've already arranged to be able to backup my password list and to store the backup in an offline / secure way. I don't want to set up a second account recovery path just for passkeys.
Finally, there's no data on any of my portable devices that I care about. I break a laptop or phone every N years, and I learned long ago to treat them as disposable. As currently implemented, passkeys break that invariant.
Claiming the ASCII ribbon campaign was racist is neither technically correct nor practically correct.
There weren't any machines that supported ASCII directly that late in the game. Instead, everything supported DOS code pages. Those are supersets of ASCII, and those supported localization. This was often called "ASCII", since that's pronounced with fewer syllables.
On top of that, by 1998, mainstream systems were starting to support UTF-8, and, as a superset of ASCII, it was treated like "just another" plain-text format / extended ASCII code page by software user interfaces of the time.
Practically speaking, the campaign was against sending HTML (or, god forbid, RTF) emails. That doesn't preclude localization at all.
the "ASCII ribbon" referred to a ribbon drawn as ASCII art, not an insistence that people use exclusively ASCII characters. Unicode is still plain text and supports any language you can think of, and also most languages you can't think of.
Yeah im sure people will use googles passkey storage, or apples passkey storage, but that was already happening with passwords too. Passkeys isn’t going to change that. Third party password managers are already adding support for passkeys. And OS support for third party passkeys is already there on mobile.
Personally I’m looking forward to passkeys. Just going to make my life a little bit easier. I’m going to continue using a self hosted vaultwarden instance. It already supports passkeys on desktop, and I’m eagerly awaiting mobile support for autofilling them. Hopefully that comes soon.