NIST’s new password rules – what you need to know | Hacker News Reader

NIST’s new password rules – what you need to know

nakedsecurity.sophos.com

501 pointscpeterso229 comments

The importance of this NIST standard cannot be understated. It has a requirement that passwords be hashed with a random salt! Microsoft Active Directory does not use salts!

I am trying to imagine the consequences to all the businesses and agencies that must adhere to these standards suddenly coming to the realization that they must replace their Active Directory installations and what that will mean for administering all their Windows systems. It's not going to be pretty.

You might be thinking, "but these are just guidelines!" Yes, but actually there's loads of existing business contracts with wording that states the business must adhere to all NIST (security) guidelines. Also, you can bet that once this gets finalized other standards will follow suit.

It will be interesting to see what Microsoft does because salts were expressly not added to AD because so much functionality cannot work with random salts in place. They're going to have to break backwards compatibility with a lot of functionality and many 3rd party products that synchronize with AD. Entirely new APIs are going to need to be written.

It will also become seriously annoying to create keytabs at large organizations since only domain admins will have that power once random salts are in place; making automation very difficult.

Will requiring salts break ms-chap-v2?

Presumably Microsoft would add a salt before losing all that business. Perhaps only if you turn on special NIST-mode, in the way of microsoft and backwards compatibility.

It might break some functionality, but probably not as much as moving to an entirely different product if you have things written against MS APIs.

This is a great example of how smart standards can leverage incredible pressure against vendors to adopt best practices.

What will happen is that if the new standard is accepted as is, every single implimentation will have to craft a Plan of Action and Milestones (POAM), and every security officer is going to write in "Waiting for vendor fix". That's a lot of pressure on Microsoft to change this.

Will it take time? Certainly. Years in fact. But if you want massive change, this is how you start.

I'm a big fan of Active Directory. But I applaud this move. I'm even more excited to see if this will filter down to banks. Probably not as quickly, but one can hope.

> Perhaps only if you turn on special NIST-mode

That is pretty much how they worked the Posix compliance requirement for government/forces use for NT/2000: the API was available through an optional (and IIRC not quite complete) module that very few ever turned on even where it was a contractual requirement that it be present.

The option you suggest could be present but no doubt not be in use by many people because extension-X, third-party-app-Y, or internal-automation-subsystem-Z, or some feature of AD itself, would break.

If a salt matters, that means you can look it up in a dictionary of hashed passwords. Which means its in a very small search space. Which means a exhaustion search would find it quickly anyways.

Far more relevant than "salts" would be using a PBKDF (See PBKDF2, SCRYPT, BCRYPT - which come with a salt for free anyways) with an appropriate number of iterations.

What was the last year that Rainbow Tables were relevant anyways - 2010? Earlier?

Even if you assume weak passwords, there's no comparison in effort when you involve stretching.

No salt means you can precompute the hash for the 1,000,000 most common passwords. That'll take maybe an hour or two with aggressive stretching. Then you check it against the million or so records in the database for any matches.

Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. That means you're talking about decades of computation time. That's a heck of a lot more expensive. And importantly, you have to start that computation AFTER the breach, because that's when you gain access to the salts.

Salts are not unimportant.

Now this is something which i don't understand. Is this really the best we got?

If you somehow get into a server with those hashed passwords, you'll probably try to mirror it and everything on the server, to figure out the hashing mechanism. So lets say, time is not an issue, also regarding long lasting APT's.

So what will you do with it? Why should you try brute force a million passwords, each one taking 2 hours to decrypt? No, you're smarter than that: Why not create a rainbow table of possible admin account, vips, state actor, etc. How many are those? 100? 1000?

Nice, you just reduced the search space by a factor of 1000.

That whole circus about hashing... I know, randomly salted hashing makes sense, but true secure password storage is a myth.

So - I think we basically agree with each other, that for a straightforward single round of a hash like SHA256, that a salt is now irrelevant (reason - a GPU cluster can check 10s of billions of passwords/second)

I think the point I was trying, and perhaps failing to make, is that the three PBKDFs - PBKDF2/BCRYPT/SCRYPT - all come with a salt anyways - so you don't really need to call them out.

