Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The transition from logins to cryptographic passkeys is getting messy

wired.com

Post reply on HN
Print view View original

101–110 of 154 posts

Re: The transition from logins to cryptographic passkeys is getting messy

#101

Post by doodlesdev »

upofadown wrote: post #56

The root issue here is that most people do not know how identities based on public/private keys work. So the stuff about using bluetooth and and QR codes is just a pointless and meaningless ritual. If anything goes wrong the user will have no idea about what they should do to resolve that issue. They won't know what they have to do to prevent things from going wrong. The modern cryptography that this stuff is based o…

Maybe we should create a religion around cryptography and share the knowledge as sacred books, this way the knowledge won't be lost regardless of context or culture and will be subconsciously in everyone's minds (even the atheists since they will also be exposed to it).

Re: The transition from logins to cryptographic passkeys is getting messy

#102

Post by Ajedi32 »

It seems like most people commenting here don't know what passkeys are. I'm seeing a lot of complaints about things that simply aren't a problem with Passkeys, only with plain WebAuthn.

Passkeys are based on WebAuthn, but they are not the same from a user experience perspective. The simplest way to describe Passkeys would be "WebAuthn, but with the keys stored in a password manager instead of being tied to a specific device."

Apple has a pretty good overview of how things look from a user's perspective: https://support.apple.com/guide/iphone/sign-in-with-passkeys... Note that while that while that article is about Apple's specific implementation, passkeys are an open standard with multiple independent implementations.

The biggest issue with Passkeys right now (aside adoption by sites) is vendor lock in. Many implementations don't allow the key database to be exported or transferred to a different Passkey client. That's an issue with those implementations though, not an inherent problem with the protocol.

Re: The transition from logins to cryptographic passkeys is getting messy

#103

Post by jrochkind1 »

quesera wrote: post #97
jrochkind1 wrote: post #90

Earlier quoted context omitted.

i have a bunch of copies of my house key, including one at a neighbors house and one in a realtor-style lockbox in my back yard. If I somehow lose all of them, I can still call a locksmith who can re-key my locks for maybe $300ish. There is no conceivable circumstance in which losing my key(s), no matter how badly I mess up, even if I only had one copy and threw it in the ocean in a fit of rage, will permanently deny…

> and one in a realtor-style lockbox in my back yard FWIW be sure to assign proper expectations of security to those lockboxes, i.e. very very low. I make a hobby of defeating them at friends' houses. Takes a few minutes. The last time I sold a house, I brought the lockbox to the closing to hand to my real estate agent. He was perplexed.

> I make a hobby of defeating them at friends' houses. Takes a few minutes.

Fair and good warning, but I'm curious, how long would it take you to pick my front door lock instead? Are you saying those lockboxes are significantly easier to defeat than a standard front door lock? (I am genuinely curious! I imagine it could depend on both the particular brand/model of lockbox and door lock!)

