Troy Hunt on Passwords

Troy Hunt has a good essay about why passwords are here to stay, despite all their security problems:

This is why passwords aren’t going anywhere in the foreseeable future and why [insert thing here] isn’t going to kill them. No amount of focusing on how bad passwords are or how many accounts have been breached or what it costs when people can’t access their accounts is going to change that. Nor will the technical prowess of [insert thing here] change the discussion because it simply can’t compete with passwords on that one metric organisations are so focused on: usability. Sure, there’ll be edge cases and certainly there remain scenarios where higher-friction can be justified due to either the nature of the asset being protected or the demographic of the audience, but you’re not about to see your everyday e-commerce, social media or even banking sites changing en mass.

He rightly points out that biometric authentication systems—like Apple’s Face ID and fingerprint authentication—augment passwords rather than replace them. And I want to add that good two-factor systems, like Duo, also augment passwords rather than replace them.

Hacker News thread.

Tags: , ,

Posted on November 5, 2018 at 10:24 AM • 30 Comments

Comments

Clive Robinson • November 5, 2018 11:06 AM

Yes passwords are here to stay, and with it “low entropy” that can all to frequently lead to security issues.

However many fail to consider the changes in the way the legal system works these days which is why passwords are going to hang around for a very long time. When you talk about “multifactor authentication” the “something you have” and “something you are” factors are taken away from you by the law. That is you have lost control of them legaly thus in that respect they are now useless privacy measures from an intrusive State, which they are all becoming these days.

This only leaves you the “something you know” factor under your control. The law can not take it away from you it can only coerce you where it is reasonable to do so. That is imprisonment by “contempt of court” or direct legislation.