What I guess I should have made explicit, (and I didn't) is that if all you are doing is a single round of a SHA - then adding a salt at the beginning isn't going to make that password any more secure. If it could fall to a Rainbow Table Lookup, then it will fall in pretty much the same amount of time to a password-cracker - on the order of milliseconds.

> Salt means FOR EACH RECORD in the database, you have to compute those 1,000,000 passwords. That means you're talking about decades of computation time.

SHA256 of the million most common passwords (with a 128 bit salt) takes 2 seconds /total/ on my laptop. That's only 42 days required to crack a database of one million hashes.

  var stopwatch = Stopwatch.StartNew();
  var salt = "0123456789012345";

  int crackCount = 0;

  foreach (var password in File.ReadLines(@"c:\temp\10_million_password_list_top_1000000.txt"))
  {
    System.Security.Cryptography.SHA256.Create().ComputeHash(Encoding.UTF8.GetBytes(password + salt));
    ++crackCount;
  }

  stopwatch.Elapsed.Dump();
  crackCount.Dump();

  00:00:02.0981333
  999999

Salt is indeed important, but the only real way to protect is to iterate - PBKDF2/scrypt/bcrypt.

Are you ignoring the part where I said "when you involve stretching?"

The claim was that salting is irrelevant compared to stretching. It is not. It is still unbelievably important even when doing stretching.

Sorry yes I obviously missed that bit.

I think in the real world there are two scenarios, someone is using one of PBKDF2/Bcrypt/Scrypt - in which case all of this is moot, set an appropriate work factor/#of iterations, and you are secure with even a moderate sanity check against the password. Interesting note - said sanity check, ironically, could be a simple as a lookup - the top 4 billion passwords can be stored in a packed 24 gigabyte lookup table on disk which can be searched in < 100 milliseconds).

The other scenario is when you doing a single pass of a hash, in which case the salt is irrelevant for the security of that password.

Everyone here understands that you need to salt when your dictionary takes a long time to build (Say, more than 1 millisecond/password, which equals 2.5 billion passwords/month) - not everyone appreciates that salting a fast password (more than 2.5 billion passwords/second) - adds no security to that particular password.

The scenario where there is moderate "stretching" (by which I presume you mean running multiple iterations of a hash), with no randomized salt, is a bit of a straw man - who would bother to go the effort of "stretching" and not stick a randomized salt in while they are at it?

The problem is they are basically saying that almost every "best pratice" recommended over the past 5-10 years is absolutely the wrong thing to be doing. Don't be surprised when people throw up their hands in frustration.

"best practice" according to whom and "recommended" by whom? Maybe by security theater or other sources of BS, but not security experts (who are worth their, ahem, salt).

It's been longer than 10 years, and known for quite some time by most.. The xkcd article is over 5yo itself, and a lot of people pushed for more open passwords for ages...

I do one controversial think and that's trim password imput (mainly because of trailing whitespace selection in some apps/oses). Other than that, if you can input it, you can use it... though now doing some unicode normalization for unity combos is probably a good idea prior to hashing.

https://xkcd.com/936/

That comic is unfortunately not telling the truth. The password phrase IS 44 bits of entropy, assuming you input random ascii. But any reasonably knowledgeable person trying to crack passwords, will use a dictionary to create a passphrases, rendering this less useful than the first password. Even if you do substitute o/0/ø, i/l/1, a/4, ect randomly. You still need a rather long sentence, and preferably spice it up with simple substitution - now this passphrase is no longer easy or simple to remember.

Then why doesn't he update it?

I think XKCD is correct here.

If you choose four random words from a list of 2048 common words, and your attacker knows that's what you're doing, then your entropy is 4 * log_2(2048) = 44 bits. If the attacker didn't know your strategy and tried to brute force letter by letter it would be much higher - around 48log_2(26)=150 bits assuming around eight letters per word - but like you said, we should assume the attacker knows exactly what strategy we're using, so 44 bits is the better number to work with.

Since that's still more than 28 bits, a 'correct horse battery staple' type password is harder to crack then a short random string of mixed characters, even if the attacker knows exactly what your password generation strategy is.

> I think XKCD is correct here.

> If you choose four random words from a list of 2048 common words, and your attacker knows that's what you're doing, then your entropy is 4 * log_2(2048) = 44 bits. If the attacker didn't know your strategy and tried to brute force letter by letter it would be much higher - around 48log_2(26)=150 bits assuming around eight letters per word - but like you said, we should assume the attacker knows exactly what strategy we're using, so 44 bits is the better number to work with.

> Since that's still more than 28 bits, a 'correct horse battery staple' type password is harder to crack then a short random string of mixed characters, even if the attacker knows exactly what your password generation strategy is.

Typo in the above but can't edit on my phone, the second sum should be 4 \* 8 \* log_2(26). Apologies.

Can we really assume 2048 different words? 100 words make up 50% of all words written according to this https://en.wikipedia.org/wiki/Most_common_words_in_English ?

I was a bit hasty of the entropy of the passphrase, my mistake. I still stand by that even if we choose from 2048 common words, generating a good passphrase (one that isn't a common sentence) is harder than we think.

None of [ "correct", "horse", "battery", "staple" ] are in that 100 list, though.

I'd go so far as to say that 2048 words aren't that many.

Here's Merriam-Websters 3000 _core_ words [1]. Here's a list of 355k words [2].

[1] http://learnersdictionary.com/3000-words

[2] https://github.com/dwyl/english-words

There is not 3000 _core_ words. You don't teach elementary school children 3000 words. That list is significanly smaller. In Denmark it's 120 words, then you'll be well on your way to reading and writing most basic stuff.

That someone has selected 2048 words used to generate passphrases, doesn't make it easy to remember.

I've been doing this for years and it is indeed easier to remember. You won't be keeping all your passwords in your head in any format if you're using a unique password per site or service as you should. But you occasionally have to buffer them mentally between your password manager and the input box (especially on mobile), and the same number of bits of entropy are infinitely easier to copy correctly in this format vs something like "?G[G6n|4".

Err.. I would suspect most(non-english?) people on the internet to know 2000 words. (By virtue of being atleast bi-lingual, they would, so the challenge boils down to can they type it? unicode support should help, but I've found most cases people simply type those sounds in English.) As for the English as a primary language people, I've no clue about the number of words, but if we can expect them to type 1024 words, we'd still get 20 bits..

"Average native test-takers of age 4 already know 5,000 words."

http://www.economist.com/blogs/johnson/2013/05/vocabulary-si...

Know and ability to spell are two completely different things.

Eh, you may want to peek at the XKCD things explainer to see what is life under 1k words.

Everybody uses more than a few thousand words on at least one language. And selecting the least used ones will make your passprhases easier to memorize, because they have much more concrete meaning (by virtue of their rarity) than the most used words.

You can if it's a computer picking the password from presumably common words.

If the human is picking anything than there WILL be a bias in selection. Effort should be made at minimizing that, but even with education this is a difficult task for any worker.

It got to the point where I actually took a classic literary work and made a 'password words' dictionary from it just so that I could have the computer generate possible new passwords. (there bias is mostly filtering out things that might be offensive... because someone can always take it the wrong way even if you explain in advance the theory of how the password was created by a computer).

I've been pretty happy using diceware[0] for my word-based passwords. Just be sure to use actual dice and not a software based random number generator if you want it to be truly random.

[0]http://world.std.com/~reinhold/diceware.html

Mix in some other languages or slang words, and a number is always possible and easy to remember. You may choose to replace the space consequently with a comma or ; or another easy to type character (not one that requires a shift if you keep everything lowercase).

Yes, 2048 is tiny. I've been using a 4096-word dictionary I found online for years, along with my family and two kids since they were about 6 years old. There is absolutely no trouble with a 4096 word dictionary. Yes, they (and me too) sometimes bump into words we don't recognize, but it's not that common.

Here, I just generated you a few passwords:

* hefty march attempt force bowel scuff

* between sepia book sweat lemma saint

* safe warn magical cask hefty wish

* alum glib puck adieu dour lazy

* telephone pine cavort good knee swank

* numeral plan jewel conch slate tube

* pastry piano sure proxy unit brew

* trig rise taint current sans gallop

Here is the same random numbers but encoded into ascii instead of words:

* 81Pk3t?Rq6S}

* ]CPcYrT^?iE3

* +qV`J9ZU&.,C

* `>sp=~V);3g>

* E&_ff7a|Z4B[

* ?OX~[J>0K'S*

These each have the exact same amount of entropy as the word-based ones.

Yes and good luck writing those passwords like "between sepia book sweat lemma saint" without typos :)

I just watched a friend using some kind of long password and it took about a minute to get the password correctly entered. Easy to look at the keyboard also when he was typing and guess the words used.

Better that then 81Pk3t?Rq6S}

BIP39 uses a wordslist of 2048 words, it selects 12 words to generate a passphrase. I believe the target is 128 bits of entropy.

The GfyCat URL generator list is about ~1800 animals and ~8000 adjectives [0]. All fairly memorable words. Add in other types of words and 2048 quickly becomes a small number.

The words don't have to be incredibly simple, either. Grabbing a random GfyCat image from the front page gives me "OrangeLankyBasilisk" which is easy to remember, none of those words are particularly foreign. But they're not in your list of most common words, nor are any of them in XKCD's simplewriter [1], which keeps track of the 1000 most common words.

[0] https://github.com/a-type/adjective-adjective-animal/tree/ma...

[1] https://xkcd.com/simplewriter/

Edit: The words need to be randomly chosen by a computer, so it doesn't matter what the most common words are. You could generate the password from a list of 2048 spanish words or japanese words or emojis and the entropy is the same as the previous scenario (assuming the attacker knows your dictionary of symbols just like they'd know your dictionary of English words). If you let a human choose, of course the smiley-face and poop emojis are going to be picked 50% of the time, but that's not the intention of the comic or passphrases.

No, you are wrong. The number of bits of entropy in "horsestaple..." is estimated by assuming the words where chosen at random from the 2^11=2048 most common words. 4*11=44 bits in total. In practice it is even better since a hacker would also try different kinds of passwords! So no, you do not need substitute characters.

Yes, I was wrong about the entropy when writing that. But I still don't think that passphrases are as godsend as the comic make it seem. Can we really assume 2048 common words? The 100 most commonly used, make up 50% of written words.

A common sentence like "I drove to the mall yesterday" is not a good passphrase, but I'm certain that people who use "rocket" as a password would do something similar.

