Ubuntu addict and loving it
I was looking for a compromise between security and usability. If users have to remember a long random string of characters, half of them will probably write it on a post-it and leave it on their desk.Originally Posted by hyper_ch
I'd take the easy rout and random generate them a password which they can't change, only generate a new one
Tall Cafè Ubuntu
I think gpw (program to generate pronounceable passwords) generates the easiest to remember random passwords.
Code:vivaldi@narval:~$ gpw 14 10 tganshrupp olutakedde untrinexci mandenskil osssswersh mandinferm unsissidec arthantcha olocediabl preepadeal ancyclasco oussanknon ffshalizie ddessmatip
5 Cups of Ubuntu
Generated passwords are useful for one-time first logins. It might be worth while preventing confusing letters in an auto-generated password for the people who don't know how to cut and paste. E.g., prevent 0 and O (zero, captial o), prevent 1, l, I (one, lower-case L, capital i) and prevent the combination of letters rn (lower-case R plus lower-case N can look like lower-case M).
But it's bad enough trying to keep people from writing down a password they choose, generating them a "strong" one almost guarantees that they will write it down and stick it to their monitor - which is totally insecure.
A cracker would first use tools similar to those that twisted_steel recommended. These tools do basically the same thing your code does, but they have person years of effort in them already so they should be much richer.
Scoring:
Passwords that can be found in a cracker's dictionary of the most popular 1,000 passwords should all score zero. Any dictionary word should score near-zero, even if it's followed by a single digit. Same with keyboard sequences, but the 1K most popular list should include most of them. Otherwise, score passwords based on how many digits the maximum number of permutations would be.
There are 26 single-case letters, 26 letters of an alternate case, 10 numbers, and 33 miscellaneous symbols on the standard US keyboard. If you support utf8, people can enter Hebrew, Arabic, Kanji, or any number of other characters, but they generally don't, so I'm not going to consider more than 95 possible characters. Here are the character sets I considered in my analysis:
26 single-case letters
36 single-case letters and numbers
52 dual-case letters
62 dual-case letters and numbers
I think its rare to see a user willingly use a symbol in a password, but just for the record, there are
69 single-case letters, numbers, and symbols
95 dual-case letters, numbers, and symbols
The number of possible permutations of a password is the size of the character set raised to the power of the length of the password. Permutations = charsetSize^pwLength. So I ran the numbers for 6-character and 8-character passwords with different character sets:
Chars Permutations Score
26^6 308,915,776 9
36^6 2,176,782,336 10
52^6 19,770,609,664 11
62^6 56,800,235,584 11
26^7 8,031,810,176 10
36^7 78,364,164,096 11
52^7 1,028,071,702,528 13
62^7 3,521,614,606,208 13
26^8 208,827,064,576 12
36^8 2,821,109,907,456 13
52^8 53,459,728,531,456 14
62^8 218,340,105,584,896 15
If a cracker has direct access to the encrypted password and it's less than 8 characters long, consider it cracked in an hour or two, no matter how strong it is. Look up "Rainbow Tables" to see what I mean.
OK, All of that was pretty interesting to me to put together, but it's mostly irrelevant because the easiest way to get into someone's account is to ask them for their user ID and password. There are scripts for this on the web (to be read by a human to another human, not a computer) that will keep you awake at night.
I strongly recommend:
- Make your application wait a random amount of time between 1 and 3 seconds to report a failed login - this will slow down brute force attempts.
- Make your application lock the users account after 5 failed login attempts - this will limit the number of guesses in a brute force attack.
- If you can avoid giving any kind of feedback, it helps. E.G. If you display, "Wrong User ID" then a cracker can try user IDs until that message disappears and know that they have the right user ID. If you display "account locked" then you know that you have found a real user ID. Etc. Even a one-character difference in your response page is all a cracker needs to know.
- For a highly secure application, you need to give users a one-time pin that they type at the beginning of their real password. You can generate a little sheet of these things that they carry around and cross one off each time they log in, or you can get them one of those RSA SecurIds with the changing numeric display if you are willing to pay tens of thousands of dollars. This is the only way to fool all keystroke recorders.
- If someone will ever have to email a password (for initial account setup) force the user to change their password on their next login. Any password sent through email is as good as compromised if anyone is interested enough to try to look for it.
- Remind your users never to share their user ID or password with anyone. Make it clear that no-one should ever log on as anyone else or share an account. Remind them that you will never ask for their password, so that there is never any reason they should provide it to anyone.
Good luck! (I always tend to write too much. I joke that my blog just might be the most effective cure for insomnia known to man. Take it as a compliment that I found your question so interesting.)
Just Give Me the Beans!
This is the best advice. Those passwords are easily memorable, and meet the criterium of being pseudo-randomly generated.
You'd need to mix in some capitalisation and ideally a number and symbol to those, but something like that is definitely a good start.
5 Cups of Ubuntu
I know this isn't what you were looking for, but I found this site in relation to this topic. The site has a download link for using offline (and checking for bad script). http://www.passwordmeter.com/. Just my 2 cents.
Jeremy
Ubuntu addict and loving it
Interesting link. A lot like mine except no dictionaries.
http://cdenley.yi.org/pwstrength/
Ubuntu addict and loving it
At first I was impressed that they had consistent formulas (mine are sort of trial and error), but they don't seem accurate in all situations. For example, the password "a" receives a higher score than "ahfjckdomrodjk". However, it seems to be completely done in javascript, which means the password doesn't need to be sent to the server, which would be a security benefit. You couldn't properly evaluate a password's strength without a password dictionary, though, and that would make one big javascript file for the user to download. I suppose I could have the dictionary split, then use javascript to grab the appropriate section based on the given password. Maybe I'll try that some time.
Posting Permissions
Adv Reply
Bookmarks