A question about password length...
Right. So here's a dumb question about password length. There are a great many sites where you have to register to use the service. Most of these sites require you to provide a user-name and a unique password. In order for your account to be secure, it's in your interest to have a password that's hard to guess. So the first thing that most sites suggest is that your password should be a certain number of characters long. The reason for this is that people will try to use passwords that are as simple as possible to remember and short-passwords are going to be easier to remember than long ones. So if you were doing a brute-force attack trying every combination of letters and people (on average) were using more passwords that were four characters long than seven or eight characters long, then you'd be able to break some passwords pretty quickly just by starting with the smallest words. So people stick on a minimum length of passwords. Which is interesting. So my first question here is: if you set a minimum password length of (say) six characters, how many people use exactly six, seven or eight character passwords? Doesn't that make it easier for people to state 'a large number of passwords will be of this length, so let's target our efforts there'? Even if the maths involved is much nastier? I bet - for example - that loads of people have passwords that are combinations of two three or four letter words... What's the maths like around this stuff?
Comments
Please stay on-topic, informative and polite. I reserve the right to remove comments for whatever vague capricious reasons seem reasonable at the time.
Not sure about the maths, but as an application engineer I deal a lot with this.
We've seen that most people get used to minimum length passwords and pick words that they'll remember that are at least this length and use that same password on most sites.
for example, in one application which had a minimum length requirement of 6, most users had 10 or 12 letter passwords, way over the minimum. Looking at the hashes of these passwords over multiple applications where the same user has registered, the hash is the same, so that user is using the same password over multiple sites.
That makes sense to your average user, who in this day and age has 1 million and one passwords, numbers, etc to remember, but its a security bad, for obvious reasons.
here's not a lot you can do about this except by enforcing stronger security and thereby annoying the user (make sure your password contains letters and numbers, is mixed case, is changed very month etc - all not guaranteed to tick off a user)
So users (as far as I've seen) usually go for larger passwords than smaller ones. No real problem.
The real problem (and what personally ticks me off when I'm a user of an app) is not the minimums, its the maximum lengths. That seems silly to me when you;re trying to promote good security.
It becomes a real problem when the app you're using enforces a maximum on your over-length typed password choice and then doesn't inform you that its been truncated. You'd be surprised how many sites out there do this. Its not user friendly at all, and the only real benefit I can see to it is saving hard disk space in the database.
→ Posted by: Wild at August 8, 2003 12:45 PM
A premice of these questions is : is a brute force attack over HTTP even possible ? Isn't the network latency + server load just going to make it impossible if you have over 8 char passwords ?
Of course it's easy to code a protection against brute force attack (store the http user agents IP, and a timestamp, and define a maximum threshold of attempts, etc), but it would be too resource consuming for most medium to large web apps, that's why nobody does it.
→ Posted by: Androse Rosewood at August 8, 2003 1:12 PM
I'm really not sure about the maths, but it sounds like you're planning a break-in... :)
→ Posted by: Chris at August 8, 2003 2:45 PM
Tom: In my experience building web applications , people usually have one password that is used for pretty much all of their password needs. If it doesn't reach the minimum length, they simply pad it with other, easy to remember, characters. For example, if I use the password "bryan" everywhere (I don't), and the site requires 8 characters, I could simply make the password "bryan123". Doing this keeps the password easy to remember, but since it's not a word, a vanilla dictionary attack will be useless against it. Let's say you have 120 characters to choose from when selecting your password. You can pick any of 120 characters for the first character, any of the 120 for the second, and so on... This gives you 120^n possible passwords where n is the password length. As you can see, increasing the password by one character increases the number of possible passwords exponentially.
Now, your idea of a dictionary attack is interesting, except that as I pointed out above, most people (in my experience, at least) don't go looking for an 8 character word. For people who do use simple dictionary words, it would, in theory, be very easy to guess their password on a site with password length constraints. If S is the set of all words in the dictionary, the number containing, say, 8-10 characters (which I assume most people would use given a mimimum length of 8) would be a miniscule subset of S. Although I have no proof, I suspect the number of words in English with more characters actually decreases the higher you go.
This would be something interesting to look into for my 4th year thesis project since I'm majoring in Electrical Engineering and I'm planning on specializing in cryptography and security.
Ambrose: Not many people actually try dictionary/brute force attacks over HTTP - you're right, the protocol is way too clunky for that. I suppose the concern is more this scenario. Let's say a small web server I have an account on gets broken into. They have a mySQL database of their users, with hashed (md5) passwords. They use a brute force attack on a local computer until they find out the password for my account. If this is the same password I use for other sites, they can log in to eBay, Amazon, and other popular sites I may have accounts on and cause trouble. Also, if you wanted to break in bad enough over HTTP, you could limit your requests to one per minute, go to sleep, wake up, and have had 480 attempts. If the user's account is a dictionary word, of 8 characters or so, that's probably about half of your possiblities right there.
→ Posted by: Bryan at August 8, 2003 4:14 PM
I think the Crypto-Gram newsletter probably has some good articles about this sort of issue. (http://www.counterpane.com/crypto-gram.html ... I should note that Counterpane is a legitimate cryptography & security website, not some l33t hax0r site masquerading as something legal)
→ Posted by: brian w at August 8, 2003 4:37 PM
I've noticed a large number of secure sites use a number of blanks when a password is displayed even though your password may only be six or so characters long. Freeserve is a typical example.
→ Posted by: John at August 8, 2003 4:39 PM
Assuming that passwords are case sensitive and constrained to letters/numbers, you're talking about 26*2+10=62 possible values for each character. The number of passwords for a password length n is given by 62^n, or 62, 3,844, 238,328, and 14,776,336 for 1-4. As noted above, if we assume a network latency of 1ms (which is pretty darn fast), you're talking about 4 hours to brute force any 4 character password. Bump it up to 6 characters and it's roughly 19 years. And that's if we're only considering those at length 6... so if people always used the minimum, you're safe to say that brute force really isn't an option.
→ Posted by: cameron at August 8, 2003 4:41 PM
I hit this problem when registering for the otherwise-excellent BBCi Connector chat service. The password I use in most places on the web is six chars long. I use it when registering for places I don't care that much about (i.e. nearly all web registrations.) The BBCi Connector registration, however, demands a minimum of eight characters, which I find intensely frustrating. If it was a bank account login, I'd understand - but a chat room?
→ Posted by: Yoz at August 8, 2003 5:22 PM
not really, say i would normally search for passwords that are only alphanumerical characters and i will search from 1 characters to 10 characters. there would be ( ( 26 + 10 + 1 )^9 + ( 26 + 10 ) ) combinations. ( 26 = the alphabet, 10 = the numbers, 1 = no character here ) but let's say i would search from 6 characters to 10 characters, that's ( 37^4 + 36^6 ) - so we decreased our search space by 00.00167% - big deal!
→ Posted by: je_apostrophe at August 8, 2003 10:11 PM
I don't know the answer to the question about user behaviour in choosing lengths of passwords I'm afraid, but no, knowing the exact length of the password you're after does not make guessing it _significantly_ easier (obviously it does make it easier, just not significantly so). The absence of a character (ie a password being 7 characters rather than 8 characters long) is only of the same weight in your calculation of time-to-crack as adding an additional possible character to the set you allow (ie. A-Za-z0-9) (in fact, it's a lot less so, as these 'blanks' can only occur contiguously at the end of the string.)
→ Posted by: James at August 9, 2003 1:37 PM
Sorry it took me a while to dig it out, but I wanted to find a URL to go with it.
The Green book (DoD password management guidelines) is a good (if brief) discussion of some of the science behind this. It's a bit old, but the maths is still valid. Read the appendices, esp. C. http://www.securityunit.com/colorbook/CSC-STD-002-85.pdf
→ Posted by: James at August 11, 2003 1:19 PM
The thing is, brute force password attacks like that are uncommon. Much more common or at least troublesome are the social hacks such as the setting up of a spoof site. Or taking advantage of services that use something knowable, like email address, as the username. With a CD-ROM full of email addresses, you can run them against logins using easy to guess passwords like "password".
→ Posted by: pb at August 13, 2003 11:40 PM
Well it's a little late to be posting here (a year and a half after the question!) but take a look at my URL- it shows how long it can take to crack a password of a given length. If you have to check 6 characters, it might take 6 hours. If you also have to check 3, 4, and 5 character passwords, that adds another ten minutes. Not really significant. Allowing short passwords is a security hole.
→ Posted by: yary h at February 19, 2005 1:53 AM
No no no. To simplify a bit, suppose we have 26 characters to work with (A-Z). If you have a minimum password length of 1 and a maximum of 8 then you do NOT have 26**8 possible passwords ! You have Sigma, n = 1 to n = 8, 26**n passwords. That is, you have the sum of 26**1, 26**2, ... , 26**8. Writing that out in Arabic numerals is left as an exercise to the reader :-)
Note: ** = exponentiation operator
→ Posted by: MM at September 5, 2006 3:42 PM
One consequence (see posting MM at September 5, 2006 3:42 PM) is that increasing the number of characters in your password (the exponent) is better than increasing the number of characters in your password character set (the base), though both help.
→ Posted by: MM at September 6, 2006 2:47 PM