The intention is that the random words are selected from a list of 2000 unique, common words.

Choosing a sentence is a different strategy, which is less secure.

    $ wget -O ⅓Mwords http://norvig.com/ngrams/count_1w.txt
    $ for i in `seq 10`; awk '/^[a-z]{3,}/ { print $1 }' ⅓Mwords | head -n 2000 | shuf -n 5 | tr '\n' ' ' && echo
    videos possible disease maintenance chair 
    teen documents than without son 
    research interface library largest drive 
    location ball beauty coming files 
    files middle fri meet air 
    guarantee samsung click super inn 
    legal previous rent resort use 
    reply thought better fresh phentermine 
    bad command once vehicle australian 
    fun random professor course sponsored

A random 5 words is hardly simple or easy to remember. The entire selling point of passphrases is exactly that.

It's a hard problem that is IMO best solved with hardware secure keeping of secrets and a rate limited pincode.

You're not supposed to remember all your passwords. You will need to remember at least one master password and maybe a couple more.

But you can't suggest that remembering 5 random words is harder than 20 random characters?

The goal is "simple" if possible, but "simpler" is still a lot better than "practically impossible".

I'm not suggesting that 20 random characters is easier to remember, but for average Joe, it might as well be the same. Not only do they have to remember the words, the sequence, and how to spell them. Unfortunately we cannot expect this from users in general - the worst offenders write down a password like "rocket", so there is no hope that they'll try to remember a sequence of random words.

We shouldn't have remember passwords at all IMO. It's creating entropy by remembering things, but the human brain is inheritly bad at remembering exact things. Things like a yubikey is a better idea, plug it in, enter your pincode, and use a key pair to authentication. All the user have to do is keep track of the physical thing and the pincode.

> A random 5 words is hardly simple or easy to remember

You use well-known the mnemonic trick demonstrated in the last panel of the comic.

the idea is you use a mnemonic generator to pick the words. The fact that "100 most commonly used, make up 50% of written words" (a dubious statistic, source?) is irrelevant.

Here's a mnemonic generator I wrote in Rust https://github.com/leshow/rust_mnemonic for example

> The fact that "100 most commonly used, make up 50% of written words" (a dubious statistic, source?) is irrelevant.

See https://en.wikipedia.org/wiki/Most_common_words_in_English for a claim. It is what teachers use as a guideline. It's the first 100 words they teach children to write.

> the idea is you use a mnemonic generator to pick the words.

I know you are supposed to use a generator to pick the words, that is how BIP39 for bitcoin works. But average Joe is not going to do that. He will select "I went to highschool in 1992". Authentication is a hard problem, and unless you force a reasonable scheme, it will be weak.

Even those 44 bits are too little nowadays. Passphrases are not a godsend, but something good to use when the correct technology - a password manager - is not available.

A notable use case is choosing a master password for your password manager. And you'll want a longer phrase.

I think you failed to think that through. Random alphanumeric input of that length would be 25log(36)=525=125 bits. It is 11 bits per word because it is chosen from a ~2000 words dictionary.

Edit: should have reloaded, said by enough people already :D

Do those contracts really require adherence to NIST standards, including whatever future changes are made to them? I would have thought they'd be restricted to the guidelines as they are at the time the contract is signed.

You typically have to renew every few years for DoD.

Can NTLM, which prevents sending the password itself across the network, work with random salts?

No it cannot since the authenticating client won't know the salt.

NTLM isn't the only authentication method that is fundamentally incompatible with salts. The way Windows clients perform initial Kerberos authentication (getting the TGT) will break as well.

Kerberos is easier to fix though since the protocol was made to work with salts. It's just that the way Microsoft implemented it leaves it vulnerable to pass-the-hash styled attacks.

Another issue is how applications handle incoming Kerberos authentication. For example, when you configure IIS to perform Kerberos authentication you (usually) need to specify a service account and provide the password. Instead of storing the password IIS will simply pre-compute the hash (which it can do because there's no random salt) and store the result using DPAPI (I think... Since it's a Microsoft product it may use a different nonpublic API). If using random salts IIS won't be able to do that anymore and will have to work like traditional MIT Kerberos applications--using a keytab (provided by an administrator).

additionally, there are rumors (maybe more than that now) that the next round of HIPAA/HITECH /etc... regulations are going to adopt a lot of NIST standards and frameworks. So, this could potentially trickle down to the Healthcare industry.

Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.

PCI compliance requires quarterly rotation of passwords and keys.

This recommendation may perhaps be a step to getting those compliance rules changed.

Nothing better than rules based on bad data and security theater.

If your password is compromised, it will only work until the next reset. That's better than having one that works for years.

If your password is compromised, you've already lost. Since password rotation policies incentivize weak passwords, they are more likely to result in a compromised password. Thus, password rotation with weak passwords is not better than a single strong password that is never rotated.

Now that I think about it "Don't worry about detecting attackers, they will get kicked out when we next rotate passwords" is not an attitude you want anyone to develop.

Plus, chances are pretty good that if they compromised one password undetected, they can compromise the next one in the same way (spear phishing, malware, etc.).

That's true, but I'm having hard time thinking of a use case where a sustained, hidden compromise is 'worse' than a one-time compromise.

I mean, I guess they could login to your bank every week and transfer out $50 instead of just transferring out all your money on day 1, but... ?

I have previously worked in the gambling industry. The worst nightmare of any gambling device manufacturer is a group of people that discover a bug and exploit it on small scale - no one will bat an eye and investigate if a machine pays out 50 bucks more or less.