The thing is that as normall the legislators are well behind the curve on this because of the “reasonable to do so” requirment, and that all jurisdictions actually have limits (even the US can not make it’s definition of the law stand in other places such ad Russia, China, and a whole list of places.

As I’ve explained before there are other things you know other than passwords that can be leveraged so that it is nolonger “reasonable”.

Thus passwords and “fast time outs” are just the first line of defence to protecting your privacy.

@quuux • November 5, 2018 11:09 AM

Usability rules: yes.

X not having it: no.

People have been accustomed to handle carved metal pieces, AKA keys. Works fine for everybody with a hand. Anything with a similar way of handling like a physical key will find similar acceptance, IMHO.

The closest I currently got are contactless tokens plus NFC reader; not perfect yet, but works for many purposes. And if people can put the tokens on their keyrings, acceptance is good. Similar thing with Smartphones and NFC.
I’m not convinced FIDO is the solution, though.
But annoyance (and risk->damage on reuse) from an ever-increasing number of passwords makes improvements likely, one way or the other.

Just my 0.02€.
Quuux

Alain Coetmeur • November 5, 2018 1:31 PM

Even if we do all we can to kill password, they are there to stay at least for the majority of usages, however individually we can avoid the troubles.

With a password management tools, using a second factor, a really strong, complex/long, seldom updated not to forget it and thus store it, we can replace all other passwords with generated passwords.
In a way it generates a kind of personal identity federation, with strong authentication.

The big advantage is that you don’t need to ask each application to update to 2FC, to protect your password. Each application can have the (weak) security you accept, without endangering others (you trust more). You are doing your own SSO, choosing if you use SMS, software OATH, hardware OATH, FIDO U2F, and choosing the level of security of your provider…

You concentrate the risks, but can you do something else ? Impossible to memorize 500 passwords that are not in fact a single one with an algorithm, eventually leaking your algorithm on a loose site.

Does my position look rational, or unduly risky?

Timothy • November 5, 2018 1:37 PM

Because it’s actually important that the onerous tv remote not deprecate service availability, Netflix has found the balance on password length and complexity for people logging on to their tv: “Your password must be between 4 and 60 characters and may not contain a tilde (~).”

aperu • November 5, 2018 2:23 PM

Hello!

Mr Schneier, I am a fan but have never posted before (I’m shy… 🙂 but the topic was to good to ignore.

I don’t like the movement to eliminate the password and replace it with unique biometrics means. Not bueno… Why introduce unnecessary risk? can the password method be BETTER???

I like having the last word when it comes to access so I’m working on a solution. I like this site so I thought I share my prototype with the community and see what you guys think? http://dtroid.com/xologate/demo/

BTW… the objective is to go beyond the keyboard and de-standardize the password with alphanumeric & custom object options.

Steve • November 5, 2018 2:26 PM

I’d love to use U2F or 2FA.

Own 3 different devices, but only 1 (FSA FOB) works with Android (no USB) and the other 2 are different Yubikeys. By policy, Google, and Github and other cloudy providers won’t enable U2F without an SMS-capable phone provided first.

Contacted github about this policy and had an email exchange with a real person. Very professional, but they weren’t going to change their policy.

There is NO FREAKIN’ way to contact google. I’ve had issues with a Nexus phone and with multiple chromebooks. Their “support forums” were useless. Issues were closed without resolution and whatever some other forum leader decided as “the best answer” was posted, though those answers NEVER worked.

Setup my nextcloud server to use U2F. It was really easy, but it is either on or off for a userid. That means tablets and phones cannot access the service when it is available.

I previously owned an NFC capable Nexus phone, but my testing of the yubikey NFC authentication would only about 10% of the time. It was sad, really.

IME.

Humdee • November 5, 2018 3:46 PM

I am going to quibble is it really correct to say that the second factor in 2FA “augments” passwords? I see 1FA and 2fA as responsive to different security concerns/threats. I don’t see what intellectual work “augment” does in 2FA because both factors are equally necessary for 2FA to work. If one takes the second factors away from 2fA one isn’t left with a weakened form of 2FA, one is left with an entirely different security paradigm.

Anders • November 5, 2018 4:31 PM

The problem with biometrics is that you can’t change it – your fingerprints, your iris etc – once it leaks like you can easily change the password.
And sooner or later anything will leak.

Clive Robinson • November 5, 2018 4:50 PM

@ Humdee,

I am going to quibble is it really correct to say that the second factor in 2FA “augments” passwords?

Yes and no, it depends on what type of attack you are defending against.

Yes against “remote” or “stolen device” attacks, the lack of an IDkey or even biometric stops password guessing from succeeding (if implemented properly).

No against the arising Police State tactics (see my lead comment). Likewise those who have been kidnapped with their other factors. Where it falls to how susceptable a person is to coercion in various forms (remember the USG believes that waterboarding and similar ate legitimate interagation techniques).

It’s why I argue above for a short time out on passwords with another form of “something you know” used as a back stop.

That is if you can hold out for say 24hours the password entry function is locked out. Then another say geographical or time related authentication factor is required to re-enable the password function but with a new password that you don’t have then it’s game over for coercion it won’t work…

If you search this blog going back a few years you will find that @Nick P, @Wael and myself have had quite indepth discussions about it.

Petre Peter • November 5, 2018 8:02 PM

Password hygiene can be difficult when my provider doesn’t let me change my password even though I know the current password but don’t know the answer to my security questions. If I already know the password I should be allowed to change it.

Dave • November 5, 2018 9:02 PM

Many good points in Troy’s post. Passwords are definitely not going away any time soon. With the proliferation of IoT devices, I’d expect there will be even more passwords. If we don’t find a better way to protect them, they will become an even bigger issue. We have the “fiduciary” responsibility to protect them, as one parent of a cancer-survival child explained in this Forbes article – https://www.forbes.com/sites/forbestechcouncil/2018/10/12/the-growing-issue-of-compromised-credentials/#6daba7ec2434

Jonathan Wilson • November 5, 2018 11:25 PM

Why would a provider like Github or Google not allow you to use password + U2F key as your means of authentication rather than only allowing U2F to be used as an alternative to SMS or similar?

Weather • November 6, 2018 1:18 AM

Password are public, the device is with the person, plus phone number, geo location, plus model,
It is harder to hack,unless you want to get close, then easier, it’s a trade off

de la Boetie • November 6, 2018 4:54 AM

This seems a selective and incomplete analysis, because it does not consider the provider side. The providers are desperate to make the second factor something that uniquely identifies you so that they can trade you on the back end. The username-email is not particularly good at this, so they love having your by the mobile phone or biometrics.

The “obvious” second factor as an option is U2F, but this is inimical to the interests of the provider as it does NOT give them your ID effectively – a different certificate is provided for each site individually. So that’s why the availability of U2F as an option has been so glacial, despite it being consumer-friendly.

The analysis is also way too sanguine about the use of biometrics as a second factor, there are well known problems with that, rendering it anathema, at least for me.

Larry • November 6, 2018 4:56 AM

What about Steve Gibson’s “SQRL”?
Speaking of passwords, is there a technical or cost reason that some sites limit the number of characters that can make up a password?

jbmartin6 • November 6, 2018 6:50 AM

I’m surprised you didn’t mention your concept of authenticating the transaction, not the user. I agree that passwords aren’t going anywhere, especially after struggling to get 2FA via smartphone to work on planes or in foreign (to me) countries. The meaningful efforts are treating the password as only a single factor, and then looking to reduce risk in other ways, rather than making one huge costly barrier. Google’s Beyond Corp is an example. Here’s another tidbit for this topic. My bank only supports password logins to the web interface. When I asked them why, thinking I was going to switch to a more secure bank, they had a great answer. They said that they guaranteed depositors against all costs of fraud, they found this was a lot cheaper than all the infrastructure, development, and user support costs of any two factor authentication system. They felt their fraud detection on transactions and activity was more effective at reducing the risk than reducing usability for average customers.

Clive Robinson • November 6, 2018 7:34 AM

@ Larry,

Speaking of passwords, is there a technical or cost reason that some sites limit the number of characters that can make up a password?

Yes, storage costs, back in the 1960’s it was above 1USD/byte. However this has a “legacy” effect, which means the limits remain in existing systems long long after storage costs have fallen but upgrade costs on software etc have risen to a power law with respect to time.

I don’t know how old you are or what you were doing during the 1990’s but Y2K showed why early “cost savings” can become not just a huge “technical debt” but a very real financial debt. At one point in the very late 1990’s some contract programners were earning more per week than they were per year at the begining of the 1990s…

The moral, don’t put off what you can reasonably fix as it becomes possible, just to save a few bucks today… Unless of course you are a senior manager with no real skin in the game who fully intends to jump ship within a couple of quaters to another job, where todays “increase in share holder value” is the only real employment metric that matters…

The events at the beggining of this year with a very senior Intel exec selling a large block of share very shortly before Meltdown/Spector became public is a lesson in this respect.

@ jbmartin6,

I’m surprised you didn’t mention your concept of authenticating the transaction, not the user.

I’ve been publicaly saying it for a quater of a century or more, and people are still not taking it onboard. Oh and it’s not just “not the user” it’s also “not the channel” as well.

X-Mouse • November 6, 2018 3:21 PM

Capital One Bank only requires

  1. last name
  2. social security number
  3. date of birth
  4. account number or one or two pieces of public information such as previous addresses

to reset a password and login in. No email confirmation until after the fact. No two-factor authentication.

There is a sort of “warrant canary” page they have up to describe the process.

Jesse Thompson • November 6, 2018 5:06 PM

@quuux

@Clive Robinson

Speaking of passwords, is there a technical or cost reason that some sites limit the number of characters that can make up a password?

Yes, storage costs

While I get that you’re talking about inertia from days prior to the use of hashing algorithms in password storage, today one can accept a literally indefinitely long password and just have front end stream hash that once, then pass 1-hash to back end which iterates however many rounds it desires before comparing against the fixed-length hash that is the only thing it ultimately stores.

Plus, everyone’s far more common 8 character long passwords just get bloated out to 120-270 bytes apiece when storing (worthwhile) hashes anyhow. 😉

@quuux

People have been accustomed to handle carved metal pieces, AKA keys. Works fine for everybody with a hand.

.. except that the locks are digital. When you’re plugging a physical key into a physical computer (eg, swiping NFC past reader or plugging USB stick into port), which digital transaction is that physical act meant to authorize?

Usability isn’t just “can the end-user perform the authentication step”, it’s also “can they prepare the authentication step”. For passwords, that’s nothing more than aim cursor at text box — optionally with keystroke obscuration — and then use keyboard. Yubikey’s usability hinges upon this delivery method, for example.

For all other physical coupling mechanisms, you’ve got to have some software layer that actually links the desired transaction to the physical port, the end-user has to install that on their PC, and all of the providers who want to make use of said physical security have to support interacting via this new channel.

I personally count that entire acceptance chain in the “usability” column.

mrpuck • November 6, 2018 5:34 PM

Back to @Larry on the number of characters in a password. I use a password manager (1Password). I generate the password on a new site. I never know not only the length of the password that I need to generate, but also any other requirements like numbers, capital letters, or special characters. Why can’t a website display what they accept for a valid password? If the page doesn’t explicitly list the requirements then maybe a hover over the password field could display what is needed. The absolute worst is the continual fail until you eventually zero in on something that passes what is unknowable. Yes passwords will be around for awhile. Let’s make them easier to create.

Anura • November 6, 2018 10:57 PM

@Jesse Thompson

There are legitimate security reasons to limit password length: Key stretching algorithms usually include the password in every pass, and timing attacks can allow you to determine if the password is over a given length. In the extreme, it also opens up the possibility for DDOS attacks.

carrots • November 7, 2018 7:39 PM

Dare I say. Passwords are as secure as they have always been.

At least as long as there is a fixed ratio between the performance of a brute forcing machine and login system KDF performance requirements.

Let’s say in 2020 you use a modern KDF to protect a password with bit strength of n bits. It so happens that together with the KDF, the attacker’s existing and future hardware resources manage to break that password in 100 years. Good enough, you’ll be dead by then.

If you generate the password in 2030, your hardware is likely to have advanced the same amount as the attacker’s hardware, and since your system has more cores and more RAM than in 2020, the KDF requires more resources and the attacker’s efforts still take the same 100 years.

However, if the attacker spends more resources in relation, you’ll have to either spend more on your computer, or increase the password length.

Another problem is what performance do you assume the adversary to have. If you want to extrapolate what Snowden said to Poitras, assume one trillion guesses per second was possible in Jan 2013, and double that for every 18 months that has passed. The problem is, we don’t know for what system that advice was for. Was it gpg private key protection? rsync? Linux login passwords / FDE?

Wael • November 10, 2018 8:25 PM

This is why passwords aren’t going anywhere in the foreseeable future

Right! Although the limerick is from my early days. Haven’t improved much 🙁

Wael • November 10, 2018 8:32 PM

@Clive Robinson, @Humdee,

Likewise those who have been kidnapped with their other factors.

Typical threat modeling considers the security of the device and ignores the effects on the device owner’s safety. Biometrics add a factor of security to the device and reduce a factor of security for the owner of the device. Have you ever watched a movie where someone cuts off a victim’s hand for authentication purposes? Detach an eye?

CallMeLateForSupper • November 11, 2018 11:27 AM

@Clive Re: Something For the weekend

Great romp, Clive. Tnx!

This made me deposit coffee where it should never be.
“At one stage, I’m browsing through hit political discourse platform and opinion conveyor belt twitter dot com,[…]”

“I come up with a simple 8-step plan to do this, with 4 easy repayments of 2 steps.”

Kevin • November 12, 2018 9:30 AM

I’m far from the first to say this, but biometrics are not a form of authentication, they’re a form of identification. Those should not be confused.

Mind Games • November 22, 2018 4:43 PM

Hopefully GRC SQRL (Secure Quick Reliable Login) will be available in the next two years and we can start to get rid of usernames & passwords in many (not all) online places.
It will be open standard, free to use and cheap or even free to implement on the operator side and free for operate (just like passwords)

Since Ed25519 elliptic curve is being used, it allows to make sure is the user. And nothing prevents operators from adding additional factors OTP/FIDO for example if they want.

GRC SQRL is more likely to be adopted because it doesn’t need some additional hardware (usb pen for example) for the user to use it (just the device(s) you already own), and there will be at least some free offers in all platforms (security of those third party’s apps remains to be seen…).

If GRC SQRL is used in some good dedicated small security hardware (calculator size) then it may be almost impossible for someone to steal the private Ed25519 user key.
Ed25519 should provide around ~128 bit security so it should be secure up to year 2030.
It would be nice to have Elliptic Curve M-511 (~250 bit security, secure up to ~2060) but Steven Gibson refuses to use it, and stays in Ed25519.

Jesse Thompson • March 20, 2019 2:51 PM

@Anura

There are legitimate security reasons to limit password length: Key stretching algorithms usually include the password in every pass, and timing attacks can allow you to determine if the password is over a given length. In the extreme, it also opens up the possibility for DDOS attacks.

Yet none of that is relevant if you instruct your front-end (Javascript, WebAssembly, mobile app, etc) to hash the input password prior to delivery to the server.

Then you treat the hash of what the user enters as though that were the password. Hash is fixed length, so no reasonable concern for DoS and fixed timing at the server because every pass of KDF runs over the same length of “password”.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.