Live data from Hacker News

Passkeys: The beginning of the end of the password

blog.google

41–50 of 1001 posts

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

#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 on your finger. That way if someone steals your phone or takes it, you are protected. The entire thing uses a unique pub/pri keys for each site. Keys are backed up by shamir secret sharing distributed across your friends or providers you select. 100% of your keys are encrypted so I the provider can't see it, recover it or be forced to reveal it. Since each site has a key, one could do interesting things. E2E encryption for apps where they can't be forced to reveal a key. If you are using an App and want to send someone a message, the app can fetch the person's pub key, then an inbuilt editor outside of the App in our app will be used to compose the message and encrypt it. That way the App provider can't be forced to reveal the message, and they don't have keys either. Pretty much control in the hands of the user. The same approach can be used for a storage pod where you have a pod that stores your data that you encrypt and control. This is a good start, hopefully we can see the good ideas of this, AT protocol (account portability), keybase, etc all start to bear fruit.

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. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.

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

#43
post #4

I hate this, I hate every part of this. The attempt to get rid of passwords has been the biggest assault on the free internet in recent history, and people are asleep at the wheel as it's happening. They want to tie you to an external service, so they can tie you to your phone, which they also manage with another external service. All of these schemes are braindead with obtuse, user-unfriendly backup/transfer/restore…

Nothing prevents anyone from creating an open-source implementation of the FIDO server/services.

For example: https://github.com/StrongKey/fido2

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

#44
post #28

I really wish these “password killers” would acknowledge that we will never eliminate passwords. Ever. There’s too many under-funded applications deployed out there that have no resources to add passkey support. Password managers are an excellent place to progressively enhance the user authentication story and could support more advanced schemes like passkeys while remaining compatible with the registry of deeds site…

Actually I'd see a future where some of those password killers might replace passwords, even for some of the under-funded, under-manned applications out there.

What is necessary is a robust, simple-to-integrate standard for authentication, authorization and sessions built into HTTP. Such that all the "hard work" is integrated into common HTTP server software or load balancers, transparently. From an application perspective it should just look like your request getting HTTP_USER=someone HTTP_PERMISSIONS="stuff,foo,bar" HTTP_SESSION="0xdeadbeef", similar to what you get from HTTP basic or negotiate auth, but with a few more necessary features such as session, login/out and a permission model. Browsers would have to provide some proper UI for that, not utter crap like they currently do for HTTP basic or negotiate auth.

Then your centralized auth application can just talk to any old application in a very simple way, no need to deal with huge integration headaches like OAuth or stuff. And the centralized auth application can do all the fancy password killer, 2FA, magic or whatever special auth you need.

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

#45
post #5

How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits. Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.

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

> The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.

Please provide evidence that biometric data has ever been extracted from a major platform (IE Apple/enclave). Absence of evidence != evidence of absence, I know, but you’re selling it as the only use case so surely you have proof.

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

#46

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…

I love this approach.

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

#47

> passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes. What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?

https://en.wikipedia.org/wiki/SIM_swap_scam

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

#48
post #5

How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits. Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.

This is more secure, passwords can't be stolen from the site. Sure, let's go with the assumption that your phone can be stolen. It would be only your phone. If a site has 100 million users, an attacker could steal 100 million passwords. With this approach, the attacker would have to steal 100 million phones. No matter what password manager you use, with a password length of 100 characters. The entire password list (encrypted) can be stolen.

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

#49

> passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes. What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?

Passkeys sign a web origin. If you try to phish one, the token you get won’t be valid for the origin you’re trying to authenticate to.

Eg you’ll get:

Token{domain:hax0r.net username:bob}

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

#50

> passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes. What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?

1. You're tricked into visiting evil.example and don't realize it.

2. evil.example: confirm 2fa code to log in.

3. evil.example starts logging into good.example as you, triggering good.example to send the 2fa code.

4. You see the 2fa code and enter it into evil.example.

5. evil.example has phished your 2fa code.

This doesn't work with passkeys (or 2fa tokens) because those verify the domain matches.

Post reply on HN