Finally: A usable and secure password policy backed by science | Hacker News Reader

Finally: A usable and secure password policy backed by science

cylab.cmu.edu

72 pointssoheilpro70 comments

I recommend changing the link and title to the actual paper: http://www.andrew.cmu.edu/user/nicolasc/publications/Tan-CCS...

IMO this accompanying press release is devoid of content and meaning even by typical university PR standards.

Yeah, the whole "backed by science" thing has a weird tinge of religiosity to it. I did notice that the article author has nothing whatsoever to do with the actual research.

Whenever I read that phrase, I instinctively know that they are trying to sell some bs that people would otherwise not even consider because of how little sense it makes.

Just like 'experts say' or 'research suggests'.

"Research suggests" is better. It's an appeal to process, not authority.

With the prevalence of password management, users are only expected to memorize a very small number of passwords. For me, I have two key passwords I must remember: my login credentials and the key to my password manager.

I don't know why we fret so much about password complexity requirements. In my opinion, the solution is not increasing the ease of memorization, but encouraging those who don't use a password manager to do so.

I would recommend memorizing the passphrase to your email as well. If you lose access to your password database for any reason, it's annoying but largely trivial to regain access to most sites, as long as you have access to your recovery email (and 2FA token, if applicable). If you lose access to your email as well, you're in a much worse position and may lose much of your digital life.

Buy your own domain and hosting so you can always regain access to it. It's hackernews so it astounds me that most people posting here use some free email instead of paying few buck for own domain and hosting.

I’ve done that for several years and given up. No matter how much I honed my server config, ensured my domain had DKIM, DMARC, SPF, DNSSEC, a proper TLS certificate for both the IMAP and SMTP servers and reverse PTR records that matched, I always had deliverability issues to clients using Outlook.com/Hotmail. Sometimes Gmail as well. All config checkers gave me full marks when I sent emails, I wasn’t in a single block list, I ALWAYS had issues. I’ve given up and am paying for ProtonMail on a custom domain now, it’s not worth the headache, honestly.

I'm not advocating hosting your own server. Just buy shared hosting from hetzner, OVH etc. and your done.

Personally, I pay for an email provider for the same reason I pay a cell provider instead of running my own SIP server - these things are fairly complex and I cannot afford to suffer a catastrophic failure that knowledgeable full-time staff could have prevented.

Own domain and hosting have their set of issues. Like how to make sure you don’t loose your domain to attacker due to phishing attack against your registrar support person.

If you are just an individual you may have difficulties in proving your ownership of a domain in case you loose it.

Don't shift the goalpost please. We are talking about forgetting password for your email account.

Now the part about attacking your email/domain:

If somebody transfers your domain without your will you have to contact domain registry and you will get it back after a bit of back and forth. It happens, noting new here.

Unless you register .eu domain - there is a whole institution dealing with that and there is no easy and quick way to transfer the domain in a stealth way + long grace periods and better authorization so its much harder to even try to do that.

Compare that to Google - your account gets locked or even worse somebody gains access to your email and that's it. Your not getting it back.

Buying your own domain it's a great plan, but this not one of the problems it solves - you're just changing the crucial password from being your email one to your domain provider one.

You are the paying customer, contrary to Google experience you can just call support and regain access. You can even contact domain registry directly and transfer your domain to other hosting if your current one will suddenly go out of business or whatever.

There is no way to be locked out of your own domain after forgetting your password.

That's like basic stuff people! Buy your own domains already.

Not a bad idea. I once had a nightmare (a real one while sleeping) where I didn't have access to my phone or computer and thus had no access to my password manager, and was unable to log into a crucial account in the dream. It hasn't happened to me in real life but it was quite a wakeup call

> Equipped with this state-of-the-art password meter, the researchers then approached password policies from a whole new perspective: with the idea that a password must achieve a certain threshold score on their password meter.

That's the most obvious way to apply a meter, not a new perspective.

On the bottom of the page, there's an absolutely galaxy brain take that made me twitch:

“A world that uses facial recognition does not look like Hollywood’s Minority Report. It looks like a smarter, more pleasant experience interacting with complex computer security systems to help make a safer world for our friends, our families and our children.” Marios Savvides, director of CyLab’s Biometrics Center

I believe his point is comments like this are reductive, and more an indicator of pop culture familiarity than anything substantive about protecting user's privacy. minority report's facial recognition involved swarms of fist-sized flying insect robots invading apartments, and facial recognition on my iPhone allows me to secure my data from the state

I walked into a shop once and was casually told the camera system routed to a central database shared with federal intelligence who uses facial recognition to match against terrorist and most-wanted databases. I thought that was a little concerning.

