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

111–120 of 154 posts

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

#111

Post by tzs »

Zababa wrote: post #109
tzs wrote: post #104

Earlier quoted context omitted.

> 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?

Probably not. I should have said directed acyclic graph.

Actually I guess it doesn't even have to acyclic. You just need a directed graph where that has a non-empty set R of nodes such that (1) nodes in R do not have incoming edges, and (2) every node that has an incoming edge can be reached by some path that starts in R.

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

#112

Post by pch00 »

probably_wrong wrote: post #77
pch00 wrote: post #57

Earlier quoted context omitted.

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.

> Google on the other hand, do this correctly. You can configure a consumer Google account to only have secure options listed. Are you sure about that? I couldn't activate 2FA in my Google account for years because they didn't enable the option without giving a phone number first. Based on my HN experience, many users gave their phone number from the get go and therefore didn't notice that they couldn't activate 2FA…

> Are you sure about that? I couldn't activate 2FA in my Google account for years because they didn't enable the option without giving a phone number first.

Just checked, and yes, no phone or email recovery methods configured.

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

#113

Post by counttheforks »

brookst wrote: post #108
counttheforks wrote: post #82

Earlier quoted context omitted.

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?

You can get a locksmith to come pick the lock

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

#114

Post by eep_social »

stavros wrote: post #79
NikolaNovak wrote: post #55

Earlier quoted context omitted.

I am in IT but not this side and I must admit I do not grok this move... At all. I don't understand the risk to Benefit story. It seems (possibly incorrectly) to put all my eggs into one basket - whether phone (which annoys the heck out of me as it is NOT my primary device) or some cloudy account I'm supposed to trust with my life. It also seems to impose geographical dependencies (I want to check my email at my frie…

> I feel like I'm an old grouch who wants things to stay the same... It does seem like it. The things you mention aren't drawbacks of this technology, and this is par for the course for whenever I see discourse on WebAuthn. People just mention random fears that they have, the vast majority of which aren't true.

As another old grouch, it’s on the experts to explain. They’re doing a piss poor job of it so far. “Just trust us” is deeply problematic.

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

#115

Post by eep_social »

Ajedi32 wrote: post #102

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…

> Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on. Passkeys also require that two-factor authentication is enabled for your Apple ID.

Nope, sorry. Enshittification makes this entire concept, as-presented, a non-starter.

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

#116

Post by eep_social »

probably_wrong wrote: post #77
pch00 wrote: post #57

Earlier quoted context omitted.

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.

> Google on the other hand, do this correctly. You can configure a consumer Google account to only have secure options listed. Are you sure about that? I couldn't activate 2FA in my Google account for years because they didn't enable the option without giving a phone number first. Based on my HN experience, many users gave their phone number from the get go and therefore didn't notice that they couldn't activate 2FA…

The trick with a newly created google account (assuming the regular account creation flow) is to give a phone number at signup and then remove it. There are some non-standard account creation workflows that used to work without a phone number at all but I haven’t tired recently and iirc the last time I did it didn’t take long for google to require me to “verify” my humanity with a phone number.

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

#117

Post by philsnow »

dvzk wrote: post #107
NikolaNovak wrote: post #98

Earlier quoted context omitted.

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…

> showing ID to a phone store clerk is sufficient for iCloud recovery

Can you walk me through how that works? I don't know how Verizon, for instance, could get me that access. Or did you mean at an Apple store or something?

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

#118

Post by philsnow »

eep_social wrote: post #115
Ajedi32 wrote: post #102

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…

> Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on. Passkeys also require that two-factor authentication is enabled for your Apple ID. Nope, sorry. Enshittification makes this entire concept, as-presented, a non-starter.

Which is the "shitty" part, 2FA on apple ID or iCloud Keychain? Both?

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

#119

Post by dvzk »

philsnow wrote: post #117
dvzk wrote: post #107

Earlier quoted context omitted.

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…

> showing ID to a phone store clerk is sufficient for iCloud recovery Can you walk me through how that works? I don't know how Verizon, for instance, could get me that access. Or did you mean at an Apple store or something?

https://support.apple.com/guide/security/escrow-security-for...

https://support.apple.com/guide/security/secure-icloud-keych...

https://support.apple.com/en-us/HT213305

Basically: For some subset of iCloud Keychain users, SMS is used in combination with the lost device's passcode (or a user-chosen password) to recover the keychain. Since the device is lost, you re-issue the phone number with a carrier. I think 2FA or ADP may require another device or a recovery key, but my memory is hazy on this.

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

#120

Post by philsnow »

traceroute66 wrote: post #32
throwaway290 wrote: post #22

Earlier quoted context omitted.

Complete noob, stupid question re keyloggers: when YubiKey inserts its token doesn't it go through the same mechanism as keyboard entry? if so keyloggers would work as before

> Complete noob, stupid question re keyloggers: when YubiKey inserts its token doesn't it go through the same mechanism as keyboard entry? It only uses the keyboard in the OTP mode[1] (which you don't have to use, and you can even configure to completely disable). I guess OTP mode is probably the one you were thinking of ? To be honest other than the Yubico demo website, I've never come across a resource in the wild…

> To be honest other than the Yubico demo website, I've never come across a resource in the wild that uses Yubikey OTP mode login anyway. :)

A company I worked at years ago used Pritunl as its VPN (which uses OpenVPN under the hood), with Yubico OTP configured.

It was a good-enough UX, and the user enrollment procedure downloads a certificate for connecting to OpenVPN which only works for one user, so when people inevitably spammed their Yubico OTPs into Slack, you couldn't use those to log in to the VPN as them since you wouldn't have their certificate.

A keylogger would probably be able to access the certificate. To get around that you'd need to do something completely out of band like acknowledge a push notification on an authenticator app on the user's phone.

Post reply on HN