New NIST password guidelines: don't require character types or rotation
pages.nist.gov
pages.nist.gov
I'm cautiously hopeful that this will supply needed ammunition for those advocating for saner password rules and policies in organizations big and small.
Verifiers SHOULD NOT prevent users from pasting secrets from the keyboard.
Banks: this is to prevent attacker use keylogger or mouse position logger.
I was like, are you fucking serious ?
It does now! This is why it's so important to use a method like diceware to select a strongly random set of words for your passphrase.
If so many sites didn't have a limit on password length, I would use UUIDs.
BTW, is there any reason to have a short limit on password length? I'm talking less than 20 characters? I could understand limiting it to 100 characters, but when it's short it makes me feel like the site might be storing my password rather than a hash.
Honest question since I want a solution to that problem. I want separate credentials for my home and office computer so even though I use a password manager I have like 3-4 sensitive passwords I have to keep in my head.
My office computer has a relatively weak password because there's nothing on it that is personally sensitive. They force a password change every three months so I added a counter to the password and just increment that each time (pa$$1word, pa$$2word, pa$$3word, etc...).
I would imagine in the "real world" outside strict culture fit requirements that a certain percentage of passwords will be popular bible verses, for example.
There's a curve where the likelihood of collision or predictability is very high with short passwords and it declines with length until it starts increasing again.
I used to use full engineering parts numbers of semiconductors I used in projects. I also used some verbose API names that I used a lot. In retrospect that's a terrible idea. I wonder how many people sitting next to me used the same password.
Was it "Live long and prosper" or "He's dead, Jim"? The latter seems more suitable given the circumstances :)
I actually looked it up: 1,1A(bunch more stuff here)000Destruct0 it was kinda long. From memory that movie even displayed it on the screen so the guys used the same capitalization and everything.
https://www.schneier.com/blog/archives/2014/03/choosing_secu...
The main point from his essay is anything that can be remembered can be hacked. He then softens that statement to show a way to take your memorable phrase and turn it into something stronger.
Most of the time these days we're talking about online services or devices where there are practical limitations (or software limitations) imposed on how quickly we can "guess" a password. This is the most important use of passwords, their strength within a hash should be a concern of the proprietor rather than the user.
Specifically using a salt + pepper, and a hashing algorithm that can be made computationally expensive (or use some other finite computing resource like a lot of memory or even GPU power).
> This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick.
Them being "on to this trick" doesn't defeat it. It is mathematically stronger. The US-English keyboard has 100 common characters on it. A eight year old child knows over 2,600 words. The key to an "XKCD password" is that one letter in a "random" password must be equal to about half a word in an XKCD-style password (e.g. 8 characters = 4 words, 6 characters = 3 words, and so on).
So:
"12345678" (8 chars)
"OneTwoThreeFour" (4 words)
Are equally as secure (still terrible passwords, but the maths works out). That's because, assuming a "bad guy" knows your trick, the search space is much MUCH larger for an XKCD style password than a traditional password.
Schneier is just mistaken, word-based passwords assuming a reasonable length almost always perform better than random characters, and the maths shows that pretty steadily. We ASSUME a bad guy knows what we're doing, that's a given, but again it is still a much harder task for a bad guy even with perfect intelligence.
Maybe there is a difference between what is supposed to be protected. The login to some server based server? Or something I use locally like my tax files.
He wanted to rant and therefore didn't read the description of the "xkcd scheme" with enough concentration to understand it.
Legions of security people debunked Schneier, but unfortunately he didn't have it in him to retract his claim and update his post.
This blog post is the best example you can give of Schneier quitting academic discourse and becoming a pundit.
If you make a password from an alphabet of 64 characters (upper and lower case, digits, and some special characters), there are 6 bits per character of entropy so a ten character random password could have 60 bits of entropy.
If you are choosing words from a list 4000 words long, there are 11 bits of entropy per word and so you would need to string together five random words to get a password of equal strength. The big problem then is having enough space to type that many characters.
Edit: that's a pretty nice slide deck. Thanks for the pointer.
Personally, I'd rather bet on something like Diceware.
[0]http://www.lingholic.com/how-many-words-do-i-need-to-know-th...
Some words are way more common than others, and they are much more likely to be found in your passphrase if you didn't use an external random index generator (be it a set of dice or /dev/urandom), because of availability bias: you're more likely to chose common words, or even worse, uncommon words pertaining to your interests.
Diceware uses a smaller set (about 8K words), but if you select them truly randomly, you'll get close to 13 bits of entropy per word —guaranteed. I wouldn't cry too much over the loss of 2 bits per word, because Diceware words tend to be short.
Then again, even a word in a grammatically correct sentence is likely to have more than the 6-7 bits of entropy a character may have. I wouldn't bet on anything above 10, though.
I've heard the average entropy of English is 3 bits/character, in which case 14-15 bits sounds about right for a word.
91 characters, in 21 words. 4.3 characters on average, which would mean 13 bits of entropy. I don't believe it. It sounds like your source didn't account for word frequencies in real sentences, let alone grammatical constraints.
So just random words and half-words are appended, like: 'misfortune behold oratory plexum'
Then again, these things tend to just stick very well in my mind, so it may not be appropriate for everyone. Also, I only need to do this on certain services, so it's not that many to remember.
The hard part is when they then reply with "requires at least one upper case character, number, symbol, etc.". A certain XKCD comic comes to mind...
Lorem ipsum random garbage 1
Is there anyone reading this who has chosen to implement such limits? If so, why?
I haven't, but here's one answer I got from someone who did.
The bizarre password requirements at $WORK have the property that, sometimes, a subset of a password will be permitted when the full password would not be. I contacted our IT department once with a specific example of an objectively weak password which was accepted, and a stronger password (at least, it contained the weaker password as a strict subset) which was rejected. I proposed a concrete, simple-to-implement suggestion for how to relax the rules to avoid this kind of paradox. (I don't remember what it was.)
He agreed with me that this was an undesireable outcome, and that my proposal was implementable. However, he said that the institution would nonetheless not implement it, because people were used to the old rules, and would be confused if they changed.
(When I asked how people could be confused if all the old passwords were still acceptable, and the only change was that new, stronger passwords also became acceptable, he stopped responding.)
I feel like underlying all of this, there's a lagging perception that "spaces and special characters are hard". But when all you're doing is hashing them... they're really really not. Whenever I hit a max length limitation, I'm automatically assuming that particular password is being kept in plaintext.
And by forcing more characters you may end up messing things up because people can start using patterns that defies the very core idea why there should be a 'minimum length'.
And rate limiting (see 5.2.2) should take care of most concerns about it.
Though, I think this is bad > Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single account in any 30 day period.
Well, imho there MUST be no limit. This is prone to a DoS attack. Rate limiting and other things MUST be able to solve this one way or another.
Other federal agencies (IRS in particular) require lockouts with only 3 bad password attempts. That generates really high reset/unlock call volume -- easily 20-30% of users require intervention or reset compared to 7-12%.
[1] https://doc.satoshilabs.com/trezor-faq/threats.html#brute-fo...
Back in my time in the military, there was an online portal that held your service information, the ability to request leave (time off), pay, etc. It was the place to go if you needed information aside from a paystub.
It required 8 char min, two upper, two lower, two special char (from a predefined list), and passwords would expire every 30 days. The thing is, most people knew all of their service info off of the top of their head. People also weren't requesting leave very often either, so most people would have to change their password on every login from some bullshit permutation of keyboard rolling with numbers and special chars tacked onto the end.
All that being said, you only had 3 attempts before lockout. No one wanted to risk lockout, so you'd make a throwaway password and reset it if you wanted to login. If you were locked out, it was a call to a civilian contractor with a hold time of 10-30 minutes just to get a temporary password emailed to you.
One of the easiest ways to fuck with someone was to intentionally lock out their account. It was trivial to find someone's username via searching through the email global address list. Then you pull up the portal, enter their user, smash the keyboard, and cackle as you have cost that person a guaranteed 10 minutes minimum just to do something trivial like print something from their file.
I wonder why this didn't establish in the first place...
Do human users authenticate faster than once a second?
On a full sized keyboard, the normal rate is 3.3 key presses per second. On a mobile device, I'm sure an 8 character password will take far more than 1 second.
For brute force attack defense, rate limiting a single account globally to 1/sec, i.e. independent of source IP address, should be sufficient and prevent parallel attacks by bots, but this still makes DOS attacks on a particular account easy, but not the entire system except traditional overload.
Many API systems work this way and it's proven effective.
The iPhone for example has a PIN lockout, and young kids love phones.
More than once I've been punished by Apple for my kids curiosity.
That spikes costs. Many users (mobile) need to call someone, which is $$$.
Those interventions also lead to things like figuring out what app stored password is relocking the account. That kind of exercise could cost a few hundred bucks.
...all for zero benefit.
When will we see the first organization (government or private) that is effectively completely DoS'ed for days on end because their login does this, while all their email addresses are listed on their website? If sustained, I imagine this could shut down an entire organization quite effectively for a few days. Probably could lose someone millions. Or add insult to injury, and have them pay BTC for the attack to stop.
> > Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single account in any 30 day period.
> Well, imho there MUST be no limit. This is prone to a DoS attack. Rate limiting and other things MUST be able to solve this one way or another.
I agree. Nobody is going to guess a good password in 100 attemps, or 100,000,000 attempts. A tiny bit of rate-limiting, like one login attempt/second, should be enough to prevent successful brute force on good passwords.
The threat is hacking the database of hashes and brute-forcing offline.
Not in the case the hashes are leaked. However I agree very much with what you said otherwise.
Maybe I don't understand, but isn't the issue not your access to it, but others'? If you are forced to have a weak password protecting sensitive information, then it's an issue even if you never need to access that information yourself. (Or maybe you mean that you never even establish the account, and hence the weak password, in the first place?)
You can minimize this by making it per IP, for example. So, you'd have to have an idiot on your home. Yeah, maybe this is not 100% bullet proof given IPv6 and so on, but at least this doesn't introduce a vector for DoS.
So the answer is: Some are already doing that.
I think that can be read two ways.
1) 100 failed attempts/account/month 2) 100 failed attempts/IP/account/month
The latter still limits an attacker but is less likely to be a plausible DoS against the account unless the attacker has compromised the legitimate user's machine at which point all is lost anyway. Later in the same section:
> When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts from the same IP address.
Which suggests the failure count is per IP and not per account.
No, security is tough. The better security the less useful it is. NIST got this right. Do what you can, don't kill the user and implement security on the aaa side.
I was specifically addressing the DoS vulnerability of locking an organization out en masse by taking advantage of account lockout or timeout policy. A list of emails and a six line script could take a whole company offline.
MFA can be used to address that by requiring pre-auth before you can enter a password.
1. Scan a QR code.
2. You now have a secret value that can generate a deterministic pseudorandom integer securely indefinitely.
Also, SMS-based MFA should be burned to the ground.
Actual OTP should allow you to print out or write down a set of codes.
That's way different from "I don't want to give out my phone number".
Nobody gives a shit about low trust environments... go ahead and crack my slashdot account, but higher trust stuff like mail, money, network access etc absolutely need MFA.
Also, there is little evidence that entropy increases all that much when you force users to choose very long passwords.
Totally agree. I often encounter problems that go like this:
UltraSecureSystem: Create a secure password.
Me: "#@(J #!_04';/1~"
UltraSecureSystem: Password must be at least 8 characters long, can't include special characters and consists of at least one upper case letter, one lower case letter and one number.
Me: "Password0"
UltraSecureSystem: Congratulations, your ultra secure password created!
<After 1 month>
UltraSecureSystem: Your password has expired, create a new ultra secure password.
Me: "Password1"
UltraSecureSystem: Congratulations, your totally new and totally secure password created!
(Although this time I had a unique experience where I adjusted quite quickly from "2" to "3" and because I was still thinking "don't forget to incrememnt" ended up typing "4". Uggggghhhhhhhhhh)
pls don't hack me
As the implementer, I've argued many times about it, but the ITSec bods always think they know best.
Their website lists a lot of different potential applications, but I use it almost exclusively for entering passwords from KeePass. In addition to allowing password entry on the computer's lock screen, it also saves me the trouble of having to read and retype passwords manually on computers that don't have KeePass installed, and avoids exposing my entire password database to the computer it's plugged into (as would be the case if I used portable KeePass on a USB memory stick).
I personally find it unintuitive to think that people would give up on the "memorization" part if it became "too hard". It's true, and we know this from study, but to say it's "dumb" is unfair.
After a year of trying to keep track of the changes via a secured method (and at least 12 call to their IT so they reset the password without any identity check on their part) I finally resigned and write it down on paper and write the new one every time they ask me to change.
Bonus fun fact : Theses idiots also truncated password at 8 characters but truncated in different manners on the 3 login steps required so it's only after 4-5 failed attempts at a secured corectbatterystapplehorse that I understood that weak password was mandatory by their rules...
PS: And of cour rotation between Passwd1 passwd2 passwd3 passwd4 (then back to 1) was perfectly accepted and considered as safe
When processing requests to establish and change memorized
secrets, verifiers SHALL compare the prospective secrets
against a list of known commonly-used, expected, and/or
compromised values.
https://github.com/robsheldon/bad-passwords-index
I want people to use it. I gave it the most permissible possible license. Please people, use it. I'll even update it Real Soon Now.
My hat's off to you, good sir.
edit: Oh, "Convert your user's password to lowercase and do a simple string search against the index. No regular expressions are necessary." That makes sense, apologies.
[1] https://creativecommons.org/2011/04/15/using-cc0-for-public-...
https://github.com/timboss/Django-Common-Password-Validation
There are a few approaches that would work better for specific environments. I could make a gigantic Bloom filter for example, with lookup functions in a few languages.
But my goal was to make something that any programmer could use in any environment. Substring searching is a basic programming skill and just about everything supports it. (COBOL74 needs external functions to do it.)
So https://github.com/timboss/Django-Common-Password-Validation is just a a longer (10,000) wordlist, for example. If nothing else, it makes what you worked on more discoverable.
The packing program reads in a file, sorts the passwords into clusters based on their length, maintaining a popularity count as it goes. Then it prunes any passwords that occur less than some number of times in the input file ("4" by default, so it doesn't spend a lot of time churning on unpopular passwords). Next, starting with the longest passwords, it works its way down the list, merging the popularity count of shorter passwords into the most popular longer passwords which contain the entire shorter password. e.g., "password" gets merged into "password1234".
Finally it starts writing the output. Starting with the most popular password, it searches up to N passwords ahead in the list (40 by default), looking for any passwords that begin with the same characters that the current password ends with. So it finds "123456", and writes "password123456" to the output file.
I think the only thing I can do to optimize it further is to re-cluster the passwords by their starting character during the output stage, to improve its chances of always finding two passwords that can be glued together.
It's a crude brute-force approach but it works okay.
I just looked at the code, it's not that bad, I really will release it with the next update.
At least if you wanted to keep it as a long string. I'd still probably approach this as a bloom filter as others suggested since it'd let you have a larger number of entries for similar memory footprint.
The file is small enough, and the approach straightforward enough, that for instance somebody could write a trivial Wordpress or Joomla or Drupal plugin for it, and they wouldn't have to think about Bloom filters or have ready-made lookup functions.
I placed greater value on adoptability than cleverness.
For reference, common English dictionary words have about 24-bit entropy, a character has some 6 bits.
Even with good TLS it is a stupid risk to take when you could verify locally. (Just the DoS potential not to mention compromise risk.)
Actually, couldn't privacy-caring service providers also check current passwords against newly-leaked lists in case something pretty big gets disclosed and warn their affected users? Would probably take some time for services with big amount of users, but that would be some awesome help to users who use same passwords in most places.
(Source: I wrote the feature)
Pass1word
Pass2word
Pass3word
(my scheme at my last software gig when IT required periodic password changes)
>Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.
I wonder if Mastercard and Visa will reconsider this policy.
My answers to those (when required) always look like this:
> “What was the name of your first pet?” JBK?a0ly(VE3E-|-@BADZFPS<1Fh$X23
Where the "goop" is generated, and remembered, by my password manager (https://github.com/zdia/gorilla/wiki).
It really is scary, in that even my bank will fall back on things that are either easy to obtain or easy to guess, because they clarly have to deal with too many people who either genuinely have no clue, or like me can't be bothered to look up what I've answered. "Telephone banking password? I have no idea what that is. Did I set one? Sorry, can't remember..."
Second, after looking at KeePass (very briefly), it appears to be .net, and while it 'would' run on Linux, I'd have to install .net for Linux (Mono), and I'm just not going to do that.
I've found this to rarely be the case, and when it is there are additional verification steps / notifications that give you a chance to stop it (if it's a new payee).
This has to be applied to the whole password (which it implies anyway) or you end up with the rather silly situation which I encountered the other day when I had to create a temporary password for a Microsoft service. It absolutely refused to accept even a very secure password if there was a portion that was not secure.
For example: a password similar to "$4(password(!monsT3rDiet%@" was rejected. But if I removed the word "password" and made the string shorter (and therefore less secure), that was okay!
I had not even thought about normalization before in this context, but I could see it being an issue if a user moves to a new device. But what if new composed characters are added to Unicode, does that mean the user can no longer log in with NFC passwords? I guess that K in NFKC is important.
Here's one extreme example of it: "I included emoji in my password and now I can't log in to my Account on Yosemite"(https://news.ycombinator.com/item?id=10742351)
It's fun figuring out how to type Swedish and special characters on a foreign keyboard layout. Of course no part of the UI indicates this layout issue.
I think Unicode is good. I think companies should fix their broken input instead.
You'd also need to recreate that ramdisk if your hardware fails, and good luck booting from non-root encrypted volumes.
Using EN-US for boot disk volumes is pretty good advice.
Microsoft have thought this through - their recovery keys are ASCII numerals only and are entered using function keys since they're the only universal keys.
edit: relevent Technet: https://technet.microsoft.com/en-us/library/ee449438(v=ws.10...
I'm not sure I see the point of this limitation. At a first glance, it seems using the BIOS only doesn't buy us much.
Noone will ever figure out that the fat plug at the end of the USB cable is a keylogger =)
edit: or, in particularly terrible systems, if plaintext passwords were leaked.
Of course, that's only useful if it doesn't affect any other password security concerns, and it turns out that users who are forced to change their passwords frequently pick worse passwords, which is a bigger problem than the scenario this was supposed to protect against.
I can vouch for this. My rotating password at work is _______1, followed by _______2, then _______3, and so on. If a year-old hash gets cracked, it won’t take a rocket scientist to know that the password right now is _______4.
That said, lastpass can work without any modifications to your local machine(i.e. it can work without any browser plugins even) tho it's not very fabulously integrated, it does work... Assuming of course they don't block access to the lastpass website and JS.
In all fairness, it's a fair assumption. There is an attack vector where one gets an old password from 8 years ago by whatever means... and it is still valid.
The execution was terrible though. People started forcing password change every month [which is overkill to stop an attack that has a multi year timespan] and it created a whole new set of disasters.
Pity so few systems support this.
The cost of maintaining a sufficiently real-looking system is likely to be very high, with the very real risk that it won't fool an attacker.
It happens, all of the time.
Many people use predictable rotations (incrementing number, date appended), so if you know one, you know them all.
Also if they've shared it once, why would they not share it again? Put another way: why is making them regularly reset their password going to make them suddenly follow security protocol, when it didn't the last n times they had to change their password?
If the office thinks it's okay to share their password it's also a symptom of several things:
* Lax security environment, with not enough emphasis on security training and importance.
* Poor senior management. There should be reprimands for violating security rules, as severe as losing your job for repeat offenders, and obviously IT can't do this on their own.
* Bad work environment provided by IT. Why are they sharing passwords to begin with? Maybe the environment is overly locked-down with too many restrictions, or maybe the collaboration tools are just bad or missing.
Fix those, the password sharing stops.
It does help to limit the scope of who has passwords. Certainly not a perfect solution, but it isn't completely ineffective either.
Only if the rotation isn't predictable. If I receive "password3" and it doesn't work and Joe who shared it with me isn't available, I probably wouldn't think twice about trying "password4".
I agree that this approach is not very user-friendly.
Comparing old passwords without plaintext is really hard and at best inexact.
Storing them plaintext (or even reversibly encrypted) is completely stupid, of course.
Even if these technical problems could be solved, sequences like: November6, December7, January8 are not "similar" but easily predictable.
Even this sequence is probably not hard to figure out if you look at a keyboard: Secret1 Drvtry2 Ftbytu3
Deeper though, what security threat is this actually mitigating? Bad passwords caused by rotation requirements that are needed because of bad company policies, training and practices? Is there a security equivalent of "yak shaving"?
If only the hash and salted password is stored, as recommended, how would you know that "myOldPassword21" and "myOldPassword22" are similar ?
For example, I could use: myoldpasswordA1 / myoldpasswordB2 / myoldpasswordC3. Probably obvious to a human my next one will be D4, but it is a comparable problem to "play every possible game of chess" for a computer to figure that out.
Combined with using a secure computationally-expensive password storage mechanism (eg: bcrypt or PBKDF2) and I'm not exaggerating: it now takes billions of years to verify a password change is allowed.
And this is trying to solve a compromised password problem. If there's no compromise, rotating passwords is pointless.
If the password IS compromised, rotating the password doesn't really fix it, it merely limits access -- maybe. It doesn't address the original means of the compromise (so you have to assume that's still there). It doesn't address backdoors installed. It doesn't address information stolen.
So this is a hell of a lot of work to accomplish .. basically nothing.
>> comparable problem to "play every possible game of chess" for a computer to figure that out.
It would be a poorly programmed computer that didn't consider this possibility.
Two possible changes (forward/backwards) for two characters out of 15. 420 combinations. Not exactly billions.
Can't have a new 'similar' algo for past pws, obviously.
I'm not supporting that position, just what I heard many years ago when talking with a security person.
Of course, the proper thing to do would be to deactivate the account when someone leaves the organization. But if the organization doesn't have it together enough to deactivate and reactivate accounts properly, they might rely on the time limit as a fallback. The reason your password isn't good now is that someone doesn't have the info they need to do their job (deactivating accounts) properly, is lazy, or is paranoid. In any case, it's a signal that the organization that's requiring you to change your password can't manage account deactivation.
It's also a similar rationale to password resets. The e-mail might end up in some leak somewhere (see WikiLeaks), but the link won't be valid anymore.
It doesn't stop all classes of security issues, but it does make the data time-sensitive. Think about all the account leaks that happen. The data is rarely current (usually a year+ old).
So the policy is ineffective.
For example, imagine if someone compromises one of your backups. Some hard drives were stolen from the office or something. In there you had your password written in a text file ( because you're that kind of person). The attacker still doesn't have access to your computer. But they do have access to your password from the time of backup.
A disgruntled employee remembers the password of a former coworker. At one point the password will change, so the window of opportunity is smaller.
It's not perfect, obviously, but in a lot of office environments passwords are easy to gleam.
Another argument for password rotation: it usually forces people to keep different passwords per service. Without rotation, people tend to use the same password for everything
There's a trade-off, but it doesn't accomplish nothing
I preach to them they should not have an $EVERYWHERE_ELSE password, and should definitely not use it at work. But they do anyways.
Does this include credit/debit card PINs?
"Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets."
I take it this proscription applies to the actual passphrase, not as part of an account reset mechanism? If so, that's too bad, I really don't like these questions let alone the storage of the answer. Are these answers secrets though? If so, send like it's proscribed, and also they have to be salted and hashed in which case the answer itself isn't being stored.
Go to login, password expired. Expires every 6mo. Also, requires punctuation. I type in a typical strong/long password and it says "weak" until I append ! to the end and magically now it's "STRONG!"
Typo?
So when NIST does a final update, (the above is just a draft of their new standards) EVERYONE(-ish) will follow (eventually).
Who approves this stuff? Does anybody know?
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP...
Source: https://www.nist.gov/news-events/events/2016/05/random-bit-g...
Hey, I've got all the ASCII character classes. Must make it a good password.
The only problem is actually typing in those, most keymaps lack support.
The workload is ideally set to something that is acceptable to users, but considerably slows down brute-force attempts by attackers.
Please educate yourself some more before making statements on the value of things that surprise you, they might be there for a good reason.
Your comment about "please educate yourself" was not constructive.
If it really concerns you, proper practice is to store the iteration count alongside the hash and salt, so you can easily go through and add more iterations if you want as computers get faster.
Its neither surprising (rather expected) nor of questionable value.
The NIST recommendation for "highly sensitive access" is 10M iterations :D
Also, even 10s of thousands of iterations are very fast (run `openssl speed` to get an idea). See this more as a mechanism to introduce 8-10 ms delay for every password check. This will delay the attacker, but shouldn't bring down a server.
This does not have any impact on network-level DDOS scenarios.
In short, in password authentication, slower is better.
I prefer plain English aka "passwords"
"Password Strength"
Also, I feel very funny using generated password from a website. If I need a new password, I can just generate one in Python or something.
%load pwm
import random as r
import string as s
def pw(n=12):
return "".join([r.choice(
s.ascii_letters \
+ s.digits \
+ "|!@#$%&/()=?+\-_.,;:")
for x in range(n)])I prefer not to have to use the shift key in passwords, and the 34 instead of 36 ([0-9a-z]) solves my german/us layout problem in a very golfy way.
[ed: hm, no - not yet. I remembered discussions like this:
https://lwn.net/Articles/657269/
But looks like "secrets"[1] has the strong random.choice provider among others.
Probably the (minimal, dirty) change needed (for python 3.6 and later) is:
import secrets as r
I do agree that for this particular case, the pseudo-random generator seeded by system time might be enough (or at least better than "random" key presses) - but I don't like spreading bad patterns. And for any code generating many passwords, with the opportunity for an attacker to get a sample - this is likely very bad.
rand(34**10)
rand(34*10)
In fact xkcd underestimated the entropy. The stated entropy is only true if you limit yourself to words a 4 year old would use.
Systems that limit maximum number of characters or require character classes are the worst.