Why? Are you a terrorist or in a most-wanted database?

For the last four years my country has had an extremely hostile leader that should dispel all confusion about how easy it is to become ideologically opposed and thus persecuted by your government over a short period of time simply for being a supporter of basic human rights.

>facial recognition on my iPhone allows me to secure my data from the state

You mean the police won't be able to get your data? Can't they just hold your iPhone up to your face and then get your data?

Best feature ever: https://www.macworld.com/article/3236793/how-to-quickly-and-....

Couldn't you have the same security without face unlock at all? Just keep the phone completely unsecured until you're about to be arrested, then activate the password.

Not sure what you're driving at here, could you explain? To put it more simply on my end: iPhones use biometric authentication to secure your data, and the eye-scanning swarm of spider robots are from a 20 year old fictional movie.

You said face unlock provides security against "the state". But biometric authentication doesn't provide protection against the state, because the state can legally and physically force you to biometrically authenticate to your phone.

Then you said you can protect against this by activating a password. But that's not biometrics, that's a password. The biometrics aren't helping, the only thing providing security against the state is the password.

You posted the same comment twice in a row. I'm not sure how to respond to that.

This perpetuates the fundamental misunderstanding on what makes passwords strong. In fact, no password itself has any guaranteed entropy and hence strength- only a distribution has this property. Since humans provide such poor randomness, we should never pick passwords at all, but generate them.

Research should go to making more memorable generated passwords, looking for the best tradeoff between that and entropy.

That fundamental misunderstanding is not a misunderstanding. You can look at individual passwords and estimate their "entropy", such as zxcvbn does, and in fact you need to. Because the distribution that matters is not the one you used to pick the password, but the one that the attacker uses.

You could pick from the universe of arbitrary UTF-8 strings of up to 1000 characters (huge entropy), and pull "password" - but that would be a bad password, despite the distribution.

Or you could pick randomly from {"password", "09854yngbmoujcr08twnvgje8w6g7bkv,cmxm5^&*9NMF"}, and pick the latter, and it would be a reasonable password, despite carrying only 1 bit of information in the given distribution.

> Research should go to making more memorable generated passwords, looking for the best tradeoff between that and entropy.

Agreed on that.

Although by chance you might pick a good password, you have absolutely no guarantee of the strength unless its generated from a distribution with known entropy. The problem with assuming any particular distribution for the attackers is that they tend to constantly update their attacks as password trends evolve.

Random password, picked uniformly from strings up to 1000 characters? Almost certainly at least 900 characters, extremely strong. Probability of picking "password"? Less than the probability you're currently hallucinating, or that there's a bug in your code, or that an attacker guesses your password by pure chance.

You can't show that particular string isn't easy to guess- perhaps it follows a common pattern of humans spamming "random" keypresses with far lower entropy than one would expect. Can I show that I could guess something without seeing it beforehand? Probably not. Don't settle for "I couldn't guess this password" when you can get "No one can guess this password".

I had a (slightly silly) go at tackling this problem via a secure mapping and language-model reranking according to probability of text under urban dictionary - there is a detailed description here if you're curious: (pdf-link) https://n-mca.github.io/work/Nat_McAleese_Arbitrary_Encoding...

Nope. No dictionary words is a non-starter. If I tried to enforce this as policy I'd get zero compliance.

It's a good point.

One thing that would have been nice to see is a graph with several lines.

X-axis is bits of entropy, Y-axis is recall rate. The individual lines reflect a single combination of (a) formatting scheme (e.g. diceware) and (b) reinforcement mechanism (e.g. type 20x once per day).

I've run this experiment on myself and found that diceware with intra-word punctuation gives the highest entropy at the lowest effort.

Every password I need to remember has a dictionary word in it, because it's easy _additional_ entropy. Once I've got a password that's borderline too long to remember, I can't really add more random characters to it without risking forgetting it. Concatenating it with a dictionary word ("password-dictword") is much easier to remember, but (I believe) still adds a meaningful amount of security.

It removes you from the list of people who get pwned with a rainbow table from leaked passwords, but that's not much security.

English has only got ~1.2 bits of entropy per character. [1]

[1] Table 1 in https://arxiv.org/pdf/1808.04444.pdf

