Re: Use a high-entropy password generator
And exactly how memorable are high entropy passwords?
A new study has found that password structure is a key flaw in making login IDs hard to guess. Security firm Praetorian analyzed 34 million stolen passwords from the LinkedIn, eHarmony and Rockyou breaches and found that 50 per cent of all passwords followed 13 basic structures. This lack of entropy makes it possible to use …
And exactly how memorable are high entropy passwords?
Low entropy in your passwords is the weakest link in any crypto-system.
There's a whiff of Poe's Law here, but I'm assuming this isn't meant as a joke.
The "weakest link" in most security systems, regardless of the use of cryptography, is human beings. To claim that it's "low entropy in ... passwords" is simply stupid.
Even if we restrict ourselves to the cryptographic operations per se, in many cases of actual deployed systems, low password entropy was far from the most serious problem. There have been many systems that used weak mechanisms for generating password verifiers, for example - sufficiently weak that even optimal password entropy didn't significantly increase the attacker's work factor.
Try signing up to Boots.com. The password requirements are quite frankly ridiculous, and ended up with me typing in garbage - which is probably what they want.
I've also had trouble using a random password generator on various sites because it was:
(a) too long
(b) didn't match their rules (despite being 16 random characters of lower/upper/numbers).
(c) the website blocked the ability to copy 'n' paste into the text box, forcing me to use a password I could be bothered to type out twice.
It's almost like the developers don't understand the maths and think creating rules makes it harder to crack (tip, a 20 character phrase all in lower case is harder to crack and easier for humans to remember than a 6 character password with uppercase/lowercase/numbers/symbols).
Max lengths piss me off, given the things should be salted and hashed in the database anyway (long passwords are all reduced to the same length as short passwords in terms of DB storage). So why limit me to 8 characters??
I can understand having some kind of a limit so I don't try and set a 10KB string as a password, but low character limits are just stupid.
Even typing a 10KB string shouldn't be a problem either. A hash should just work on a string no matter its size or even its contents. I should be able to use an executable as a password. I suppose the issue is memory exhaustion for the hashing process, but RAM is cheap nowadays anyway, so even if the hasher requires 1 MB per session, you could still support 10s of thousands of users on a modern web server.
Since so many developers are "self taught" or come in via some kind of trade school, you can't expect that they've had any exposure to theoretical concepts like entropy. Their managers are usually even worse off.
When anyone asks about this sort of thing I always point them to xkcd # 936, not because it contains the most mathematically accurate presentation of the subject, but because it gets people to start thinking about the problem in the right way.
Here's an entropy aware pass phrase generator I really like:
And a strength checker that uses the same principles to evaluate what you've created:
"A hash should just work on a string no matter its size or even its contents."
Well, yes, but the dev defined the 8-letter password input buffer as char (well, char, if you're lucky)...
Here's an entropy aware pass phrase generator I really like:
Yikes! I flatter myself that I have a good vocabulary, but a high proportion of the passphrases contain unfamiliar, foreign or obscure words.
overnice bowline sceptic octopus pleopod sentient
licorice patroon miler bondman tramline dicker
par compo gyrus carolus rejoice jack
whoreson winding digit lozenge skiplane hopper
refer hyoscine nude ala fender piton
resign hawfinch enshrine assignor boast heliport
compos trigraph slacks genital corpsman akene
matchbox squeaky plump haloid sapwood metallic
byelaw smallish turbit marking afforest praetor
I concur with all of your gripes. Long password restrictions are particularly annoying. Sometimes the password field is a fixed length or the password is silently truncated somewhere before it is saved with the new account. Either way this means next time I try and log in my password is inevitably wrong and it is a case of trial and error to guess what length I need to truncate my password to. Usually I have to do a password reset and use a shorter password hoping it is short enough this time.
If the password length is limited then it should be clearly stated when the password is created.
I have "12AB.," on a speed-dial just for stupid motherfucking sites like that, and then I add it to the end of my actual safe PW.
Assholes that think adding extra special little-princess predictable patterns into all of their users passwords, need to get taken out and shot in the head.
(and then get shot in the head 2 more times, and then 1 time exactly 7 minutes later)
The craziest implementation I have EVER come across is a company who really must remain nameless (hence the AC post.)
Their rule states no consecutive letters. So, having used "B" for instance, you can't then use "A" or "C" ANYWHERE IN THE PASSWORD! Each letter you use effectively eliminates 2 others!!
After several invalid passwords, and a phone call to find out what the restrictions are, I eventually managed to construct something suitable.
They probably thought that the Enigma was a good idea (no letter can be translated into itself). And look what that led to.
Password handling is one of the most borked aspects of websites. The amount of sites that don't specify a max number of chars but will let you enter (say) a 20 or 30 char password, and then mysteriously you're unable to login afterwards because presumably they've trimmed the password to some invisible maximum and you haven't got a clue what it is.
I encountered one site with a similar issue. On the account creation page, the password field had a length of 20 characters, but the login page only allowed 10. Somewhat concerning that no one at the company who developed, tested, or used the site had a password longer than 10 characters.
I also ecountered something like this on a website...But I knew it was trimmed because upon registering I received my password in plain text in an email and noticed that it was shorter...
This is clearly a company trying to make a name for itself, without addressing the real problem.
Most security failings are not because of weak passwords. Once you move beyond dictionary attacks, your password is secure enough.
The real vulnerability is everything else surrounding the password. As we have found out, major sites have stored unencrypted user passwords in spreadsheets, truncated passwords to only the first few characters, had trivially weak encryption, used no salt, and used a fixed salt value.
In between you and the site with questionable security are people watching you type, keyloggers, fake login prompts, compromised DNS servers, rogue WiFi hotspots, spoofed sites, cross-site scripting, man-in-the-middle attacks, compromised identity managers, and too many more vulnerabilities to list.
You are far more likely to be exposed by having your password revealed by something you can't control, and then having it added to a dictionary for later attacks, than a clever system guessing passwords using rules.
Once you move beyond dictionary attacks, your password is secure enough.
A meaningless claim. Whether a password is "secure enough" (or just "secure") depends entirely on the threat model, and you haven't specified one.
Depending on your definition (which, again, you've failed to provide), "dictionary attacks" probably doesn't include rainbow tables, which certainly might be employed by attackers if the potential benefit justifies the cost. Or attackers might mount massive parallel brute-force attacks against a specific target; again, some password-protected resources justify the (now quite low) cost of using a cloud provider for that purpose - particularly if the cloud resources are stolen (by hacking some legitimate cloud user's account).
Certainly the other attack classes you mention - observation, keyloggers, etc - are applicable to many threat models, and in many cases will represent more-prominent branches of the attack tree. But these are not universal verities that apply in every case.
Someone explain to me why they don't set it so you must wait 10 seconds before trying another password?
Wouldn't do a damn thing against most attacks. Digging through my logs, a lot of attacks will try the same password but cycle the username (password hash is the same). Then the attack switches to a different password and goes through the username list again. All an attacker would have to do is increase the number of usernames tried so that the cycle becomes 10 seconds long. And that is assuming that the attack has a short list of names, even trying 1000 names at 10ms a piece would mean that the attacker doesn't even notice a thing.
Because automated password guessing attacks probably account for 0.1% of successful hacks, as opposed to the large majority of hacks that have nothing to do with whether you have a great or terrible password, and the remaining minority of hacks where your encrypted password (along with that of thousands/millions of others) are stolen and subject to leisurely dictionary attacks.
Moreover, blocking a username for any amount of time verifies that the username exists in the system, which is a possible issue in itself. Time delays can be useful when dealing with password-only entry such as your mobile phone but not with username-password combinations
For my work I have access to a certain computer system that contains private data for many millions of people. I also have write privileges and could do lots of nasty things if I were that sort. (Fortunately, I'm not.)
What makes me wonder what the people who set this thing up were smoking is that all passwords for this system must be exactly "X" characters long, and "X" is not all that large.
WHAT WERE THEY THINKING?
AC for obvious reasons.
WHAT WERE THEY THINKING?
Probably either a legacy restriction carried over to a new system rather than doing a more intelligent mapping (see my previous posts), or someone failing to break out of a bad habit shaped by older systems.
... there's only one measure of password quality, and that is approximate - it is how long a decent password cracker can run on it without success. Anything else, as shown here is actually scoring passwords on 'how well they fit our rules on passwords'. And when those are bad rules ...
One is the mathematical, knowing the cryptography rules that make the p/w "strong".
The other is psychological.
Knowing what can reasonably be expected of a reasonably sane user. And that doesn't mean what they could or should do, but what they would do.
So, if you insist on a capital letter mathematically reasonable it may be but a user will place it where they can remember they put it - which is largely where they would expect to find it.
So they might use "Password", possibly "PassworD" if they think they're being clever, but never "pasSword".
was a PW we used on a development server when I was in IT. Capital, check, Number, check. And fast to type too.
At some time the company was taken over and we had to work with even more systems; I think I counted that I had to enter 10 passwords before I could actually do any work (managers did not like being asked what we should book the login time to). Of course, the passwords were subject to different lengths, accepted/required character types and lifetimes. Guess what the first hour after a holiday was spent doing?
I encountered the following snafu: Registered for a website and used a 30 character generated password. Then I could not log into the site again because the password box on the log-in page was restricted to 20 characters.
"What was intended to increase randomness is instead creating structure that statistical analysis can exploit"
Er, no. It increases the number of characters in the option set which increases the permutations required to brute force the password.
But since the pattern is that the first char is a capital and the number is at the end it actually doesn't change the number of permutations at all...
"Password1" is the new "password"
A nicely conducted piece of statistical research, telling us what we've actually known for years. The entire "character set + template" approach to authentication credential creation is well recognised by both experts in systems and psychologists to be flawed, but we're stuck with it because the people defining login requirements currently have no understanding of either.
The silliest recommendation after "character set + template" is the supposedly random character string. This is grounded in a misunderstanding (and misapplication) of Shannon entropy, and fundamentally fails because (even if generated by a true random process) no-one (OK, maybe one in a million) can remember it. It's actually impossible for a human to create because the mind can't wrap round true randomness - what looks like a "random string" to a human is usually biased to emphasise a small subset of the possible code space.
Even the random word sequence advocates ("horse staple ...") have it wrong. The essence of a robust authentication credential subsists in three requirements:
 it must be long enough to make brute forcing hard - the required length will change with time and the criticality of what is being protected;
 it must be memorable to its creator - so in principle it must mean something to him or her;
 it must not be readily guessable by anyone else - so a problem arises for folks who are not very original ;-)
Within the string space fulfilling these three requirements, the strongest strings against guessing attacks will be the ones that conform least well to a common template. So the best rule set will contain the fewest, simplest rules. Here's my take with commentary in square brackets:
"A logon credential [note that we intentionally don't say 'password'] is not to allow you access to our systems - it's to prevent anyone else gaining access by pretending to be you. It must therefore be easy for you to remember but difficult for anyone else to guess. To achieve this, here are some basic guidelines:
 think up a memorable but not well known phrase or sentence of at least four words totalling at least 15 characters [reasonable length at time of writing, but may need to increase]. This phrase should mean something to you to make it easy to remember, so be imaginative, consider using humour and/or your native language.
certain obvious words are blocked and therefore cannot be used, including [e.g.] your user name, the company name or date words (month and day names) [but keep the excluded words list to a minimum to avoid user frustration].
 you may, but are not obliged to, separate the words in your phrase with non-alpha symbols."
Not the ultimate maybe, but probably a better start than the standard rules that render all words in any dictionary illegal (rather a challenge for a literate user) but permit 'Pa55w0rd!'. I've written about this elsewhere (http://intinfosec.com/library/policies/2011-Instant_Compliance_for_a_Grand.pdf)
So I'm called by a friend who has had her Yahoo! email account hacked and someone is sending emails to her friends as her. It's not just spam sending either this is I thought someone preparing for an "I'm on holiday and I've been mugged please Western Union me £800 to get home" scam. They'd been sending emails saying that this girl was off on holiday somewhere hot and might not take their phone etc. they were caught out by an out of office reply for an email my friend hadn't sent.
So I go round and we talk about password security Dictionary Attacks, Brute Force etc. and did some simple maths about how long it takes to crack a password. I suggest using a phrase spaced unevenly with odd capitalisation and random other characters (e.g. thi smO nit Orn eed s!a rea lly gO, Odc lea n) but she settles on something far longer but easier to remember. So having had her change it (without my knowledge of the actual phrase) and check that everything else is the same like recovery email password reminders etc. I asked her what her initial password was and she says "football" she also acknowledged that this was a bit dumb knowing what she now knew about how easy that was to crack.
Being able to create strong passwords is one thing. Being able to recall them is another. And, being able to recall the relations between the accounts and the corresponding passwords is yet another. ID federations (single-sign-on services and password managers) create a single point of failure.
At the root of the password headache is the cognitive phenomena called “interference of memory”, by which we cannot firmly remember more than 5 text passwords on average. What worries us is not the password, but the textual password. The textual memory is only a small part of what we remember. We could think of making use of the larger part of our memory that is less subject to interference of memory. More attention could be paid to the efforts of expanding the password system to include images, particularly KNOWN images, as well as conventional texts.
Biting the hand that feeds IT © 1998–2018