The article seems to focus on YubiKeys (even despite using a mac device), but at least in the Apple ecosystem the state of the art is far ahead of plugging in a thumb drive style device IMO.
When I navigate to various websites that support Passkeys these days - Lowes, Home Depot, and handfuls of others - on iPhone (firefox) I am prompted with 'Do you want to use Face ID to sign in?'
If I do the same on macOS (firefox or safari, I'm sure Chrome does it too.), I am similarly prompted 'Do you want to sign in using a passkey?' and it gives me steps to use my mac's fingerprint reader or delegate to the iPhone Face ID to sign in on my Mac.
Combine that with Apple offering to use a private/hidden email address for signing up to the service in the first place and forward mail to your real email, plus the auto-generated secure passwords stored in the new Apple password manager.. and it's a pretty magical and secure experience as a user.
I'm not at all sold on this experience for disaster-recovery reasons. I can put a backup Yubikey in a safe deposit box or other off-site location pretty easily and for relatively cheaply. I'm not gonna buy and put a backup laptop or iPhone in one.
If I lost all my devices in a natural disaster I want way to be able to get back in to accounts. And personally I don't want that to be cloud-dependent (bit of chicken-and-egg dependency story, it seems, plus a centralized weakness). I might be misunderstanding the device-as-passkey story, but the stuff I've read about it hasn't seemed to proactively answer that question.
When we implemented passkeys a few years ago[0], we chose to implement them as a purely secondary authentication method. So you had to have an account, then you added a passkey.
So you have the normal account recovery process if you need it, while you get the advantage of passkeys for improved, faster regular login.
That's obviously a tradeoff.
I wrote up a bit about this issue[1] last year but I think there's been some progress on standardizing backups of software passkey private keys[2]. The idea of syncing around a private key, no matter how protected it is, still makes me a bit queasy (as it seems you are) but I understand the motivation.
Hi, to answer your hypothetical situation, what I do is save my passwords on apple passwords, and use two yubikeys as the security keys for the apple account itself (cool fact, apple forces you to use two keys as a safeguard, which I think is pretty cool and haven’t seen anyone else doing).
Yeah, if your device is lost or destroyed and you rely on passkeys, you are well and truly f**ed. Your only hope is if you have recovery passwords stored in a password safe or manager. If you already have that safe or manager, than you can already very easily have 25+ character passphrases for every site you use, so what have passkeys gained you except having to be double-vigilant about having a recovery method for every login you create?
That’s not true. You can use iCloud keychain and have numerous recovery options, including other passkeys. A lost device is not a critical issue at all.
To your questions, the password safe can store passkeys as well. The entire point is to get to a place where we aren’t all dependent on some remote site’s security to keep our secrets safe. Why use a 25+ character password which can be compromised in a number of ways when a passkey doesn’t involve sending secrets at all?
a good passkey implementation allows multiple passkeys. you can have faceid on your mac, and you can also have a yubikey in a safe somewhere for disaster recovery.
also, passkeys get backed up in iCloud, so losing your device isn't really an issue. the disaster scenario is more what happens if apple locks you out of iCloud.
The main point of this article is that good implementations are few and far between
Most of my banks don’t support it at all, but the few that do still require SMS as a recovery mechanism. So it’s pretty pointless from a security standpoint.
Even O365 will keep pestering you to add a phone number for recovery if you go passwordless and remove your phone number. I think they may even force you to add it back in certain flows.
I think Apple has one the better impls and they went hard on account security after the rash of celebrity nudes were traced back to poor iCloud account hygiene. Recovery codes get sent to every device in the account with an option to decline, passkeys are first class citizens, and they don’t need to know my phone number for any of it
So whenever I create another account - I need to fetch all my yubikeys from remote locations to enroll them?
I mean if you have one or two accounts it's probably ok. My password manager contains hundreds of passwords. If I am to enroll hardware keys for each of them... Just no.
You need to be able to clone/copy/backup your keys. Enrolling multiple keys - is non solution.
I'm surprised you had a working experience with passkeys. Every time my iPhone asks me to use a Passkey I just get "something went wrong" or some obtuse error message. It has never worked a single time and I just gave up.
No, faceid unlocks a Cryptographic key stored in a TPM like device. Of someone can run arbitrary code on your iPhone, they can get it to unlock the TPM. If they can't, it would be challenging to fake FaceID right now. It uses a bunch of stuff, IR cameras, a depth camera I think, probably some kind of eularian video magnification for pulse detection. Possible to fake but expensive, probably need to hire some old-timers from industrial light and magic to do it with practical effects.
Or you mean literally hold the iPhone to your face, in which case they'd also need to force you to keep your eyes open. The greatest weakness of cryptography has always been that you can beat someone with a five dollar wrench until they unlock the system.
Phones have a TPM just like a USB security key. The face id on a phone based passkey is just the equivalent of pushing the button on the yubikeys.
So they need the physical device. You cannot clone the TPM parts that are in newer phones. The faceID just unlocks that hardware on your phone in the same way pushing the button on a yubikey sends the key up.
1) The FaceID TPM is connected to the phone all of the time, whereas you only plug the Yubkey TPM into your computer when you need it.
2) The Biometric data that the FaceID TPM collects is available pretty much all the time when you use the phone. It's not like a fingerprint sensor where you would have to go out of your way to press your finger to it. If you can hijack the OS silently, then you can probably hijack FaceID silently.
It just seems backwards to me to replace a "simple" hardware token that you have to physically plug in with a massively complex internet-connected device. If someone steals your hardware token, you know.
I think a lot of people in this thread are assuming passkeys are passwordless. They are just the latest way to do what we used to need an external Yubikey for.
You can still set the settings on individual sites to ask for a password when using a security key (external USB or device based) if that's where your concern is. The whole 'skip password' thing was just there as a convenience for people who aren't worrying about physical and biometric access but do want the two factor auth (protection against phishing, by far the most common threat).
You can also set your phones unlock how you want too if you don't want faceID.
it unlocks the cryptographically secure device, it doesn't replace it. to access your passkey through faceid, they have to steal your phone, unlock your phone, and then spoof faceID.
Passkeys won't fully replace passwords. There's one glaring reason why: theft or seizure.
You do not currently need to unlock your phone, computer, or internet accounts for law enforcement though the legality is fluid. But with a passkey I cannot imagine law enforcement exercising any restraint.
The same goes for any one else seeking access to your accounts or computer.
Sure, there are other ways to get that information but I'd imagine it's better to let them use those.
I am not sure what you are saying. If you use Apple's passkey implementation, you need to unlock your computer and when using a passkey confirm with Touch ID (or Face ID on iPhone). So, if you don't need to unlock your phone, computer, or internet accounts for law enforcement, they also can't get your passkeys.
Using a USB stick as a passkey without authentication is just a bad idea.
Ps. passkeys are end-to-end encrypted on Apple devices using iCloud keychain. Sure, Apple could push a software update that exfiltrates your passkeys, but in the end you need a trust anchor somewhere in the chain.
Legally, you may not be compelled to provide a password. But the same is not quite as true for biometric attestations. First, a cop can physically use your face or finger to unlock your device without your consent. Second, legally they are allowed to compel you to unlock devices with these measures.
I think what they're saying is that when someone wants to use your password-locked device, they can threaten you with jail/obstruction of justice/beating/bullet, depending on where on the Law vs Chaos axis of the alignment chart they fall; you will then give them your password, and escape the extremely dangerous situation you found yourself in.
With passkeys, unfortunately, they'll have to keep you around for all their exploits, and may need to regularly re-threaten/beat you into submission.
In certain scenarios, there's such thing as too much security.
Pointing out one good passkey implementation does not mean we should remove memorized secret non-physical passwords as security.
A physical pass key can have all the biometrics in the world and be completely unprotected from law enforcement. Requiring multiple devices is useless if all devices can be unlocked with things I can see you carrying.
On iPhones, simply holding the volume up and power button for five seconds disables Face ID just like a reboot. If you have that long, it’s all you need to do.
One gives stored records (including auto-typing) and 2FA.
One gives a second bank of records et al.
The third is a duress key which wipes the device.
Also, you can reflash your data to it from an encrypted backup in case you do use the duress PIN or lose the device.
I think it's pretty cool to put the key in, type an eight digit code, then press a button to type my Amazon/GMail login page into a browser bar, enter username, enter password, wait for the page to load, then enter the 2FA. All automatically.
It says it is “open source”? Does that mean the firmware can be updated? One of the best things about yubikeys is that they cannot be updated. A physical device like this that can be updated seems like you are one exploit away.
Agreed. I don't want my credentials tied to a device if that device isn't small and robust. The lifetime of my Yubikeys is at least 3 times that of my usual phone as well. And if they fail, I have recovery options.
Apples/Googles ecosystems are intransparent and not really portable.
Personally I am not really a fan of passkeys. Sure, login is hassle-free, but I am used to remember several passwords and their variants.
Everyone knows how USB security keys work and now we have a slightly newer standard that new USB security keys use but also we can use devices with a TPM such as phones to avoid having to plug in a separate USB key. And now everyone's acting confused about it since there's also an optional ability to skip entering a password and just use the passkey in some circumstances but that part is not what a passkey is.
Passkeys are great, the implementation where they're intentionally kept from the user and managed by a 3rd party OS vendor is disappointing. Going from "it's an okay supplementary auth mechanism" to "password manager for the masses" would be so easy for Apple and Google, just let the users access and export them dammit!
People would call a password manager that considered its user to be an adversary and refused to show the owner their own passwords mad but that's what we have. Passkeys in my Bitwarden strike the right balance for me— I can use them everywhere, they can be backed up, they're vendor agnostic.
Any "password manager" system from a service which disclaims responsibility for security or which can cancel the account is worse than useless. It's dangerous.
A password manager run by a bank, with the bank standing behind it, might be worth something.
Because that's an important part of security in the real world.
Crypto is cool and all, but also creates plenty of footguns and is overall annoying to deal with. Legal solutions plug into the wider system of how adults deal with the world - courts, insurance, and yes, men with guns. It's not as solid as purely mathematical solutions, but it is flexible in ways that matter to real people in real-life situations.
Anyway, GP's point was more that banks are known to be subject to regulation wrt. accounts, they can't just shut you out and pretend you were never there (in contrast to e.g. Google which can, and does). They're not allowed to be too big to care.
> banks are known to be subject to regulation wrt. accounts, they can't just shut you out and pretend you were never there (in contrast to e.g. Google which can, and does)
Exactly. Banks are required to have what's called fiduciary responsibility. They have legal obligations to fix their mistakes. They can't provide their services "as is, with no warranty".
A friend who runs a bank branch for a major bank says that about a quarter of her day is spent dealing with people who had some kind of error or scam problem. All routine transactions are automated, and there are only about two teller windows in a branch now. What bank branch staff actually do is sell loans, and customer support. That customer support is not optional. There are bank regulators who will punish banks if they don't do it.
that's fine for a bank now, because they more or less control have full control over the thing you're trusting them with (your money).
password managers are keys to all sorts of third party systems, in a sense they're more like safe deposit boxes, and you don't hear of many banks offering them these days, and they cap their liability quite a bit. Also, a financial transaction is relatively easy to rewind by the bank, everything else your passwords give access to, not so much.
So sure, you might not be locked out of your passwords, but you run a much higher risk of someone else also gaining access to them.
> Crypto is cool and all, but also creates plenty of footguns and is overall annoying to deal with. Legal solutions plug into the wider system of how adults deal with the world - courts, insurance, and yes, men with guns. It's not as solid as purely mathematical solutions, but it is flexible in ways that matter to real people in real-life situations.
Okay, so the bank runs a password manager and messes up the unimportant crypto part that's just kiddie stuff (math). As a result, some folks in $FAR_OFF_COUNTRY copy off all your passwords. How does the legal system protect you?
> For any locked door, you need more than one key and they should be independent. If you have independence, they serve as backups for each other.
For any locked door, you need a key for day-to-day use; beyond that, you need to know a way to contact a locksmith or how to use a crowbar yourself, and have a way to eventually prove you're authorized to access what's behind those doors.
All those real-world analogies in crypto tend to miss one critical thing: in real world, things break, and people make mistakes, so for any security system, there exist ways to recover from failure or mistakes, and ways to recover from failures to recover, and so on.
Yes, this means you may spend a couple hours talking to the police afterwards, but you won't be forced to camp outside of your apartment on a cold winter night, because you've left your keys at work.
There are real-world situations, particularly in remote areas, where you can't rely on someone else to bail you out if you screw up. But they're not typical, and yeah, the analogy breaks down if you push it too far.
I think the advice of having multiple independent ways to log into an account is still good. Unfortunately, Google doesn't provide backups for the threat model of "Google locks you out due to an automatic policy decision" so you have to figure it out on your own. Similarly for other services.
How is a password manager a single point of failure? Mine syncs between multiple devices. I've had the same primary password for a decade now, and I've already forgotten it... I can't reproduce it without putting fingers to keyboard. It's the one human-chosen password that I ever made strong... 30-some characters, pretty fucking random. My wife knows it too.
But now you'll tell me that Google is more trustworthy than her.
It depends on the password manager you use. If you’re using Google or Apple’s password manager, you’re probably okay if you lose a device, but the one risk you can’t fix without having another password manager is if they cancel your account.
If you use both of them, though, that covers it.
Passkey syncing across password managers isn’t implemented yet, so it means manually adding an account in both places if you go that route. Hopefully that will be fixed by a new standard.
> It depends on the password manager you use. If you’re using Google or Apple’s password manager,
Are those even really password managers? I used to use 1Password, but got tired of only being able to sync through iCloud. About a year in, I switched to Enpass since it did webdav. Biggest gripe is that there is no native Xbox app with it, make it a pain to track some of the kid's game passwords.
They store passwords, and now also passkeys. How are they not password managers?
They’re probably the most-used password managers, since people use them without necessarily realizing that they’re using a password manager.
The thing about passkeys is that they make everyone use a password manager whether they want to or not. It’s a protocol that requires a password manager - there is no manual way to do it.
> But it wouldn't something that could be stolen off bitwarden.
Hah. I'm not the only one thinking about ways to use AWS KMS for it!
But the attacker can still impersonate you and ask the HSM service to sign data for them.
Ideally, I really want a system with a proof of physical interaction. The existing HSM APIs are not well-suited for that. But if you can trust the software that runs on the service that provides the HSM access, then this can be done with minor caveats on macOS.
I caught my husband so many times through his chats and all about cheating on me and when i told him he always claims that he has changed and all. right now he hides his phone from me and i still guess he is cheating cause i could not break into his phone any more so i was referred to a hacker named FRED who i ran to for help and this hacker was able to break into his phone and proved me with the access to my husband phone without my spouse knowing about the hack. Right in my phone I have all my husband's daily activities . I got to read all his chats, texts, calls, WhatsApp, Facebook, and many more. This hacker is really great, thank you. Did you find this review helpful? contact him via Gmail FREDVAL CYBERGHOST @ GMA IL . COM and you can text,call him on +..1..51..77..98..18..08 or +..1..97..82..95..17..63
I caught my husband so many times through his chats and all about cheating on me and when i told him he always claims that he has changed and all. right now he hides his phone from me and i still guess he is cheating cause i could not break into his phone any more so i was referred to a hacker named FRED who i ran to for help and this hacker was able to break into his phone and proved me with the access to my husband phone without my spouse knowing about the hack. Right in my phone I have all my husband's daily activities . I got to read all his chats, texts, calls, WhatsApp, Facebook, and many more. This hacker is really great, thank you. Did you find this review helpful? contact him via Gmail fredvalcyberghost@gmail.com and you can text,call him on +15177981808 or +19782951763
Pass keys are a solution that will probably win, because it's very attractive to the device developers. They're portable, from one device to another, but only using the developer's private apis.
U2F is better cryptography - the device key never leaves, but this is precisely what makes it hard for users. Losing a U2F key is risky, yet you have to carry it around with you. You can do what I do - Have a second U2F device registered everywhere, so that if the travel one is lost,
But I just experienced the second pain- I had a phone die on me. This seriously messed up my life for a week - every provider that used phone verification or text verification was inaccessible.
As developers, I beg you not to go to exclusive Passkey support. Keep UN/PW/U2F support around, and support multiple second factors.
Really, the problem is as simple as this: there's way too many bad actors, they have knowledge of tech, and little risk.
I’m writing this review to sincerely thank Galaxy ethical tech Recovery Services for their exceptional work in assisting me in getting my lost Bitcoin investment back. I lost $250,000 in cryptocurrencies as a result of falling victim to an online hoax, which was a severe emotional and financial blow. Fortunately, when looking through my options online, I found Galaxy ethical tech Recovery Services. I made the decision to get in touch, and after our initial conversation, I knew I was in good hands. In addition to being competent, the staff at Galaxy ethical tech Recovery Services was sympathetic and recognized the pain I was experiencing. They guided me through every stage of the procedure, outlining their plans and the actions they would take to get my money back. I valued their openness and commitment, which increased my confidence in the healing process. I was astounded by how hard the staff worked to find my investment in such a short amount of time. I was informed on a regular basis, and I could see they were dedicated to their goal. I was shocked to learn that Galaxy ethical tech had successfully retrieved my $250,000 Bitcoin investment from the swindle artist! The relief and joy I experienced upon getting my money back are beyond words. Galaxy ethical tech Recovery In addition to helping me recover my financial loss, gave me hope that justice would be served in the face of deceit. Throughout the entire process, their professionalism, knowledge, and sincere concern for their clients were clear to see. Contact them today via email: (galaxyethicaltech@mail.com).
what app; +15072712442
So far, my experience with passkeys has been disappointing:
- Many major websites implement passkeys in a hybrid way that you can keep logging in using your password (Amazon comes to mind). That actually kills the greatest security feature of passkeys: resistance against phishing. As a counterexample, Microsoft has implemented it as "passwordless", and kills password login fully when you opt-in, but that seems to be the minority of the platforms right now.
- UX is worse. On almost all login forms, you have to click on "Sign in with a passkey" button to go through an extra step in the authentication flow, making passkey signing option more work than a password login with a password manager. That also means you must know if you had enabled passkeys on that website. There is no familiar UI design for that either, you have to explore every login form to find out its passkey mode. Password managers like 1Password can detect passkey sign-in options and show up a popup to log you in, but that's mostly a case-by-case hack, as I understand.
- Despite that the authentication mechanism is very well-defined, the account recovery flow isn't. I don't know how much risk I'm putting myself into by signing into passkey flow. If I login to everything using a passkey, including my email, how much risk am I getting myself into if I lose my passkey provider account? How do I recover my account then? Is that flow also phishing/scam resistant?
- The story of 2FA is bleak. Now that I have a strong authentication scheme, can I safely do away with 2FA? I can't really tell anymore because the risk model has more dependencies now. If 2FA isn't eliminated, and password login is still allowed, what do passkeys gain us by any metric?
Unfortunately, the design of passkeys push them to password managers instead of physical tokens. Physical passkeys are dangerous because you can lose them. The solution would be to add multiple keys, but that is hard to do. It would be nice to be able to add multiple keys at once. Or add a key that isn't present to have off-site backup.
The result is that need a password manager to store the passkeys. Then passkeys turn into better, more annoying, non-phishable passwords.
The general un-user-manageability of keys makes passkeys such a failure to start.
Ideally I'd want to be able to sign up and add three keys right away, backed by different devices stored in different places. At the moment though I'd need to relay around one key & go through each websites custom flow to add the next key.
This isn't going to work. This isn't viable. It's not enough.
If users could manage/export their own keys maybe they can send newly provisioned keys to off-site backups. But we still have to go navigate and provision extra keys on your website. There needs to be a way to present/enroll multiple keys all at once. And ideally standard endpoints for further management of passkeys on sites.
We are already seeing some very minimal client/website management-ish coordinations forming. WebAuthn is adding signals, so the client will know it can de-list some Passkeys that go inactive. https://groups.google.com/a/chromium.org/d/msgid/blink-dev/C...
Please take the added complexity and combinations seriously. App developers need to update their testing procedures to test all the combinations of login approaches over many different implementations (browsers, operating systems, hardware tokens, local vs remote, etc).
The traditional username, password flow could be tested once and work nearly everywhere.
As an example, I’ve been helping QA a webauthn issue on Wikipedia, that leads to potential account lock-out, due to passkeys not getting published to the various wiki sites completely. encountered <https://phabricator.wikimedia.org/T358771>
Fewer than 100 Wikipedia editors use webauthn , so the issue doesn’t receive much attention.
When implementing webauthn, QA testing , customer telemetry, customer onboarding & customer support all need much more investment to provide the same level of service.
According to the definition linked to by the Register article the passkey for a site is stored on my device. How do I log in to the site from a different device?
I have a Linux laptop, a Chromebook, and Android tablet, and two Android mobile. How does storing the passkey on one of these devices work?
I needed a fast response, I read about Fred Hacker and I actually saw a testimony like this about him and I decided to try him out. His approach alone showed his seriousness and professionalism,this hacker is a genius and highly recommended by a lot of people,it was very easy for him to help me spy on my spouse remotely for some token….I was very happy with the service he rendered I came here to testify for what he did for me and I’ll always be grateful to him…the least I could offer is referring him to you guys contact him on fredvalcyberghost@gmail.com and you can text,call him on +15177981808 or +19782951763
This. I figured passkeys had had enough time to mature, so I would look at starting the transition. Nope. Support is very uneven and - as the article says - needlessly confusing.
I'll wait another year. And I certainly would not inflict the current mess on a nontechnical person.
This article makes a good point about sites using passkeys alongside passwords, which basically renders them useless. But after that, it starts to read like AI slop.
The article also doesn't discuss how Google and Apple have decided to weaponize passkeys for their vendor lock-in wars. Google and Apple can fuck right off. How many stories have been posted here on HN about someone getting locked out of all their Google services for some stupid reason with zero recourse? Never put any of your eggs in that kind of basket. (And yes, I know there are alternatives. But normal users will never know about those.)
You can track your husband’s phone without knowing it effectively through TOMCYBERGHOST@GMAIL.COM. It’s fast, safe and easy. You get frequent updates about fits various activities and movements. If he really cheated, you will need quick proof
I may be too hung up on the FIDO2-ness of it all, and not paying enough attention to what they're trying to say about the particular configurations of the protocol are.
Right, passkeys are basically 1) a superset (FIDO2) of U2F that includes a passwordless option, and 2) software or "platform" rather than hardware or "roaming".
If akimbostrawman was knocking the passwordless part I agree. Partly for the obvious technical reasons, but also because in enterprise security 'passwordless' is being misused to market push-equivalent auth as 'phishing-resistant', and a lot of companies are falling for it.
If akimbostrawman was knocking the software part I disagree, because outside of companies like Google or Palantir IT teams aren't stoked about managing hardware tokens for tens or hundreds of thousands of people. The best option is the one people will actually use, and that's going to be passkeys.
sorry to be so pedantic, but passkeys is not a superset. All implementations and even the wording of the yubikeys creators say that it is the discoverable and passwordless option. See [1], i have not seen counter examples where they are wrong. However, webauthn does allow for the set of options you just referenced, i.e., FIDO2 including it's backwards compat with U2F.
Your mistake seems to be thinking that adding things to U2F credentials (here resident keys) doesn't make passkeys a superset, but that's what it does. Passkeys are U2F credentials with more stuff. The extra stuff makes passwordless possible, but whether it's allowed is up to the service. Either way, the user has a passkey.
The roaming vs. platform distinction is much more arguable. Common use has "passkey" meaning "passwordless-enabled platform authenticator", but technically hardware keys also fit the bill. I stick with the common use for pragmatic reasons, but either side can well-acktshually the other all day on this one.
When I navigate to various websites that support Passkeys these days - Lowes, Home Depot, and handfuls of others - on iPhone (firefox) I am prompted with 'Do you want to use Face ID to sign in?'
If I do the same on macOS (firefox or safari, I'm sure Chrome does it too.), I am similarly prompted 'Do you want to sign in using a passkey?' and it gives me steps to use my mac's fingerprint reader or delegate to the iPhone Face ID to sign in on my Mac.
Combine that with Apple offering to use a private/hidden email address for signing up to the service in the first place and forward mail to your real email, plus the auto-generated secure passwords stored in the new Apple password manager.. and it's a pretty magical and secure experience as a user.