Live data from Hacker News

The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

eff.org

11–20 of 38 posts

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#12
post #10

Anytime someone say password are not good I reply: can you change fingerprint? Can you change retinal imprint? How accessible are such data? => biometrics it's no good. n-th factor auth: how can we trust a token? I mean at a hardware level? => if we can really control it's a nice ADDITION to password protection, but no more. Other options like "granted third parties" (SSO solution by any kind, from Google to mobile p…

No one should ever be putting your biometrics in the cloud. Similar to a PIN, they are only used to secure a device locally once you've already authenticated. So eg you prove ownership of your email + phone number to authenticate, then save the token locally secured by a fingerprint.

For good implementations, it's not a naive token saved to the hard drive but a key saved to the enclave that's initialized during first auth. To crack that you need to get sufficiently advanced malware onto the device so that it can break open the enclave.

These both are significantly more secure than a password than anyone can spray against the target from anywhere and are subject to reuse.

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#13
How many years have we been hearing username/password auth is outdated and difficult and stupid and insecure? Fifteen? Twenty? Something like that at least, and I'm headbangingly tired of it. As tired as of the two factor idiocy popping up everywhere these days. Latest offender I've run into is Digital Ocean, who might otherwise have lured me back with a recent promotional offer. But no, they had to go and ruin it by plastering me with emails and codes and whatnot every single time I tried logging in, presumably because I like to get rid of my cookies the instance I leave a site.

Listen, passwords are not hard to use. Mine are 256 bit and utterly random everywhere they are allowed to be. I manage them responsibly. It's not a hassle, anyone can do it, there are great tools for the job. I do not want any centralised single sign-on solutions or other fancy hocus pocus, I do not need them, and I feel - increasingly - penalised for the laziness of those who can't be bothered.

So, in short, whatever this is about, I can only hope it fails like so many other attempts before it. The Log in with Google & Facebook buttons proliferating on every second site out there are plenty bad enough.

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#14
post #12
post #10

Anytime someone say password are not good I reply: can you change fingerprint? Can you change retinal imprint? How accessible are such data? => biometrics it's no good. n-th factor auth: how can we trust a token? I mean at a hardware level? => if we can really control it's a nice ADDITION to password protection, but no more. Other options like "granted third parties" (SSO solution by any kind, from Google to mobile p…

No one should ever be putting your biometrics in the cloud. Similar to a PIN, they are only used to secure a device locally once you've already authenticated. So eg you prove ownership of your email + phone number to authenticate, then save the token locally secured by a fingerprint. For good implementations, it's not a naive token saved to the hard drive but a key saved to the enclave that's initialized during first…

In the end what you say is really "I trust more my device and vendor then myself". Not really a concept I accept...

Of course too many lusers use IT devices even for serious work but consider their "luser" characteristic as a natural fact and instead of education prefer trusting a vendor for me is like preferring a dictatorship hoping that "it will be a good one" because people are not adult enough to be in a democracy.

A small classic example we all know "ok, you are authenticated because you have entered the correct username & password, now prove it a bit more typing an OTP I send to your mobile via SMS" can be easily read as: "I do not trust enough you because someone may have steal user & password BUT I consider enough unlikely that he/she/it steal also your mobile" and as a consequence it means that carriers/phones are considered more trusted than humans being. Not a good thing for me, not a thing I can accept despite, in limited case have some points.

Also I do not want my carrier know all the service I use and when I use them, it's a significant metadata leak that may be irrelevant in single case but may became relevant in other cases.

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#15
post #2

Why can't we use privatekeys as a way to log into websites? It's good enough for servers, and it's good enough for git access. I'd be way more comfortable about simply having my browser have access to a privatekey, and prompt me to use it to login when a webpage had a keyed login prompt. It seems like privatekey login would solve the problem of guessing & phishing passwords. (Someone plz fork Chromium and build this…

You can use a yubi key, or IMO better yet, a trezor crypto wallet(as unlike yubi, you can clone and restore it more easily with your seed words). Not sure how yubi works, but trezor generates deterministic passwords based on your private keys. Plus it's open source so I guess if they go bust you should be able to retain access to your passwords and to clone/restore ability forever.

Built into browser would be more user friendly, admittedly, but in my opinion this is quite good too, and arguably more secure as your private key is not exposed to your PC.

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#16
Phone numbers are awful for authentication. I stopped using my Russian phone number once I moved to the US and mobile carrier just reassigned that phone number to some other customer.

I found out when I saw myself in my Telegram contact list having other person's avatar and I assume people who had my old phone number in contacts also saw a new account in their Telegram contact lists under my name.

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#17
post #2

Why can't we use privatekeys as a way to log into websites? It's good enough for servers, and it's good enough for git access. I'd be way more comfortable about simply having my browser have access to a privatekey, and prompt me to use it to login when a webpage had a keyed login prompt. It seems like privatekey login would solve the problem of guessing & phishing passwords. (Someone plz fork Chromium and build this…

Client certs have existed for a long time. Most sites won't implement them without great demand from the user-base or specific security needs. This would also mean that sites would have to track all of your client certs from each device. The upside would be that you could tie a cert to a specific hardware device and serial number, which means someone getting your certs won't be useful to them. Microsoft does somethin…

This is used heavily in USG/DOD where everyone has a certificate thanks to HSPD-12

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#18
post #17

Earlier quoted context omitted.

Client certs have existed for a long time. Most sites won't implement them without great demand from the user-base or specific security needs. This would also mean that sites would have to track all of your client certs from each device. The upside would be that you could tie a cert to a specific hardware device and serial number, which means someone getting your certs won't be useful to them. Microsoft does somethin…

This is used heavily in USG/DOD where everyone has a certificate thanks to HSPD-12

I would fully expect some government sites to require client certs. Some DNS registrars also required client certs in addition to 2FA. Some payment systems also require them in addition to IP restrictions.

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#19
post #9
post #5

Earlier quoted context omitted.

WebAuthn does this, and chrome/FF/edge support this. They're also adding CTAP2 support allowing the use of biometric, BTLE, and NFC devices to provide authentication keys. Soon you'll be able to use TouchID to log in to your website, provided you've associated the pubkey from your fingerprint authn with your website. https://www.chromestatus.com/features#component%3A%20Blink%3... (TouchID on MacOS: TBD) https://bugs.…

So instead of password managers we'll have private key managers?

WebAuthn private keys don't exist at all outside of the physical token. So there's nothing to manage. If you rely on WebAuthn as an essential authentication step you'd have two or more tokens registered and treat those the same way you would house keys.

Re: The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords

#20
post #17

Earlier quoted context omitted.

This is used heavily in USG/DOD where everyone has a certificate thanks to HSPD-12

I would fully expect some government sites to require client certs. Some DNS registrars also required client certs in addition to 2FA. Some payment systems also require them in addition to IP restrictions.

HSPD-12 largely abolished passwords as authenticators throughout the executive branch.
Post reply on HN