(Plus I have bars on some basement and first-floor windows in places that aren't easily seen from the street so seem especially vulnerable, but not on all my windows, someone could always break a window instead. I do not live in a secure military facility).

Re: The transition from logins to cryptographic passkeys is getting messy

#104

Post by tzs »

jeroenhd wrote: post #33
_448 wrote: post #29

Oh, what could go wrong! Why is there no discussion on users losing their private keys? Ask all those cryptocurrency users who lost their private keys. Now don't tell that there are crypto wallets/vaults that manage private keys; there are many ways key can be lost even when using wallets/vaults. We engineers live in a different world, disconnected from the regular users who have no clue what public-private keys are!

The standard mantra for physical key-based 2FA has always been "register two keys and keep one in a safe", which seems doable for important accounts (like banks and government stuff) but no way am I going to get a key out of my safe when I want to order a replacement part on JoesDiscountDishwasherParts.biz. I really wish there was a way to register your backup key through your primary key. Luckily, FIDO2 can fix a lo…

> Having a business where you can go to a physical office and show up with ID so you can get your account back would solve this problem.

I've wanted something similar, combined with a tree approach to account recovery where the effort for recovery can vary depending on the importance of the account.

Say I lose access to my McDonald's account. That's not a very important account. It just contains some reward points that would get me some discounts at McDonald's. That account would be a leaf on the recovery tree. It's parent node would be my email account, currently at Fastmail. Recovery of my McDonald's account would just require responding to a recovery email McDonald's would send to my email.

My email account is much more important. Its parent node would be my domain name, currently registered at Namecheap. Recovery of my email account at Fastmail would involve demonstrating to Fastmail that I control my email domain.

My domain name is so important, since it is in the ultimate recovery path for so many descendant nodes, it would probably have at least two parent nodes (I didn't say anything about the tree having to be a binary tree).

They would be businesses that can verify my ID in person using government documents like my passport, and provide a way for me to prove that identity to third parties.

Banks would be good candidates to run such a business. Post offices would also be good candidates.

The protocol between the root verifiers and their direct child nodes could be a zero knowledge protocol so that the child node doesn't get your real identity and the root verifier doesn't know who the child node is. All the root needs to learn is that you are being verified for some site, and all the site needs to learn is that you are the same person who set up the account.

Such a zero knowledge protocol could also be good for age verification, which more and more jurisdictions are requiring from some sites. With such a protocol between the age verifiers and the sites you could have age verification without giving up anonymous accounts.

Re: The transition from logins to cryptographic passkeys is getting messy

#105

Post by flangola7 »

GTP wrote: post #85
pqs wrote: post #59

Earlier quoted context omitted.

If I lose the keys to my house, I break the window, enter the house and change the lock. If I use my digital keys, It's over.

That's why you're always advised to have a backup passkey.

If you are homeless or your current housing is unstable or unsafe what do you do? Not everyone has a safe place to keep physical objects. Homeless individuals already have communication issues because they usually don't have a reliable long term phone or phone number.

Re: The transition from logins to cryptographic passkeys is getting messy

#106

Post by madbury »

_448 wrote: post #29

Oh, what could go wrong! Why is there no discussion on users losing their private keys? Ask all those cryptocurrency users who lost their private keys. Now don't tell that there are crypto wallets/vaults that manage private keys; there are many ways key can be lost even when using wallets/vaults. We engineers live in a different world, disconnected from the regular users who have no clue what public-private keys are!

I run a company that cracks passwords for people that have lost the passwords to their crypto wallets.

Since the early days in Bitcoin people have been talking about backing up their private keys, and the methods of doing that have become simpler and simpler. Yet we talk to people every day that didn't realize that they can't just "contact Bitcoin" and ask them to reset their password.

Some platforms for creating "secure" backups of wallets apparently had back doors built in (BitcoinPaperWallet dot com I'm looking at you!)

A non-trivial portion of the population (based on my personal experience) is struggling with mental health issues and true analytical weaknesses that make it really hard for them to understand what's happening, or correctly recall what did happen.

Is all of that really compatible with moving secrets into the background (instead of remembering passwords)?

Re: The transition from logins to cryptographic passkeys is getting messy

#107

Post by dvzk »

NikolaNovak wrote: post #98
nixpulvis wrote: post #80

Earlier quoted context omitted.

I guess it's tricky because at work, a central secret store with permissions and some kind of audit trail is a good idea. At home some cloud backup / syncing should be done, but I don't think that replaces local backups and everything. What's the issue here, people can't export backups of the passkeys?

I think the issue here is we don't understand how to. I can, and do, backup and safeguard my KeePass database in ways many and various. I have a fairly robust system to backup "traditional stuff" - including sync to my local NAS, a monthly off-site exchange of external drives with my best friend, and a cloud sync. I have NO clue how to backup my whatever this is keystore or database or whatever, in a way that I'll fe…

Passkey objects on macOS are encrypted at rest within the iCloud Keychain sqlite database in Library/Keychains/*/. It shouldn't be too hard to adapt the keychain extraction tools that exist.

I don't know why you would want to though. Since (1) passkeys will rarely be a required nonreissuable credential, and (2) losing access to iCloud Keychain is extremely improbable. For many users, showing ID to a phone store clerk is sufficient for iCloud recovery. For others, it's using their laptop, a recovery key, or a recovery contact.

Re: The transition from logins to cryptographic passkeys is getting messy

#108

Post by brookst »

counttheforks wrote: post #82
brookst wrote: post #78

Earlier quoted context omitted.

Wow. You are definitely many standard deviations from the norm! But all of these digital techniques also allow multiple keys and / or key recovery.

Nah, I think you might be. Most people I know have locked themselves out once or twice.

Like, to the point of having to replace locks?

Re: The transition from logins to cryptographic passkeys is getting messy

#109

Post by Zababa »

tzs wrote: post #104
jeroenhd wrote: post #33

Earlier quoted context omitted.

The standard mantra for physical key-based 2FA has always been "register two keys and keep one in a safe", which seems doable for important accounts (like banks and government stuff) but no way am I going to get a key out of my safe when I want to order a replacement part on JoesDiscountDishwasherParts.biz. I really wish there was a way to register your backup key through your primary key. Luckily, FIDO2 can fix a lo…

> Having a business where you can go to a physical office and show up with ID so you can get your account back would solve this problem. I've wanted something similar, combined with a tree approach to account recovery where the effort for recovery can vary depending on the importance of the account. Say I lose access to my McDonald's account. That's not a very important account. It just contains some reward points th…

> My domain name is so important, since it is in the ultimate recovery path for so many descendant nodes, it would probably have at least two parent nodes (I didn't say anything about the tree having to be a binary tree).

If your domain name can have multiple descendant nodes and multiple parent nodes, is that still a tree?

Re: The transition from logins to cryptographic passkeys is getting messy

#110

Post by sdflhasjd »

pch00 wrote: post #57
crooked-v wrote: post #24

I can't wait for companies to use secure passkeys and still force me to use SMS 2FA with no option to disable it.

Microsoft "consumer" (live.com, etc) accounts are like this. They have a whole set of advanced, secure options like security keys, TOTP, etc but they force you to have either an email or SMS recovery option configured :( Google on the other hand, do this correctly. You can configure a consumer Google account to only have secure options listed.

They're even worse because, last time I checked, they are effectively a single factor as you could use them for resets.
Post reply on HN