Hacker News new | past | comments | ask | show | jobs | submit login
The Devil Is in the Details of Project Verify’s Goal to Eliminate Passwords (eff.org)
90 points by DiabloD3 on Oct 4, 2018 | hide | past | favorite | 36 comments



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.


In Australia it's outright common to have recycled numbers. I've had a few. My work phone had to be given a new number 3 times in the first 6 months until I had a useable one, because I kept getting random calls at all hours of the day/night looking for people who weren't me. It's mostly for work phones for some reason (I assume they have a higher rotation of useage as employees come and go, and nearly all companies use the same provider, Telstra), but my brother got a number that was someone else's before him too so it does happen privately.

The idea of phone numbers being the prime authenticator is laughable. I'll actively avoid any service who ever does this.


There's simply no way I trust AT&T, Sprint, T-Mobile, and Verizon to secure my private information.


There's not even a way I would trust anyone else with my most private data except me.


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 in! And hit me up when you want me to make the Django/ExpressJS auth plugin for it.)


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.chromium.org/p/chromium/issues/detail?id=780078... (CTAP2: merged)

https://www.chromestatus.com/features/6288375388569600.

We're integrating webauthn for our medical clinics as a way to support easy, secure authentication without 2FA to reduce sharing of ipads with a session logged in.

More reading: https://duo.com/blog/developments-to-webauthn-and-the-fido2-...


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.


When you lose a house key it's pretty manageable to get a few locks changed, but it can be rather overwhelming to remember all the dozens of websites that have your auth details, and update them.


Good news. Like a house key, the FIDO keys are basically anonymous. So, as long as you didn't e.g. leave it with your wallet on a bus, or write on it with non-erasable marker "simongr3dal@example.com" losing the key is not that scary.

In fact, unlike a house key, the Security Key works fine for its new owner, they can register it to sign into their Facebook, or whatever, that will work fine. Facebook will have no idea it's your key, now it's their key.

If they know you're simongr3dal@example.com on Facebook then that's a problem, yes, as obviously they can sign in as you, but if it's so hard for you to remember what you signed up to, seems like it'll be pretty hard for a hypothetical finder to figure out too... "Hmm, I wonder if this random stranger was into Diaper Porn and Antique furniture?"


AKA "wallet"


Awesome!!


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 something like this for xbox "machine" accounts. Each device can have it's own password that is tied to that serial number. If leaked, the password (or cert in this case) is not useful anywhere else. This is similar in concept to tieing an ssh public key to a specific network or IP address, except it is a hardware identifier in this case.

Unpopular opinion disclaimer: Anything else pretty much requires tieing into some 3rd party auth service or hardware token which have their own issues, such as vendor lock-in, managing server side libraries, leaking usage data to 3rd party providers, creating weak-chain back-doors to 3rd party vendors, privacy violations, etc.. I know those are all the rage right now among technical folk, but the general public adoption is quite low. Passwords will be around for a very long time.


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.


Hopefully all of their authentication methods are hosted in-house, on-prem and not outsourced or outside of secure boundaries. Everything has a back-door these days and leaks like a waterfall. :-)


A lot of the authentication is TLS client certificate authentication, SAML hosted by internal SAML IdP systems (such as ADFS) for web stuff.

For most other things Kerberos (via PKINIT) is used.

SSH authentication X.509 using PKIXSSH is rarely used since it is not a standard part of any operating systems used. For SSH, typically either Kerberos or SSH keys based on the RSA keys used by the certificates.


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.


This is what you're doing when you use U2F, right?

Also see: https://w3c-ccg.github.io/did-spec/



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.


I find it very troubling how small/nonexistent the outcry is over such an invasive concept.

The PR teams are already hard at work making Facebookian claims of user privacy control that were found to be grossly untrue.

I personally will need to be diligent in avoiding the firms that adopt this service at all costs.

Furthermore, you have to wonder why seemingly “competitive” entities(as far as an oligopoly goes) would collude to provide such as service. Their motives have already been demonstrated to be bad in the past.

Further reading (if you haven’t already): https://krebsonsecurity.com/2018/09/u-s-mobile-giants-want-t...


I am going to start suing everyone for negligence - or whatever applicable term my lawyers can think of - if they force me to use SMS authentication with no other OTP alternative.


I move country every month or so at the moment. Since telecom providers choose to charge vast sums of money for roaming, I have to get a new sim card in each country. So this whole system is just not going to work for me.

It also means that my phone number is meaningless. I never answer it, as I only use messaging (or messaging calls) to talk to people. But this isn't unique to my situation. A lot of non-roaming friends are the same - they never use phone or even SMS any more. The only people who phone using your number are spammers, scammers and marketroids.

I'm an edge case, but what of someone going on holiday for two weeks? At the moment, they still get a local SIM, because it's massively cheaper than roaming. This would prevent that.

Maybe that's the point - the telecoms companies need a way to keep us locked to our SIMs so we can't switch providers at the drop of a hat.


Same here. Even if I am not a frequent roamer, I changed country every now and then.

Whatsapp already shows how painful is to use ephemeral phone numbers as identity: when you change your number, even with their migration procedure, you still have to notify all your contacts, because at most numbers are authentication, not identification. Doesn't strike me as unusual however that corporations with obsession on control and snooping are trying to conflate the two.


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 phone auth) IMVHO can be trusted LESS than passwords. So in the end we only need to teach XKcd password strength vignette and teach developer how to care about security.


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.


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.


So write down the secret OTP key, do the crypto yourself with a pen and paper, or failing that with any device (laptop, hardware TOTP device) you own, using open source software, or build your own using the standard. It's nothing to do with your phone or carrier.


I simply do not need such kind of authentication for myself, at least I do the best to avoid such need.

Try to think of a Plan9-like world, which means user-centered not "modern mainframe centered". We still need services, but there is no need to have them like today.


So don't do SMS OTP and use an authenticator app instead, which is more secure.

And inflammatory comments aside, yes, any good IT org should believe that it's more likely for a user to be phished and give away their super secure xkcd based password than it is for a nation-state attacker to target their phone OS with a 0day.


Try to think about different scenarios: first not a nation vs nation attack but a simple dictatorship attack against some opponent, something like "hey see! This bad guy have done many criminal thing". Also think about what kind of situation we have today with anything based on few proprietary hardware and software commonly used anywhere.

After think about ancient Plan9 model which put your personal workstation at the center of the world and "services" only as "addition" to it. In this scenario need of auth, risk of phishing etc substantially vanish.


> No one should ever be putting your biometrics in the cloud.

They are likely already there. Ever had to provide fingerprints for an employment background check or security clearance? They have likely been leaked, along with all your other personal history.


Fair - to be pedantic, no IDP should accept your biometrics as a credential on its own, addressable from anywhere on the internet.

The goal is that an attacker has to steal your physical device and get access to your biometrics, which is significantly more work than spraying aardvark to zebra against an ROPC endpoint.


> So in the end we only need to teach XKcd password strength vignette

I hate seeing XKCD style passwords being advocated like this all the time. If I know your password is “four English words”, it’s pretty much game over. While there are well over 100,000+ English words, the average English speaking person would draw from a list of about 5,000. 5,000^4 is only 625 trillion combinations. With GPU based password cracking easily topping 150B/sec these days (depending on algo), you can see how this isn’t as secure as you’d otherwise think.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: