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.
Passkeys: The beginning of the end of the password
41–50 of 1001 posts
Re: Passkeys: The beginning of the end of the password
#42What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?
Re: Passkeys: The beginning of the end of the password
#43I 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…
For example: https://github.com/StrongKey/fido2
Re: Passkeys: The beginning of the end of the password
#44I 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…
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
#45How 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…
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
#46I'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…
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?
Re: Passkeys: The beginning of the end of the password
#48How 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.
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?
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?
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.