However, in most cases people are dumb, greedy or the combination of both - e.g. in February 2014, a concerted mass hack occurred across Germany and over 10M € were reported as losses (http://www.spiegel.de/spiegel/print/d-126511954.html), and most other bugs surface fairly quickly because people exploit them until the machines run dry and the owner/manufacturer inspects them.

So, in the case of gambling machines/casinos, a small-scale hidden compromise is far worse than a "big blow" - thankfully for the industry, greed usually prevails over common sense.

There are quite a few scenarios where a sustained, hidden compromise is an (or several) order of magnitude worse than a one time obvious compromise.

The first to come to mind is a corporate espionage scenario. Do you want to know what your competitor is up to today, or do you want access to their briefings/CAD/code for the next 12 months? Long duration compromises also allow you to slip data out slowly, so a NAS doesn't show 200GB being transferred off in a matter of hours, but a slow drip of 100MB a day.

At a personal/home use level, long term access to a bank account allows an attacker to build up a spending profile, which depending on your habits, could be used for blackmail.

The reality is that passwords are being deprecated as strong security boundaries.

We've been working under this fantasy that it's acceptable to make a "strong" password and have a meaningful expectation that you can maintain the security and integrity of access. Multi factor authentication is the best solution to this problem -- a moderately complex password with MFA is stinger than a password.

If you want to compromise somebody long-term, you move laterally within the targets network and infect multiple devices.

Password rotation doesn't fix that because the difference between myLongPassWordThatDoesntChange and myLongPassWordThatRotates7 is effectively meaningless. An adversary who has your current password can almost certainly guess your next one because changing the 7 to an 8 is a pretty obvious step, and it's one that most people do when forced to rotate.

Forcing password rotation guarantees that most people will just use the shortest possible password and stick some rotating suffix on it because your policy is pointless and annoying. You make yourself the adversary when you enforce policies like this and people stop trying to be secure and just try to get on with life.

Anecdotal and only related to your last paragraph, but as a security researcher I can say that 99% of the time attacks on a personal bank account are never "long term." Most of time, regardless of skill, hackers get in, cash out and disappear. It's far more lucrative (and generally safer) to empty the account than try to blackmail someone based on spending habits.

I happen to know of a bank exploit in which the attackers compromised one thousand online accounts, and attacked all them (transferring funds) on the same day.

Presumably the attackers were worried that after several transfers the bank would notice and block further access, so they kept a roster of compromised accounts to attack all at once. I suppose that a password rotation policy would have helped mitigate damage in this case, though something like fail2ban or automated IDS would have been better.

The rotation guidance is partly to address employees who've left the company, vs generalized password cracking attempts.

Then you've already failed my not having a plan to disable accounts

I haven't failed anything. I am not an IT pro.

Also it's not just for the account of the terminated person, but for any passwords the terminated person has 'learned' whilst employed.

again if your corp doesn't have a policy for off-boarding employees and removing their access then you've failed. If your corp doesn't have a policy of not having shared accounts then you've failed... if you are forced to have shared accounts then you need to have in your off-boarding policy that anyone who had access (which was a purely need to know basis) once off-boarded would trigger that password change.

The point being that what you are seeing as benefits of password expiration are better achieved with proper polices that management and HR operate under... while password expiration may in some ways help you achieve your goal in a lazy manner it also opens you to ALL your employee's using weaker passwords and giving you way more attack points than the off chance that someone decides to not follow the policies you established above.

Also none of those policies require an "IT pro" ... implementing them might, but understanding the goal of the policy and putting them into place is something any good management team should be able to accomplish.

I agree with you in principal, but is also important to remember that policy != practice. For a policy against shared accounts, for example, there is no reasonable way to guarantee that Employee A has not given his password to Fired Employee B.

if you are compromised in that manner "Employee A has not given his password to Fired Employee B." then no password policy is going to save you.

Also remember passwords are only ONE part of your security armour, they aren't the entire suit.

http://i.imgur.com/kU3jB9B.jpg

http://i.imgur.com/OeIRC5U.jpg

An APT isn't going to log in with the password every time. They're going to install a rootkit.

Unless you can only change on a pre-defined interval, the attacker can always change your password for you to avoid being locked out. I don't know many users who would complain their their password seemingly never expired.

These are often combined with a requirement to not reuse some number of recent passwords, so the attacker can't change the password right back again. When you can't log in then your password will be reset and they've lost access.

That's true, I hadn't thought of that. Holiday week has my brain off in the clouds.

That is the entirety of PCI

PCI is nothing more than Security Theater so Mastercard and visa can claim it is all the merchants fault for data breaches and shield them from any liability

Credit card numbers themselves are security theater.

Not half as bad as Social Security Numbers.

SSNs are identifiers and when knowledge of SSN gets you some privileges, it's problem with whatever gives you these privileges. Card numbers are on the other hand essentially explicitly designed to be used as authentication data and at the same time printed in big letters on the card and known by all parties involved in transaction.

They're both pretty bad.

My passwords are always surprised or overly enthusiastic. MyPassword123! Soon becomes MyPassword123!! And then as I progress in the company my enthusiasm gets even more hyper MyPassword!!!!!

It's fun to know that almost every requirement usually gets solved by capitalizing the first letter, by prefixing or postfixing the number 1, but using the "!"... and that's what the majority does.

Where does it require quarterly rotation? I'm not seeing any specific time limit in the PCI DSS, but I could have overlooked it.

I thought PCI compliance required you to follow A standard (they didn't dictate which one) as long as it was a recognized industry standard and you were consistent with it. NIST would qualify...

We're going through various audits for PCI right now. Our auditor insisted that we need to add checks for reuse of recent passwords.

However, I've heard that the process varies widely depending on who your auditors are. Some are apparently very permissive, but we got the other end of the spectrum.

I also love that one. I am not yet finding the specific citation in the actual linked repo. I would appreciate it if someone could point it out!

We have a script that updates our passwords for some automated processes. So let's just increment a number inside the password every month with some perl!

  /^(.*?)(\d+)(.*?)$/

Love the /e for executing the substitution

    $ echo abc9def | perl -pe 's/(\d+)/$1+1/e'
    abc10def

"Autumn2016!"... ftw!

I worked at NIST until recently, and my password expired every 90 days. We also had separate passwords for a half-dozen legacy IT systems (timesheets, travel requests, IT support, etc), all with more stringent and senseless length/character requirements than the last. And password managers were not allowed per security policy.

It was frustrating.

3M has made a lot of money out of these companies.

So did you use a written note in your wallet or a password manager on your smartphone (from which you can read it)? What did you or the average colleague do?

At my last employer, my standard corporate password ended in a '4'. Due to muscle memory, incrementing it to a '5' didn't work so well. Instead, I just started repeating that final character every couple of months when the forced password change came around.

My password wound up being "<main-password>4444444". Was always a little mystified that I could hammer out seven 4's without counting them faster than I could remember that I was at a suffix increment of "10" or "11".

I like the rule but enforce a yearly password change in my Windows environment. I'm just a little paranoid about cached credentials living on machines for long periods of time.

I'm guilty of this as well. Just a week or two ago I went up to 23. Adding one for the first period when I had no number on the password, (90 * 24)/365.25 = 5.91 years

I started the first week of December, 2010.

> Knowledge-based authentication (KBA) is out.

All the rules are great, but this one might be my favorite. Every time I faced a list of KBAs I felt like I was trapped in UCB's comedy sketch:

https://www.youtube.com/watch?v=tMEjpXJZgIA

(If a common security device is bad enough for a comedy troupe to have a bit on it, maybe it could use some work.)

The worst KBAs I've seen are for United's frequent flyer program. Almost every question is of the form "What is your favorite X?" X includes items like "vegetable" or "summer sport." Maybe most people have strong opinions about the superiority of broccoli and tubing, but I was always just scratching my head. (The questions were mandatory and you could not write your own.)

Yes, my mother's maiden name is Een3oquu+P_a9oez0queiPhaeChaijoh, why do you ask?

Ironically, you usually can enter a string as answer to those questions that is more secure than the allowed password.

You'd think. United gives you a drop down with around ten common answers to choose from.

If you happen to have a favorite vegetable, but it's, say, the daikon, you're out of luck.

And then you call phone support and they ask you for it.

Amazing how we don't allow support to know the password, but the security question answers that allow access - that' fine!

If I had to break in to an account, I'd choose one that used recovery questions. That'S far easier than cracking a password.

"I just entered a string of random characters."

"That is correct. Thank you."

mentally: "I knew he was the kind of guy who would do that."

"Go ahead and transfer all of the billing information to this address and change the email to evilhacker@guy.com. Thanks."

CSR: "Sure, I'm happy to be of help."

I actually had this happen once. The conversation went something like this:

Them: "I need to ask you a few security questions. What's your mother's, uh... mother's maiden name?"

Me: "Oh yes, I put a bunch of random letters and numbers there, let me pull that up for you... A Q 1 #..."

T: "... That's okay thanks. Next question: what street did you grow up on?"

M: "Same deal there?"

T: "Yeah, we're done."

I got the feeling the support agent had never seen someone do this before and thought I was crazy.

Looks like some good suggestions:

- Glad they're recommending a stop to the pointless "password must be no longer than (16, 20, ...) characters". Aren't you storing a constant-length hash anyway?

- Why do some logins restrict which ASCII characters can be used? When I see that I can use any symbol from '%!#&' or whatever list they provide, I can only imagine it's a really naive SQL-injection defense. Is there any valid reason for this?

- And glad to see they're recommending against "security challenges". Half the time I'm forced to pick a security question, either none of them apply, a bunch of them are ambiguous ("what's your favorite movie?" - uhh, I'll give you a different answer depending on my mood, etc.), or they're easily searchable ("where did you go to high school?")

Unfortunately I doubt the bad actors will pay too much attention to this. I know Google is planning on dinging sites that don't use HTTPS, is it possible they could ding sites for poor password policies?

> Is there any valid reason for this?

If they know that at some point they'll have to ask you to enter your password over a restricted input-method (e.g. on a DTMF keypad.)

Real world example of this "limited input" problem: http://apple.stackexchange.com/questions/202143/i-included-e...

Pre-Touch Bar, of course...

Yep. FastMail restricts spaces in passwords due to mail clients that do not allow them.

Which clients specifically?

(FastMail developer here)

The issue was actually that we support many different protocols (not just mail) and some combinations of clients/protocols have had issues in the past (it might have been some FTP clients I think, but can't remember right now.)

Anyway, this restriction no longer applies as we now require server-generated app passwords for 3rd party apps: https://www.fastmail.com/help/clients/apppassword.html. So feel free to use as many spaces as you like in your password!

I didn't know that, thanks, and thanks for providing a product I can rely on!

I just use the security questions as another password, like my favorite color is JyQ|l[Duc-I6KrU-0k and I went to elementary school at ?YfBW+Yurh@m$lml":.

Those are rough when a customer service rep asks you for one of those over the phone... :)

I was literally just about to post this. I refuse to make my password less secure though - and security questions really are just "alternate passwords".

I've never had a problem but I have had a few reps who are trying to not act really surprised. I've had one instance of someone trying to stifle laughter (of the "You can't be serious") kind. Taking security seriously is a rare thing. :(

They usually stop me after the 8th or so character. I'd be concerned but if any potential social engineer has the first 8 characters they likely have the full string anyways so stopping early makes both our jobs easier.

On several social engineering calls I've had reps who were happy with just "it's just a bunch of random characters, would be a little silly if I tried to read it out"

Wow, that's disturbing.

Perhaps I should say that my first pet's name was "mellower retry audited grieves" rather than "esrhciaiyzhkj". (Both are random, and both have very close to the same information content given the dictionary I used.)

I do this. I told the CS rep that my password hint was "just random characters mashed on the keyboard" and she accepted this and moved on. I'm not sure what to think of the security implications.

That's what you get when the reps can see the answers. The only working solution is to have the reps "log in" to the users account by entering the security question answer.

If the reps can see the answer, it's far too easy for the attacker to turn the verification process into a game of twenty questions.

I've had this before with my bank, when I've had to authorise a large card payment (for a car). I was asked various security questions about monthly recurring payments from my account (in the UK, so standing orders and direct debits), but I've so many I can't keep up, and I change savings accounts and health, car, home, pet insurer every year to get a good deal.

The rep on the phone kept prompting me when I was unsure. She'd mention an amount, then when I was unsure they'd say something like, "maybe it's for your mortgage...? Maybe the company begins with the letter 'N'?"

It was all a bit silly, security theater at its finest.

I had the opposite recently. Trying to log into my alma mater's website to get a copy of transcripts, but my account had long ago locked out. They asked me questions over the phone to reset it, but I couldn't answer any of them.

"What is your phone number on file?" Shoot, I don't know, it was an old number that I changed maybe 6 years ago...

"What is your address on file?" I've moved maybe five times since then? I tried "was it in another state?" to narrow it down, but the answer was "I can't say that".

"Okay, we can verify you by classes you took..." Great, now we're getting somewhere! I took Intro to Ethics. "We need to know what term." Okay, this is tricky, it was like 10 years ago... Fall of 2006? "We need to know professor's name." Um. I think I have the book here, I know he wrote it... Professor McLaughlin? "I also need to know the day of the week the class was held and what time the class was."

Are you effing kidding me? I wish I was joking. I ended up just calling my old advisor and he "verified" me with an email to the helpdesk.

I've found that the only known repository of all my previous addresses is Amazon. I really need to capture them to 1Password.

Pull a free credit report--you get one per year by law. It should have all your past addresses on it, or at least within the last X years.

As bad as it probably is, I've kept it in google sheets going back a few years now...

Replying to sibling.

Worse, if reps can see the answer, then this is equivalent to not hashing the passwords at all since you have a password-equivalent stored in plaintext.

FYI, if you click on the <x> minutes ago link above the post you can get a reply box even on new posts.

When I worked for t-mobile it was last 4 of the social unless the customer requests otherwise.

Few requested otherwise, and usually it was because they were annoyed about people being able to see part of their SSN.

>> they were annoyed about people being able to see part of their SSN

Part of? I worked for AT&T back when they merged with Cingular. We only asked for the last 4 over the phone, but the entire 9-digit SSN was shown in the app. Every single low-level employee had (has?) the entire SSN in front of them. Never dared tell a customer that little fact when they made a fuss over my having access to their last 4.

Many password managers have a setting to make a password pronounceable, which is perfect for this use case.

Some systems allow entering your own security question and answer, in which case my security question is always "What's the other password?".

There are some companies that make you choose from a list of answers too. United Airlines is one.

My suggestion: use a nonsense answer and use it for all of them. I don't reuse passwords but for exactly the reasons you state the answer to all my security challenges is something like "Because a kipper doesn't red the blue."

Alternately have a few nonsense phrases for stock challenge questions (first car, first pet, favorite <thing>, etc.) It's better than using the real (googleable) answer.

Finally, as Dale Carnegie would have loved: the more absurd it is the easier it is to remember. So while you won't remember if your favorite movie is the matrix or titanic, but you WOULD remember "I clocked blithely cookie everywhere." as the answer when you see that question.

Pafwert [1] creates the absurd really well.

[1] https://github.com/m8urnett/pafwert

Here's what I use to generate answers to secret questions:

    < /dev/urandom tr -dc a-z0-9 | head -c 16

This leads to things like:

> "What is your first pet's name?"

"q1ry9nftmxb1gmag"

I haven't had it happen yet, but I wonder what a customer service rep's response will be when I spell out "yrlmduihhyju5il0" when asked what my favorite color is.

The guy on the phone laughed. I've moved to providing a few random words, easier to say over the phone than capital y lowercase r number 1.... etc.

The woman on the phone at the utility company that was messing me around didn't laugh when I said the answer to my security question "what do you think of customer service" was "f*cking retards" :-D

Who even makes that a security question? I mean seriously. You might as well ask "What is your opinion on the color yellow?"

"What is your opinion of cargo cult infosec practices, specifically security questions?"

Going to guess they wrote it themselves in this case.

Be careful with it. Was dealing with credit card stuff (raising limit to go on travel) and when they were verifying my identity the policy was evidently to combine my questions with a "background check"

Said background check basically being they googled my name.

Which you would think isn't a problem until you get to "What school did you graduate from?" and have to go through four levels of reps to explain that (not actually what I typed) "Omelette Du Fromage" was my way of making it harder to social engineer my account.

I usually have fun with security challenges. And get annoyed at ones with multiple choice answers.

What's your favorite movie? -> a sexual position

Where did you go to high school? -> another sexual position

City of birth? -> something else from the kamasutra

Of course, that makes phone conversations where they ask you those security questions very fun.

Apparently, sexually explicit concepts (maybe all 'shocking' concepts?) are very highly memorable, so that's probably a good approach!

> When I see that I can use any symbol from '%!#&' or whatever list they provide, I can only imagine it's a really naive SQL-injection defense. Is there any valid reason for this?

One reason I've seen for this is that the website is just a front-end for some older mainframe system that has password rules from 1987. Banks and insurance companies are frequently culprits here.

" I know Google is planning on dinging sites that don't use HTTPS, is it possible they could ding sites for poor password policies?"

How they gonna do that? Do you expect Google to audit every site in their search ranks?

The same way to index websites: with web-spiders. They would need to write new code for this though. Also for HTTPS they also had to write new code.

How do you check if password is salted and hashed correctly afterwards? There's not much use of strong passwords if they are stored in plaintext anyway.

Couldn't Google just auto-register an account with a known good password, and penalise the account if it fails? Someone else mentioned improving the http authentication 'api', which would definitely help in this regard; until then there are drawbacks to the auto-register approach including things like captchas. Sites would have to explicitly allow the Google bot to bypass them.

They should have required proper guiding when creating a new password. I normally use passwords that are like 80 characters long, generated in a password manager. If I paste one of these in a password field, then submit, I get the warning that it's too long. Why didn't it say so when I pasted it? Why put a limit on it below 256 characters? Does that really matter nowadays? It's not a 5MB selfie I'm uploading.

The limitions of the password should be built in the HTML of the form like a regex or something easier.

I've written into several companies in the past saying "your password policy are bad for __ reason", and they always of course write back saying basically "our security team doesn't care, shut up". There've been quite a few times I've cancelled accounts right after signing up because of just how absurd they were (for instance I believe Trade King forces you to click type your password with the mouse on an on-screen keyboard just in case you have a keylogger malware).

It's great that there's now a "right answer", and it seems to be based on some solid research about what actually helps and what doesn't.

In a similar vein I wish there were somehow a standard for http login and change password requests. Right now password managers are pretty hit or miss about whether they can actually fill a form and log you in, sometimes it just can't find the right field, sometimes there's a javascript field check of some sort so you have to click into the field after the password manager fills it before you can submit, etc. Having some kind of a standard would let you more reliably be able to automate logging in, rotating all passwords (at least on accounts without MFA), etc.

There's not "Now a 'right answer'" NIST standards have been around for a while; the companies you've mentioned are just even more arrogant idiots than you originally thought :-)

Given that password autofill built in all browsers, it should be part of HTML, IMO. Something like <form login><input type="text" name="username" username><input type="password" name="password" password></form>

Aren't passphrases kind of a bad choice for passwords? If all you are ever really guessing is the symbols that make up someones password, and you know that for example they have 4 words that make the passphrase, then you effectively only have to iterate 4 symbols with a known list of possibilities for each symbol (i.e. the dictionary).

If you compare the permutation space of a short passwords (length 7) with random characters (say ~80 potential symbols), with a long(er) password made up of 4 english words (say ~3000 potential symbols, the most commonly used english words).

    character_symbols = 80
    word_symbols = 3000
    number_of_character_password_symbols = 7
    number_of_word_password_symbols = 4
    permutation_space_characters = character_symbols**number_of_character_password_symbols
    permutation_space_words = word_symbols**number_of_word_password_symbols
    print('%.2E' % permutation_space_characters, '%.2E' % permutation_space_words)
    ('2.10E+13', '8.10E+13')

The words space is four times bigger, but in the same magnitude as the short (bad) password. I'm not an expert here, so I might have stuffed it up, but it seems like passphrases shouldn't really be encouraged?

I do love the recommendation to remove time-based password expiry though.

How do you know how many words are in the passphrase?

You don't I guess, I'm just using 4 as an example (it's also the number of words used in xkcd's password strength comic).

I only ask because a different answer will change the math drastically.

No it doesn't. Your password has as much entropy as it has, and no more.

If you want to follow that train of thought to its logical conclusion, your attacker not only doesn't know the length of the password, they don't know what character sets make up the password either, and so you could claim that a 4-character numeric password is equally secure to a 64-character Unicode password. In fact by inductive reasoning 4-digit password could be said to have pretty much any finite amount of entropy, because how does the attacker know that it's not actually length N+1?

Yes, the attacker not knowing exactly what the password class is (words/character set/length) does help somewhat in a practical sense. But it doesn't "change the math" at all, if you have 3000 symbols (words) and your password is 4 of them then you have 3000^4 possible passwords. You don't get to count passwords that are not in your password class as part of your entropy.

I didn't mean math in general, I meant the math used in the post I was responding to, which had some unfounded assumptions. I can make assumptions too with vastly different outcomes, I'm sure that 10 random unrelated words are more secure than 10 random unrelated characters.

Everything in the article is spot on, I only wish they went further and recommended passphrases more strongly. It's correct horse battery staple and all that.

As for your calculation, you are about right. Except memorizing a completely random 8 character password drawn from an 80 symbol alphabet is /extremely/ unpleasant for most people, especially when you may have a few different passwords you use on a daily or weekly basis. And for passphrases, 6 words drawn from a 4096-word dictionary is typical. I use that setting (or even 8 words for more important things) and have easily memorized about a dozen passwords, even ones I use only once every few weeks.

40966 = 4.7e21, about the same as an 11-character random password.

So you have memorized the equivalent of a 60-word nonsensical poem?

Well, you only need to memorize the passphrase of your password manager's file.

Yes, 80 ^ 7 has the same order of magnitude as 3000 ^ 4. But passphrases are recommended because many folks can memorize a passphrase more easily than a password of equivalent complexity. Or because a typical user's idea of an okay password ("Johnny88") has less entropy than a passphrase.

Passphrases are unnecessary for users with a password manager, except maybe for the manager's master password.

Now use a couple words not in the top 10,000. Suddenly your complexity goes waaay up.

What we should really talk about is the password entropy like what you've done.

If you take the xkcdpass package from Ubuntu, it uses a word list of 41230 words by default [1]. That's 41230^4 and about 61-bit of password entropy. If you want to use a smaller word list, add words to the passphrase until you reach a desirable password entropy.

Using your example of 80^7 for random characters, that's only 44-bit password entropy. So in this case, xkcdpass gives you a stronger password with just 4 words. If you want to reduce the word list to 3000, just add 1 more word and it's 46-bit password entropy. A decision between 7 random characters vs 5 words.

I personally prefer random characters because you can up the entropy significantly, and I have no problem remembering random sequence in the mid-teens range. That can easily get you 90-bit entropy or more. Everything else is saved in my password manager and there you can up the entropy even more. My auto-generated passwords are usually around 200-bit entropy.

  [1]: https://github.com/redacted/XKCD-password-generator

> I personally prefer random characters because you can up the entropy significantly

Isn't it far easier to up the entropy of a passphrase, though? Unless your password is using the entire Unicode character set, adding a word to a passphrase is going to give you better entropy than adding a character to a password, and it will probably be easier to remember since you can - reasonably safely - give it contextual meaning.

I love this. I despise the fact that my bank restricts passwords lengths to max 16 chars, hash lengths are constant, it is ridiculous. It is a BANK, if anything they should be more secure.

Instead they force me to make passwords that easily fit a password mask by restricting special characters and forcing at least one number, uppercase letter, etc. They are actually weakening the security in a vain attempt to get people to make stronger passwords. All they do is make it P@$$w0rd instead, no increased security, it is so predictable

I think disallowing SMS for 2FA will make it harder to get people to use it, if they finally decide to signup then they are informed they need an authenticator program. Also there have been times my phone was dead and I didnt have a backup plan.

> there have been times my phone was dead and I didnt have a backup plan.

This. Just recently this happened to me when I needed to get into my Gmail and I was shit out of luck. Didn't have my phone on me. The best Gmail would do was some sort of account reset that would take 2+ days (for good reason). I was entirely locked out, no solution short of returning home to get my phone.

Anyone recommend a solid backup plan?

In the Google case you can print a set of backup codes. See the security page under your account.

> Knowledge-based authentication (KBA) is out

Finally! This is my biggest beef. I've taken to generating long random strings as answers to these questions but in some cases that's insecure too because they present you with a multiple choice set of answers and then it's obvious.

Also glad they're getting rid of ridiculous composition rules, hints, and password expiration.

I would love to see an explicit recommendation of "no disabling paste" in the NIST standard... so that I can contact companies that do so and drive me nuts. The article implies that disabling paste would run afoul of the NIST standards, but is there actual language I could point to?

I would sure hope so. I managed to convince a company to allow paste in their login form by tweeting them this article: https://www.troyhunt.com/the-cobra-effect-that-is-disabling/

But I doubt most companies would be this reasonable if they have this level of stupid in their password handling.

In addition to the standard salting and hashing, they recommend using an additional key stored separately from the data.

> A keyed hash function (e.g., HMAC), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

I guess using a pepper is a better-than-nothing measure, if you don't have a hardware security module.

> and should accept all UNICODE characters, too, including emoji

Hell no. This WILL lead to disaster, especially if people store their passwords in managers that may or may not mess up Unicode. UTF-8, for example, allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look visually identical, yet fail any string comparison.

Not to mention the support calls "I'm in $random_foreign_country and don't have $random_char on my keyboard, cannot login"... good luck trying to match the kitty emoticon on your Android phone to the random font on a website to whatever input system iPhone uses. Or when they're used a German Windows keyboard and suddenly have to use a German Mac - basic stuff like the tilde symbol ~, pipe symbol | or the (square) brackets {[]} are not marked out on the keyboard.

I believe that it makes sense to display a warning "Your password may be impossible to type in another country/using a non-$current_platform keyboard" when such characters are encountered.

  > UTF-8, for example, allows to encode the character "ä"
  > [...]
  > I believe that it makes sense to display a warning

Both of these are addressed in section 5.1.1.2:

"If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15] using either the NFKC or NFKD normalization. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully."

https://pages.nist.gov/800-63-3/sp800-63b.html

> They look visually identical, yet fail any string comparison.

That's a non-issue. You should normalize unicode strings to a common form (preferably NFC) before any comparision.

Personally, I think passwords should be opaque sequences of bytes that just happen to be mostly easily input on a keyboard, but I agree with the warning: some might even consider such a warning a good thing.

The problem with that is, which keyboard? USA, German, UK, Japanese?

> UTF-8, for example, allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look visually identical, yet fail any string comparison.

Well-designed high-level programming language (see Perl6) compares strings depending on how they look, not on their binary representation [0].

For example let's play with Perl6 REPL:

  > my $a = Blob.new(0xc3, 0xa4)
  Blob:0x<c3 a4>
  > my $b = Blob.new(0x61, 0xcc, 0x88)
  Blob:0x<61 cc 88>
  > $a eqv $b
  False
  > $a.decode() eqv $b.decode()
  True
  > $a.decode() eq $b.decode()
  True

As another example, Python3 would fail:

  >>> a = b'\xc3\xa4'
  >>> b = b'\x61\xcc\x88'
  >>> a == b
  False
  >>> a.decode() == b.decode()
  False

Perl6 is definitely going to dominate the world one day.

[0] https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-p...

Question: how do you store data encryption key for each user?

because:

- you get the password form the user

- compute the PBKDF2 with iteration and a salt, store iteration$salt$hash (where hash is the result of the PBKDF2 on the password).

- when user logs in check that the hash matches the PBKDF2 on password with iteration and salt.

But now, i've a the data enccryption key (DEK) and i've to store it somewhere. I can't use the password directly to encrypt the DEK since the lenght must be 32 (or 16, or 24). I should use PBKDF2 to derive a 32 byte hash, but this value is already stored in the password_hashed field. Should I compute anoterh PBKDF2 with a different salt and a different iterations for the encryption of DEK? if so i'll store in the db just$iterations and encryption and apply those to the password (after the user logs in) to derive an encryption key for the DEK?

What's a good approach?

I'm no security expert, but I'm pleased to see several things being forbidden that in the back of my mind, I always thought were a little fishy.

What's the only thing worse / stupider / more annoying than secret questions?

Secret questions that don't even have a free form text box for the answer! That means you can't even put random text in them. You have to select from a pre-canned list of 5-10 options.

Good riddance!

If SMS isn't a recommended 2FA, do they recommend some other means of 2FA?

Many [1]. Some examples, my comments in parentheses:

- Out-of-Band Authenticators (mobile app over secure channel)

- Single Factor OTP Device (like an OATH push-button, enter 6-digit code TOTP device)

- Single Factor Cryptographic Devices (insert into computer)

(among others)

[1] https://pages.nist.gov/800-63-3/sp800-63b.html#sec5

Also "Single Factor Cryptographic Software", which I think means client certificates.

Which is a real shame. SMS might not be perfect, but it's a real help when I don't have a better means handy. Its better than no 2FA, and it's saved my butt a few times when I get a text message saying "Here is your login code" and I'm out walking in the park.

I get a new phone every year, and Google Authenticator sucks for that, but it's by far the second most common 2FA provider. I just got a new phone today, and had to go disable 2FA on all my accounts then re-enable it to generate a new code. SMS is always a good fallback in my experience.

> SMS might not be perfect, but it's a real help when I don't have a better means handy. Its better than no 2FA

If used exclusively as a second factor, yes, it's better than nothing. However, many systems also allow you to use a phone as a password recovery system, which makes it much worse than no 2FA. Many people have had every account they own broken into, starting with a social-engineering call to their cell service to get their number moved to a new SIM/phone, followed by a reset of their email, followed by a reset of everything else.

I got a U2F key, which neatly solves the problem as long as you have a USB port. The integration into the browser makes it painless and fast to use.

Adding bluetooth to work with mobile devices would make it a complete solution.

Edit: corrected U2FA to U2F.

How does a U2F key help you? Most places don't support U2F.

Bluetooth and NFC are standardized, and the first products are out. I really hope U2F and UAF are gone 'make it' in the market.

I think it's crucial for Gmail, because the popularity of email-based verification means that if you lose your email account you lose everything. Including the presidency, in John Podesta's case!

I also use it for Bitbucket and Githib, but I take your point and also hope it becomes a widespread standard.

SMS 2FA is only as strong a your voicemail password.

You can buy a Yubikey, use the Yubikey Authenticator instead of the Google Authenticator, its more secure by far, and you can use any Android device at any time.

Or use a Cloudbased system, LastPass Password Manager for example does this. Authy does the same thing.

I use 1Password for time-based one time passwords. They're very upfront about the limitations, and I'm comfortable with the tradeoff, especially since it has eliminated the hassle of setting up Google Authenticator repeatedly.

https://blog.agilebits.com/2015/01/26/totp-for-1password-use...

Thats why i always save the qr codes to an encrypted image on my HD.

I use Authy - it's been a life-saver for having various phones get: Replaced, broken, reset, flashed during dev, etc.

> Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!

Man, I predict a world of hurt here. Maybe it'll be okay if the standards also very prominently tell you you've got to unicode normalize before hashing, and tell you what normalization form to use (NFC I think?). Too many platforms/environments still don't have handy access to unicode normalization though.

It actually does:

https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-sec...

I can't wait until we all start using emojis in security answers: "What's your mother's maiden name?" "Smiley face - no, the one with the really big grin - man wearing turban - with the same skin colour as Obama - pile of poo, ..."

Glad to see the knowledge based questions are being phased out, many are sadly answerable with a cursory search query or leaked in previous breaches.

I didn't see anything in there about security images/indicators, which have also been shown to be ineffective: "was this bank the image of the man snowboarding, or the woman skiing...?"

Password strength is meaningless when the password can be reset via an email provider that allows weak passwords.

True. Google does a good job here - they support U2F (and other password hardening techniques), and additionally report any access from a new device. You do have to opt in to these measures, but at least they are available.

Password max length should be minimum 64 chars as specified in https://pages.nist.gov/800-63-3/sp800-63b.html#aal_privacy.

We want to know what compliance levels apply for the above rule in an enterprise product. Anyone knows where I can find compliance levels for Products targeted for Enterprise customers ?

8 characters seems very short.

I like asking people to pick 4 words and a number. Satisfies the length issues.

But... I love emojis and other things being possibilities. Cool.

They shouldn't pick 4 words, it should be randomly chosen for them.

At which point, they hit reset password (either on that page, or on successive logins) until they get four words that stick trivially... because they're a normal sentence.

Slow them down?

To bend a cliche, users interpret things in their way as damage and route around it.

Seeing as NIST recommends PBKDF2 over bcrypt and scrypt should we assume that means NSA can crack PBKDF2 faster / more cheaply?

This is the first thing I thought too. I've consistently heard the opposite but am not a cryptographer.

The article Sophos links with regards to an explanation for choosing PBKDF2 over bcrypt or scrypt goes over numerous obviously bad practices like cleartext storage, then states the following, without further detail:

We’ll recommend PBKDF2 here because it is based on hashing primitives that satisfy many national and international standards.

This seems like a vague and probably misguided line of reasoning. What specifically would make that recommendation rational? bcrypt wasn't new in 2010 when NIST published the article recommending PBKDF2, and they haven't made the switch since. Dual_EC_DRBG was recommended by NIST in 2006 which makes me deeply skeptical of anything they say.

If anyone could provide the motivation for choosing PBKDF2 in reasonably terms I'd appreciate it.

The best motivation I've heard is here: http://security.stackexchange.com/a/17088/77002

Essentially, blowfish (Bcrypt) doesn't appear to be FIPS-compliant, so if you have to be FIPS-compliant, you use PBKDF2.

And, considering the rest of the comments about why Bcrypt is preferred over PBKDF2, it appears it's all about how a GPU gives a significant speed-up for PBKDF2 but not Bcrypt. But now there are FPGAs that significantly speed up Bcrypt in similar fashion, so it could all be a wash depending on who you talk to.

What are the alternatives to SMS two factor authentication? Software like Authy? Even if it's easy to get around SMS wouldn't utilities like Authy also have vulnerabilities, or is the idea that at least they can be patched?

Also systems should always notify users if their password or email address has been changed, immediately alerting that they've been compromised.

2factor authentication is great so you always know if someone is attempting to login as you.

Alas, Google forces me to use ASCII only passwords: https://support.google.com/a/answer/33386

How the f@@@ on the year 2016 we have a 64 character max length password requirement!!

That's a minimum maximum requirement. It says that the password must be allowed to be at least 64 characters long, not that they be at most 64 characters long. Combined with the forbidding of composition rules and the demand that all ASCII and Unicode be allowed, 64 characters is more than enough.

If you allow unlimited length, that a DoS attack. Ask the devs at Django

For which they set a 4K limit on password length. I think even the commenter you replied to would find that satisfactory, being much more than 64 characters.

But what if I want the complete contents of war and peace to be my password?

  You can't always get what you want
  But if you try sometimes well you might find
  You get what you need

It's pretty arbitrary when you get to 64, IMO. If a site enforces a maximum below that, I'll feel suspicious and treat the site as if it's storing my password in plain text; that maximum or higher reassures me that they probably know what they're doing.

Of course, one day, a 64-character password will be brute-forceable in milliseconds, but we hopefully won't still be having this discussion by then!

I agree, though I also think: why have some arbitrary limit at all? Mind you the 4K Django limit isn't arbitrary, they know that at some point beyond that they'll spend too much time in hashing-land and will have opened up a DoS attack vector.

I would argue 4K is effectively unlimited... maybe in the sense of an ISP/phone company "unlimited data plan" unlimited, but still... the likelihood of user knowing of the limit is very small. I use a password manager that maxes out at 100 characters in its password generator (a default I use because... why not?) However, in those small cases where I do use contrived passwords, I make use of passwords that are really pass-sentences (with a few extras thrown in). It's pretty easy for me to blow by 64 characters (and sometimes 100) in those cases; not because I think I'm gaining extra security due to length, but because I'm just throwing out the first, easiest to remember sentence that crosses my mind and that I know will be reasonably secure. A service that flummoxes that effort just makes it less likely I'll use the service (assuming that it's use is discretionary).

64 lowercase English letters is 10^92 bits of entropy, which is around the same number of atoms in the universe. Eventually the laws of physics put an upper bound on how much entropy you need to avoid brute force attacks.

When that happens, turn up the work factor on the hash.

And 64 is a pretty low limit if you want to use a passphrase.

"He who fights monsters will have to look into fighting scammers too" is both a decently difficult password to guess, pretty easy to remember and too long.

I'm sure there's a good reason why this won't work, but wouldn't it be possible - over SSL - to have the client generate a salt and hashed password, and send them (separately?) to the server? What's the hole I'm missing?

The don'ts list is pretty much a christmas present from NIST. I hate all of those things. Worst is the stupid security questions.

Apple still uses those and it annoys me. Yes, others still use them too, but I give Apple extra crap because I think they should know better by now but either they don't or don't care.

You can't change your existing password in apple if you forget your secret question/answer. I gave gibberish to these secret pet/school. Now I am unable to change my password ;-)

I use passwords from https://www.random.org/passwords/?num=4&len=8&format=html&rn...

FAL3 is not used in LOA- seems like it won't be used much.

Relevant xkcd: https://xkcd.com/936/

Reply on news.ycombinator.com