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

Passkeys: The beginning of the end of the password

blog.google

Post reply on HN
Print view View original

221–230 of 1001 posts

Re: Passkeys: The beginning of the end of the password

#221

Post by riversflow »

jmbwell wrote: post #83
Nextgrid wrote: post #67

How do you handle delegation in this case? Let's say I want to delegate access to my account to a partner/friend/employee on a service that doesn't support multiple users per account, charges extra for it or outright doesn't want me to delegate access to someone else (so it's not always possible to rely on the website's cooperation). Currently I can just message them the password or even write it down on a post-it no…

The accounts and services I use that support passkeys also support some form of account delegation, recovery contacts, legacy contacts, or family sharing. This includes Apple, Google, Microsoft, and self-hosted services through Authentik, Authelia, and Keycloak. My experience is not necessarily representative, but I am not sure how big the issue you describe would be, in practice, for the majority of users, who will…

> What is clearly a major issue for the majority of users is unauthorized account access and resource theft through the use of easily-phished account credentials protected by nothing more than a character string

Is this a major issue though? I think it’s pretty minor, not being able to share or backup my passwords is a pretty huge issue in my books.

Re: Passkeys: The beginning of the end of the password

#222

Post by r00fus »

segmondy wrote: post #41

I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/ . Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear o…

> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform.

This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device.

That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.

Re: Passkeys: The beginning of the end of the password

#223

Post by onlypositive »

lxgr wrote: post #153
segmondy wrote: post #41

I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/ . Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear o…

> use this to tether and lock you in to their platform. You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true. Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome insta…

Can I store the keys in bitwarden or am I stuck using google chrome to access this or whatever Mozilla cooks up?

I can't rely on retaining access to my Google account for logging into things.

Re: Passkeys: The beginning of the end of the password

#224

Post by judge2020 »

falcolas wrote: post #191
judge2020 wrote: post #129

Earlier quoted context omitted.

> but if you're the target audience for passkeys This is the difference. With the big players pushing it, including Apple instructing developers on the best way to integrate passkeys in their apps[0], it's going to overall shift more people from passwords to passkeys (especially when developers prioritize passkeys during signup). 0: https://developer.apple.com/documentation/authenticationserv...

I have... doubts. Already webauthn isn't prompting for passkeys on Apple. Chrome wants a bluetooth connection out of the box, and firefox does its own internal auth path that doesn't involve the OS. Chrome and Edge on Windows are the only ones that prompt me for passkeys today (Firefox tries to use Windows for auth, which throws up a scary prompt).

I don't follow for these

> Already webauthn isn't prompting for passkeys on Apple.

It does for me on iOS, at least (and Safari on MacOS; other browsers don't use the native icloud passkeys, chrome has its own secret store).

> Chrome wants a bluetooth connection out of the box,

IIRC it works without it for on-device passkeys, but caBLE requires Bluetooth to facilitate proximity passkey connections if you want to use wireless webauthn.

Re: Passkeys: The beginning of the end of the password

#225

Post by Springtime »

> And, unlike passwords, passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes.

It's a bit disappointing seeing them re-affirm SMS as a a more vulnerable form for 2FA when Google's stance has been to try and force a phone requirement on Google accounts that lack them in order to login—and then using the phone for SMS 2FA.

In the past number of years only after a phone is attached do other 2FA methods like TOTP become accessible as options.

However even when a phone is added Google continues to utilize SMS 2FA over them for what are deemed important actions like Takeaway or auth keys, in my experience.

This is despite known issues like SIM swapping, lock screen messages (viewable by anyone with device access) and due to the prevailing use of SMS for 2FA users have been prepped to accept security codes via messages which is arguably more exploitable than app-based TOTP in scams where fraudulent messages are known to be used alongside calls to mislead users into gaining trust then subsequently requesting a real 2FA message[1].

[1] https://robertheaton.com/almost-scammed/

Re: Passkeys: The beginning of the end of the password

#226

Post by nilsbunger »

pcthrowaway wrote: post #205
VoodooJuJu wrote: post #19

Earlier quoted context omitted.

>with a fingerprint, a face scan or a screen lock PIN I agree - not secure. And just a daily reminder that biometrics are usernames , they are not passwords. You can change a password, a lock, a key, you cannot change biometrics, and thus they should not be used for guarding sensitive info. The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate su…

Biometrics are shitty usernames too. They might change, it's just outside of your control. My apple touchID never works because I rock climb and I guess that abrades the skin too much

i rowed on a crew team for many years. The pads of my fingers were all worn down. I was rejected three times for "bad fingerprints" when applying for US citizenship.

Re: Passkeys: The beginning of the end of the password

#227

Post by michaelt »

voxic11 wrote: post #197
michaelt wrote: post #192

Earlier quoted context omitted.

The article says "Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN." Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs? As a user, that's sounding a lot like platform lock-in to me. And as a devel…

No passkeys are just normal private keys. You can store those private keys in a particular platform's secure key store which on phones can be decrypted/made usable when you unlock the device. But there is nothing stopping you from transferring these keys to a different device if you wish.

So if I transfer a passkey to my Yubikey, which has a single button and no pin, thus achieving 1-factor authentication - is that undetectable to the website?

Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained?

[1] https://developers.google.com/identity/passkeys

Re: Passkeys: The beginning of the end of the password

#229

Post by transpute »

lxgr wrote: post #180
transpute wrote: post #152

Earlier quoted context omitted.

> Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator Local-only iOS+macOS Codebook sync (open-source encrypted! by SQLCipher) provides password and TOTP convenience, durability, transparency, decentralization and fewer supply chain dependencies with one-time purchase. Founded in 2005. https://www.zetetic.net/codebook https://github.com/sqlcipher/sqlci…

> password and TOTP convenience Passwords and TOTPs are not MITM-safe, WebAuthN/Passkeys implicitly are. (Credentials are bound to a specific RP, i.e. it's impossible to accidentally provide one to the wrong website or a scammer on the phone.)

Codebook links passwords to specific websites/RPs. Some people don't take phone calls from random callers.

Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?

Re: Passkeys: The beginning of the end of the password

#230

Post by Scion9066 »

iLoveOncall wrote: post #208

> Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN. So, for the vast majority that does not have hardware that supports fingerprint reading or face-scanning, this grand new alternative to passwords is... passwords? I get that it's nice for phones, but that's only about 50% of the web's traffic.

If you don't use biometrics then it's passwords or passcodes to authenticate to the local device or a secondary device to unlock it. After that it uses public key cryptography to do the actual authentication with the site you're trying to log into. At no point does the site need to have access to anything secret, unlike traditional passwords.
Post reply on HN