But entropy is relative to an attacker (it measures the attacker's uncertainty about your password). The 1.2 bits/character measurement is about grammatical English text that occurs in a communicative setting. That means that before you get there, you probably already know what word goes at the end of this sentence.

You can measure this with human native speakers, or with a compression algorithm, or with a naive letter n-gram or word n-gram model, and get different statistics -- each of which is correct in the sense of each model's uncertainty about how the text continues.

In the password setting, words can be used in all sorts of ways, some of which are very unpredictable to an attacker, so it's plausible that each word adds at least log₂(len(dictionary)) to the password entropy when it's chosen at random from a dictionary, even when the attacker expects that the password selection method could have used that dictionary.

I was going to snarkily make a point about that figure only making sense in the context of grammatical english text, with the example of a randomly chosen 7 letter word being one of 32,909 options.

log(32,909) is about 15. Which is of course 1.5 bits per character, and that's generously assuming that a person will actually randomly pick from all those potential options. So sorry for what I almost commented, but now I have to wonder why the entropy of a word on its own is so close to the entropy of a word in a sentence. Am I missing something? Is it just coincidence?

It’s good to recommend that passwords be 12 characters or longer, and the password-strength meter seems good enough. I tested it with CorrectHorseBatteryStaple (from xkcd 936) and it said the password is strong. But what I didn’t like in the suggestions in the demo strength meter site is that it keeps suggesting that the user avoid dictionary words and add one more symbols or one more digits.

> Your password is pretty good. Use it only for this account. (Why?)

> To make it even better:

> Don't use dictionary words (Correct, Battery, Staple and Horse) (Why?)

> Consider using 1 or more symbols (Why?)

> Consider using 1 or more digits

This essentially goes against the advice that passwords should be complex but also easier to remember (yes, many people still don’t use password managers) and also the advice not to force users to add symbols or digits.

I tried a few other different passwords and pass phrases with digits and symbols, but I saw a subtle coercion in the suggestions that would make a lay user doubt the password-strength meter and create extremely long and complex passwords (no pass phrases, since dictionary words and even terms in Wikipedia are flagged). It encourages you to add more digits and symbols even when you’ve already used a few.

In short, the password-strength meter seems fine, but the suggestions are not great.

It withdraws those suggestions if you make it long enough. For example, "horsecardoghousemailglassplate" has no improvement suggestions, but until that final "plate" is added it says not to use words, and to add symbols and upper case.

Another example is "195884873718293401958657". Until that last 7 is added, it suggests avoiding dates (1958), repeating sections (1958), and having very common passwords (718293) is part of your password, but when that last 7 is added the suggestions go away.

Doesn’t it just give up on giving you suggestions after a certain size?

In my first example the suggestions stop at character 30. In my second example the suggestions stop at character 24. For a password that is all ‘a’s they stop at character 68.

I’d guess it stops making suggestions when it reaches a certain estimated strength. The suggestions are ways to reach that strength efficiently.

12 characters is only 72 bits of entropy, and that’s assuming you’re using randomly generated passwords with an equal probability distribution of the entire set of printable base64 characters.

That’s nowhere near enough entropy for a proper password.

Just use the damn password manager already.

> 12 characters is only 72 bits of entropy ... That’s nowhere near enough entropy for a proper password.

What do you base that on?

If you assume the password is stored using current best practices (ie, you use a key definition function like PBKDF2 or even better scrypt), it's tons. You can't assume a website will be using anything reasonable - but anything I manually enter this 12 character password into, like a password manager a modern auth service, or ssh it is reasonable.

Proof: assume you use a KDF that makes a check of a single password take at least 1ms on modern reasonable machine, 72 bits means it will take 149,642,763,799 (= 2^72 / 3600.0 / 1000.0 / 24 / 365.35) years to break. Sure you can parallelise it, so lets throw a billion of these "reasonable machines" at it. That reduces it to 149 years. I'll be well and truly six foot under before they crack it, which meets my definition of tons.

But it's better to look at it from the point of view of the worth of the information they get versus expense. Let's say for argument's sake my entire net worth is $100M. Lets also also say a "reasonable machine" worth $10. And finally assume the value of that $100M shrinks over time, so after 20 years it's worth almost nothing. Continue assuming we use a KDF to ensure doing one guess takes 1 second, and you end up with needing 62 bits of entropy - or 11 characters.

I just changed my PayPal password today; they restrict the length of a password to between 8-20 characters. Why the upper limit? Once you're at 20, you're likely using a password manager, so another 20 wouldn't hurt.

I tried the demo, and could not come up with a 12-character password that got a good score and was not just impossible-to-remember random jibberish.

I'll stick with generated pseudo-random gibberish and a password manager.

`openssl rand n | base64` is my go to

You can use openssl rand -base64 n to save a pipe.

The average person's working vocabulary is 20,000 words, do you expect a layman to be able to produce a perfectly random combination out of the paltry 20000⁴ possible sequences. Will they reach into the outer edges of their vocabulary to use obscure words? Surely it would be biased towards common words, making even bcrypt pointless.

If they're "reaching into the edges of their vocabulary" they're doing it wrong anyway. People are terrible random number generators. Don't do that. Use an actual random number generator to select a sequence of words from a list.

> Use an actual random number generator to select a sequence of words from a list

I wrote a program to do this for me which I myself use, and anyone else is free to download and use it (open source, ISC license) :D

It supports a few different options, including one that will tell you what the passphrase entropy would be.

https://github.com/ctsrc/Pgen

This is something where there is value in having a generator to do the password creation. That way the use only needs to remember the phrase rather than also come up with it.

With respect, maybe your vocabulary is 20,000 words, but I submit that the average English-only speaker is more like about 10,000 words.

This is a case where I choose to believe xkcd unless and until you can provide convincing evidence otherwise.

The total possible permutations of characters in just an alphanumeric 12 digit random password is 36¹², which is around 400 times larger than the number of permutations possible with 4 words picked out of a pool of 10,000 or 10000⁴.

This might seem reasonable, however, this is only a false economy as people tend to gravitate towards common words that evoke simple concepts, which drastically reduces the search space.

A dictionary attack isn't anything novel and the proliferation of this technique would only make life easier for the baddies.

You could argue that passphrases aren't even competing with randomly generated passwords but rather with the naive passwords that people come up with that has simple character substitution for special characters.

However, this is the same reason why it should only be confined to use in places where a yubikey for active directory windows login or a password manager wouldn't be practical.

If you're going to use a tool to generate your passphrase, why not use a tool to store it and retrieve it at will, while also protecting yourself from shoulder surfing?

If using a password manager then memorization is less useful while fully random passwords are considerably stringer.

So, the end result of that paper is a password-quality-meter like zxcvbn (or presumably better)?

(They do reference zxcvbn in the paper: "One of the more accurate password-strength estimators, zxcvbn [34], uses advanced heuristics to output quite reliable password strength estimates at low guess numbers typical of online attacks.")

If I read the paper correctly: They trained a state-of-the-art password guessing NN. They used this to train a second NN to estimate the number of guesses needed by the first NN to guess a given password, and used this second NN as the password meter.

A password is resistant to online attacks if it takes more than 10^6 guesses, and resistant to offline if it takes more than 10^14 guesses.

After comparing combinations of password requirements, blocklists, and strength requirements, they found that minimum of 12 characters, and a NN estimate of more than 10^12 guesses is the best password requirements for usability and protection from offline attacks.

So instead of heuristics for a strong password, they derive the strengths from how many attempts it would take a SotA NN to guess the password.

I really liked the realtime “improve this password” options — you can follow a link in the article to try out the password helper. After playing with it, I believe that it gets better results on the security:memorability ratio than other available options. I think this plus something that queries password databases if made in drop-in javascript form would be a help to many sites.

Here’s a password strategy I began using that allows me to commit every password to memory while keeping them unique (I don’t trust pw managers):

Letters representing the service + Constant text + year + constant ascii

E.g for this site it could be "hackblabla2020__#"

Then for email it could be "emaiblabla2020__#"

Then it also forces me to change it once a year-ish

If someone really cared about hacking you, and one of those websites has a clear text password dump (which happens all the time), you are in serious trouble.

I figured if someone really cared about hacking me I'd be screwed anyway. I should add that my most important accounts don't follow this pattern

I hope Constant Text is quite large, because otherwise you just announced the majority of your password to all of your logins.

Consider deleting this post?

Thanks for the concern. The examples I gave don't follow the real patterns/orders/Ascii I use

I absolutely love Jetbrains products but the only thing I hate about their site is how insane the password rules are.

Its like someone just wants to complicate things for no reason. I have to almost always use the forgot password link to login to their site because nobody can remember a password which satisfies all their rules (only other option is to save it to lastpass but that is not available on mobile)

I hope that more companies consider this new password policy that is also easy to remember.

Maybe try 1Password? It is absolutely available on mobile.

1Password is an awesome app, insanely expensive in my opinion though;

Once you get a subscription you're going to be stuck for a while, so at €38/year, for me and my partner, that makes €380 for a 5 year period! For a password manager...

Free alternatives would be KeePassXC / Bitwarden / Strongbox (iOS).

TL;DR the secure password policy is to use their secure password test, the criteria of which are not divulged.

The criteria are divulged, and it's all open source...

https://github.com/cupslab/neural_network_cracking

Securely use a compromised pasword cos u dont give a fuck is my policy

Reply on news.ycombinator.com