The main point is to use passwords that give you the most "bang for the buck" in the sense of adding the most bits of entropy for the least difficulty of remembering. Adding an extra number, or punctuation, or certain numbers of repetitions generally adds only a little bit of entropy for a significant cost in additional challenge to your memory.
Our minds are well suited to remembering combinations of common words, and by stringing a few such words together, you can generate a larger search space than using a single word with a few substitutions. Even if the attacker knows the scheme you're using, he still must search through the space of combinations of common words, which XKCD is pointing out is quite large.
The best part is that any automated attack would have to deal with ringtone popups.
Similarly, extended passages of text -- even if they don't come from a restricted corpus like that of song lyrics -- have less entropy than you'd think. A smaller number of independent random words is likely to be a better tradeoff.
Long passwords are typing-error prone. With mobile devices, it gets worse, as typing is really painful.
It is a good point, though, that for frequently typed passwords on a good keyboard, you can engage your muscle memory. That allows you to type short passwords very quickly, and even remember passwords with your fingers that you've lost from your conscious memory!
For example, if I use single dictionary words fed through a trivial ceasar cipher, then that is mathematically very low entropy. Realistically speaking, however, it's relatively safe if the cracker doesn't know that's what I'm doing, because it's impractical for crackers to compute all possible low entropy "alternative dictionaries."
let's say there are 500.000 english words you are choosing from and you use 4 words. that gives you 500000^4 possibilities. let's assume the words averages about 5 characters, so we will compare this to a 20(=4 words * 5 characters) character long password made of 26 types of character (english alphabet, not using numbers and other special characters), that gives you 26^20 possibilities. and 26^20 - 500000^4 ~= 2x10^28, or put it this way: (26^20) / (500 000^4) = 318 850.382..
i know a random sequence of 20 characters are very hard to remember, but 500.000 is an overestimation too. let's say we use special symbols too (50 characters) and the word dictionary has 100.000 words. (50^12) / (100 000^4) = 2.44 so we can say it is better to have a 12 character long password (made of alphanums + symbols) than 4 random word concatenated (i think 12 is somewhat a 'standard' for 'sensitive' passwords). and i would argue that on the long term multiple concatenated passwords are very hard to remember. i'm not saying this is a terrible approach, just not the silver bullet to the 'password problem' (which xkcd never claimed of course, and for 'non sensitive', 'reused'/'throwaway' passwords it may be a viable option).
edit: and i forgot about case sensitivity too.
It's easy to compare the entropy of two schemes as you're doing in your comment, but it's more difficult to objectively claim which is easier to remember. You argue that a random sequence of 12 characters is easier to remember than 4 words. If so, then I'd agree it would be a better scheme. However, I don't think that's the case. To really settle the argument, we should do some experiments - maybe someone already has?
Here's some examples I used a generator to create:
gangster insert madden quartic
overlong cage figurine hardship
trimmer wholly movie nadir
Bt].iu@0Soc*
Vf+pIW;C>\vp
'.}]Ba,g%@vI
Which do you think are easier to remember?
g6M;`Zt3^,d" vs selected aardvark badminton winnings
The way the human brain works, it would be at least as easy to remember 12 random words as 12 random characters.
It's hard for humans to remember meaningless conjunctions of symbols, so we think they are hard to guess; so we err on the side of making them too short. Contrariwise, we think a sequence of just four words couldn't possibly be hard to guess because it's so easy to remember, but it's only easy to remember because we can use the meanings of the words to form an idea or image, something our brains are built for (unlike strings of meaningless characters).
This is why the word technique is better: it corresponds better with how we remember, while reducing two other risks: the risk of losing your password - non-trivial - and choosing too short a password.
Another point is that letter placement within words is significantly non-random. By intelligently choosing which letters to try in each position, the hacker could at the very least minimize the number of tries by an order of magnitude for the first word.
Second, your example isn't very good because it assumes that every 8 byte character (save one) is acceptable, which is rarely the case, especially if you are trying to memorize them.
Finally, as another commenter pointed out, you've got your math wrong, and even your example has more entropy for the words than the characters.
(which works out to 8.55E20 and 1.78E19)
1) A lot of sites, still in this day and age, have max password lengths, so I still have a lot of short passwords. Usually this is bank sites and the like.
2) Password entry fields are often very short visually, and with a long password getting lost is much easier. I find I have to type them over A LOT.
The second is actually the more annoying problem.
With crappy password requirements, it's impossible to use decent passphrases. Getting locked out of your account for 3 failed attempts at typing a 30-character password is pretty obnoxious, too.
In situations that allow passphrases, you don't need a password generator like this. You can grab a sentence from your favorite book and use it. e.g. "How do you do, Miss Doolittle?" That's not the best choice, but it's still got way more entropy than a standard password, probably a lot more entropy more than you'll get by choosing a 4-gram composed of words from a corpus of 2k, and it's easier to remember.
Your favorite book is almost certainly chosen from the 129 million books that Google knows about: http://www.fastcompany.com/1678254/how-many-books-are-there-...
That gives you 27 bits of entropy.
The average book length is probably not over 400 pages. An average page probably doesn't have over 25 sentences on it. So the whole book contains only ten thousand sentences.
That gives you 14 more bits of entropy.
The total is 41 bits of entropy. This is one-eighth as secure as a 4-gram composed of random words from a corpus of 2k, if we measure strictly by entropy.
The situation is actually much worse, though: your favorite book is probably a popular book. So the number of bits of entropy provided by the choice of book might be a lot smaller than 27. I would guess that it's perhaps 10.
And many of those 129 million books are not very different. They contain quotes from other books, reprinted short stories, folk tales, set phrases, and so on.
In practice I think it might be difficult to mount a password-guessing attack using the Google Books corpus, because it's hard to get access to that corpus. The Project Gutenberg corpus would not be so hard.
If you have a long password (at least 16 characters), all other requirements are waived so that you can use passphrases.
To prevent unauthorised access to your account your password must contain 8 characters.
Wait, what? They're right, too. You can't have 7 characters and you can't have 9.
As an aside, 1000 guesses a second? Seems generous.
I haven't typed a password in 3+ months - don't know what any of mine are anymore, so I find typing is no longer an issue.
1) Nothing written down 2) Unique per service 3) Adjustable difficulty & char set per service, to match their stupid requirements.
Seems like the best of several worlds.
Just choose a nice strong master password.
There is potentially a lot less entropy in this password than "Tr0ub4d0r&3", assuming the hacker is smart enough to realise he can trivially test combinations of dictionary words in very short amount of time.
(EDIT: I'm way out of touch with this; it's not as trivial as perhaps I figured. See lower in the thread)
However; it is in the right direction - introducing some sort of extra entropy can invalidate that form of attack and make this as secure as XKCD suggests.
What do I currently do? I take a reasonable length common word, do a string/number replacement as so:
H4ck3r N3ws
And then repeat it 3 or 4 times:
H4ck3r N3ws H4ck3r N3ws H4ck3r N3ws H4ck3r N3ws
For extra entropy mix it up:
H4ck3r N3ws H4ck3r News H4cker News Hacker News
That's a simple example - so long as you have a reasonably random scheme then it is not easy to test against, but is fairly simple to remember.
Bingo :)
(EDIT: for the down voter(s) note: XKCD specifically says random common words - obscure words are another matter)
In the comic he is using a 2048 word dictionary, which gives 11 bits of entropy per word (log2(2048)), with a password made up of four words that gives a total of 44 bits of entropy.
But if we were to assume that the cracker knows nothing about our password, say other than it being all lowercase a-z, then we have an entropy per character of log2(26) or 4.7. For the phrase "correct horse battery staple", which has a length of 28, the bit entropy of that phrase, under those conditions is 4.7 * 28 = 131.6. Which is nearly to the point of the cracker being more likely to find a collision.
Explain the reasoning behind this, please.
Start with: You don't know the dictionary I used, but have to use one that seems 'good enough' (i.e. a superset of mine, if possible).
How many words are in there?
How many combinations can you create for 'two word phrases'? (You don't know the length of my phrase)
How many for three?
How many for four words?
1) Knows this scheme was used.
2) Knows the list of words you used.
3) Knows how many words you used.
You will still have that amount of entropy. Diceware entropy values are calculated with all three of these assumptions already made.
People are likely to use a standard English dictionary. In my experience (which is exactly within this field) people use a fairly tight subset of the English vocabulary.
So I would be quite happy to test for a dictionary of, say, 100,000 words and be hopeful of a good hit rate (note that XKCD says common words, which is easily missed)
Our software has a test (which runs about third in its list of tests) which does dictionary combinations up to three words (two words is quite a commonly used password based on our statistics) with a dictionary size of <s>175,000</s>17,500. (Edit: sorry, apparently it is an order of magnitude smaller, I checked with one of the engineers :)) This includes English words plus a few commonly used foreign/slang terms. The hit rate on this is fairly high.
(we crack document/windows passwords mainly)
You could of course choose deliberately obscure words to invalidate this - but they aren't so easy to remember (so people will tend not to).
If someone is going out of their way to secure a password, sure, you're going to hit a brick wall. But what every password scheme tends to forget is the "human factor" whereby people not concentrating on being secure will introduce attack vectors.
This is a terrible idea. It's one thing to ask a person to remember which characters they replaced in a word. It's another thing entirely to ask them to remember three different ways they swapped characters. This is a recipe for having to brute-force your own password. It's also still not as secure as you might imagine. There's very little entropy added by swapping characters (even though I do it as well), because there are very few substitutions that people make. "Hacker News Hacker News Hacker News" is nearly as secure as your convoluted 3rd passphrase, but a lot easier to remember.
The repeat-three-times thing is probably not great advice, either. If this became popular, it would be trivial to add this to brute-forcing code, and it doesn't add as much entropy as adding just one extra character.
I don't think the XKCD suggestion is actually good, either. Open a book and pick a medium-length sentence. There's your passphrase: an n-gram chosen arbitrarily from the corpus of (probably) English literature containing mixed-case and punctuation. You've got a ton of entropy there.
Maybe you have an excellent memory, but I'd forget this in a week. "Now let's see, is it the third 'hacker' that has the 4 AND the 3 in it? Or the 2nd?"
You can add equivalent entropy just by adding a few random special characters, a number, and a letter.
Personally, I prefer to type my passwords until I remember them. Therefore, my metric is "easy to type and hard to guess." If it's easy to type, I remember it via muscle memory, which is unbelievably better than trying to remember abstract symbols.
Look, we're working with big numbers here. You need to do the math.
In this thread alone, I've seen suggestions to use a common dictionary word translated into another language, or written in l33tsp34k with some permutations. From a probabilistic perspective, these are still dictionary words, even though they look like gibberish. The same is true of the common method of typing a word with ones fingers displaced on the keyboard.
Conversely, I see a lot of argument that these XKCD passphrases would be easy to guess because they are made up of dictionary words. This misunderstands the math behind the situation. Even if an attacker knows that your password was generated via this method, and even if they know the word list you used, the password is still hard to guess. The difficulty grows exponentially with each word in the phrase, and that's pretty fast.
The key with passwords is not to create something that looks random -- something that if you showed it to another human being, they'd have a hard time deciphering. It's to create something that is random; literally a result of a throw of the dice for every new password.
Human beings are really bad at creating randomness. There's a demonstration done in an early statistics class in which the professor divides the class into two groups. He tells one to toss a coin a hundred times and record the sequence of heads and tails, while the others are to write down a sequence they think is random using their imagination. The papers are completed and mixed and then -- magically! -- he is able to sort them into the two types, easily and with high accuracy.
The lesson is this: even when you think you're being random, you probably aren't. You're probably using the same tricks everyone else is, and making the same mistakes.
I would trust passwords that come out of a script like this to be far more secure than passwords anyone (myself included) made up, no matter how random they're trying to be.
No, it doesn't. All of the reasonable punctuation you could add to a sentence adds only a few bits of entropy at best. It also makes the sentence harder to remember— was there a comma or not? Adding unreasonable punctuation or symbols is even worse— you get slightly more entropy at the cost of a password that is way harder to remember.
The crucial point here is that four random words, separated by spaces, selected at random only from the 2000 most common English words — EVEN IF your attacker knows that your password is four random English words from the 2000 most common separated by spaces — already is a very long random string. If it's not random, each common English word you add adds 11 bits, and is only marginally harder for most English speakers to remember. Conversely, choosing "random" extra characters to add in makes it slightly longer, very slightly more random, and way, way harder to remember.
2000^4 = 16000000000000 possible passwords = 1.6E13 = ([A-Z] + [a-z] + [0-9] + [!@#$%^&()])^7.1ish. So, your four words from the 2000 word list are equal to a 7ish character password that looks like "Av#12GH". I'm not sure if you meant that seven characters was "very long" but I wouldn't say it is. Still a very strong password but maybe not as random as it appears to be when the pattern is known.
While this doesn't really improve any individual password the fact that we occasionally include non alphanumeric charecters increases the possible password set from 62 possible charecters ^ password length to a something more like 90^password length.
Similarly we dictionary attacks are more efficient than brute force attacks because we're talking maybe 200,000^(words in password) if we allow for some common word permutations versus 90^passwordlength.Definitely agree with you here.
I've been using the "few random words" method for passwords I need to remember for some time (and random 20 character mixes of alpha/numeric/symbol for the other, which I have stored in a keepass db), and I know I'm not all that random in my choice of words so if someone managed to see one or two of my passphrases it would be quite easy to create a script that could brute force the other couple quickly.
I shall have to use a script like this (or throw together my own for paranoia's sake) next time I change one of my passphrases.
It sounds very interesting. I've got to try it sometime :).
I know of two tricks for detecting the students. The first is to look for six or seven heads or tails in a row. Over a hundred tosses, a coin will probably do that, but humans "being random" won't. The other is to look at the page as a sequence of "HHH" and "TT" strings and estimate how many there are. A coin, of course, changes from heads to tails 50% of the time, but a human does it more like 70% of the time.
I'm sure there are other characteristics, too, but those two are sufficient to throw out most human attempts at a glance. It's actually kind of obvious, when you see the two side by side.
Me "being random" with the numpad: 10110101001010010101011010100101011010100101010110101
Computer-generated random: 1101110100000000011111110111011000010001010110011111
See? Here's a few more. Try it.
1000100111011001010000001001010110111000011011101011
1101010001010010101110100101000101010111101001001000
1101111010110111100010110001000100001001111001001110
1100000010000010101001000001101001101011111100111001
I think more people need to learn to remember arbitrary strings. There really is no way around that problem if you want a decently secure password, and it's rare someone has a "good memory" - in most cases they've just learnt how to remember things well.
(Note: This doesn't really apply to me or most of us here in most cases, but for example my WiFi password is of the form "Mycatsname9" and yet my neighbour still has to ask me for it whenever her phone forgets it)
Shoulder surfing: It's certainly a risk, but I'd say that prolonged shoulder surfing shouldn't be possible. If I type fast, it will be very hard to make out the phrase. If I type slow, you cannot stand around that long.
And - I'm not a security expert, but how much do you gain if you saw a couple of chars here? My intuition (yeah, shouldn't trust that) says that it's worse if I watch you and know the _first_ character of your password than you seeing the first 1-3 characters of the first word of my passphrase?
(We don't know the name of your cat, so judging the quality of the password or your neighbo(u)r's ability to remember it is hard)
Novel thought and possibly worth persuing, I hadn't thought of that. I want to re-iterate this isn't something I broadly apply across all my passwords or even many of them, just that for some users password sharing is a use-case.
Oh and if within a year's time you do not change your password, that could very well be another problem. I think you'd be better off just using easy to remember pass phrases and changing them every once in a while. Shouldn't be a problem because they are, after all, easy to remember.
Iff you share your password then yes, you should use a scheme more suitable for that. And yes we shouldn't be sharing passwords, and if we do we should be changing them, but in the real world where most people don't do that I don't think we should encourage passwords which their friends will remember easily - because that is a very common attack vector.
The entire point is that humans aren't very good at doing this.
>(Note: This doesn't really apply to me or most of us here in most cases, but for example my WiFi password is of the form "Mycatsname9" and yet my neighbour still has to ask me for it whenever her phone forgets it)
This is actually exactly the kind of scenario where using pass phrases makes the most sense. WPA2 is vulnerable to rainbow table attacks; relatively long passphrases are both easier to remember for mere mortals and less likely to be broken by a rainbow table attack.
How true is this? Because everyone that tells me "I have a bad memory" doesn't even know the most basic tricks.
> This is actually exactly the kind of scenario where using pass phrases makes the most sense
I agree, actually - I don't mind if my neighbour does remember it, I was just trying to illustrate that things that are easy to remember are remembered by accident, and things like that are easily forgotten without effort.
function rpass() {
strings /dev/urandom | grep -o '[[:alnum:]\/!@#$%^&*()<>,.,{}]' | head -n $1 | tr -d '\n'; echo
}
Passwords are evil. Most of them should be treated the way you'd treat your private SSH or SSL key. Whenever you can eliminate a password and get the user to authenticate using a third-party identity provider, you are doing them a favor.
Edit: with 80 possible characters, you get 80^16 possible passwords: 10^19 years at 1000 guesses/second.
Very useful.
The downside is that you need to really trust the password manager, as they have all of your usernames and password.
(Actually, from that page, vim now has built-in blowfish encryption, which I'll have to look at -- yet another argument in favor of sharing tips on the 'TarTubes: you may learn something even when you're sharing your own knowledge).
A better "configure GPG edit mode" .vimrc is here: http://vim.wikia.com/wiki/Edit_gpg_encrypted_files
I believe that's based on the one first posted by Wouter Hanegraaff <wouter@blub.net>.
EDIT: I'm totally wrong, it's more like 2*10^22 ... oops!
Assuming the attacker knows the the password creation method (and the math assumes the attacker does in the first case), then the attacker knows the word list and the passphrase algorithm.
11 bits per word gives you a grab bag of 2048 possible common words. To guess the password, assuming each word is unique, the attacker needs to try
2048 * 2047 * 2046 * 2045 = 17,540,692,561,920
possible combinations. Initially, you'd think an eleven character password with totally random uppercase, lowercase, numbers and symbols would give you 66 ^ 11 combinations for 66 bits of entropy, but since nobody can actually remember such a random combination, the resulting passwords using these rules are much less secure than that.
As there are so little words available, if I were to write a brute-forcing tool, I would try combinations of four words in my wordlist once I failed with my one-word-dictionary attack before I start trying out all characters.
But all is not lost: Either use more words or vary the amount of spaces you put between words. This way the dumb optimization "try four words delimited by space" wouldn't work on your password and they would have to go over to plain old brute forcing at which point, I agree, the longer, the better.
Properly executed, this will protect you against brute force attacks. No need to do nonsense like adding more spaces.
Of course XKCD botched it and said an inadequate minimum length...
Notable quote from the article: "This level of unpredictability assumes that a potential attacker knows both that Diceware has been used to generate the passphrase, the particular word list used, and exactly how many words make up the passphrase."
Let's say you're restricting yourself to a dictionary of only 2000 common words.
A single word, up against a 1000-tries-per-second attack, would therefore fall within 2 seconds. Clearly bad. Adding a second word gives 2000^2 combinations to test against, which would require about an hour. Still not good. A third word, pushing that up to 2000^3, takes us to about three months, which is probably acceptable in many cases. The fourth word, at 2000^4 combinations, gets us to 500 years, which is well beyond what most people are ever going to need for a web-based password.
Now, if you want to bring this into the realm of passwords in other contexts, which can perhaps be brute-forced with several-billion-tries-per-second attacks, this approach still works: you just need to add an extra word or two. At 2,000,000,000 per second the four word combination might only take a couple of hours, but a fifth word takes that up to half a year, and a sixth out to the thousand years mark, whilst still falling easily within the standard 7±1 memory limit and being much much much easier to remember than m(yV7&NlxAIZNx3>&@p&8/kX.
So if your personal salt is "@T#23a" you would use "@T#23a correct horse battery staple" on one website and "@T#23a giant bug transistor leech" on another website.
shuf -n4 /usr/share/dict/words | tr '\n' ' '
echo $(for i in 1 2 3 4; do shuf -n1 /usr/share/dict/words; done)
shippon preannouncer half-hourly withgang egotize baffs chapter monolater photoengraver beachhead linguidental autoheader hazeled defloration exhumate barretries
none of which seem particularly easy to remember (or spell even).
Beirut ejecting sidings mournsI know hotukdeals.com only allows [a-zA-Z0-9] which sucks.
The point is that one size does not fit all at the moment.
I guess developers need to change the way they handle passwords.
word_pass() {
cat /usr/share/dict/words | awk 'BEGIN{srand();}{print rand()"\t"$0}' | sort -k1 -n | cut -f2 | head -n 4 | tr "\\n" " " && echo
}
$ word_pass
corticifugally tetraploidy democrat vibrionic
I have another version that I use that stuffs srand but in the end I figured srand from a 250k dictionary is still better than picking words out of your head from a ~1k dictionary
from nltk.corpus import wordnet as wn
all_animals = set()
def add_to_set(animal):
all_animals.add(animal.name.split('.')[0].replace('_',' '))
for child in animal.hyponyms():
add_to_set(child)
add_to_set(wn.synset('animal.n.01'))
all_animals = list(all_animals)
actions = ['ate','chased','killed','fought','kissed',
'talked to','hated','loved','ambushed','fled'] # can add more
def make_password():
import random
random = random.SystemRandom() # is this secure?
choice = random.choice
return 'the %s %s the %s'%(choice(all_animals), choice(actions), choice(all_animals))
You could also add a humorous adjective ("rabid", "talking", "magic", "invisible", "evil" ...) or adverb ("roughly", "quickly", "quietly", "secretly" ...).
You could also add a place name.
I expect we can get some fairly high entropy from just simple schemes like this.
However, the length of the password can be a real pain if you have to type it often, even once a day.
You could get decent entropy with: the {adj} {adj} {animal} {verbed} the {adj} {adj} {animal} from in {place}. That's 5+5+8+5+5+8+5 = 41 bits.
I'm just wondering if it's worth it.
(Actually, slightly less since some words exist in both languages. Like `hell'.)
Well, sure -- but once you're at around two or three languages, you get to imagine that the attacker doesn't know what languages you're using. If I use English, Japanese, and Spanish, I can figure on the attacker needing to check the Germanic (English, Dutch, German), Romance (Spanish, French, Italian), and Asian (Japanese, Chinese, Korean) languages at a minimum.
Jargon helps too, and proper names. "dijkstra bicycle entonces boojum daihinmin"
You could have four word phrases that are maybe only ~12 characters, which if there are only alphabetical characters in the password, are still very much crackable via GPU brute force (http://mytechencounters.wordpress.com/2011/04/03/gpu-passwor...)
Edit : I managed to find back what website it was : http://www.advirtus.com/ when you register it shows the password as you type it
1: what purpose do the stupid asterisks serve, anyway? I understand them on an ATM machine, but not on my desktop PC or phone.
2: Very frequently (like, maybe 50% of the time) when trying to type a password on my phone, I miss the little "key" and mistype, but can't see that I did. I have to make multiple tries at entering the password. This feature would prevent that.
So it looks like all upside, with no cost (when used only in appropriate contexts).
2. There are technological ways around this, like finding a bigger keyboard for your phone, using password management software, imploring the website to make an app, practicing typing, etc. Also, BB/iOS/Android all show the most recent character you typed in a password field. Many soft keyboards give feedback about the most recent character you types as well.
I'm fine with my password fields being obfuscated.
The thing is, I think it makes perfect sense to implement this in certain situations, but at an OS or browser level, not in the website or inside an application. Passwords are something we have grown used to and we always expect them to behave the same way! If we were to change the way passwords are handled, it should be consistent across everything.
For example, browsers could implement password fields with a checkbox next to it that lets you show/hide password at your will. The fact that this website has only one setting (always show when in focus) is scaring me.
Inventing your own words is unlikely to produce very random words. You'll probably mostly invent the same few hundred nonsense words that any other speaker of your native language would invent.
In other words, you have no idea what you are talking about and should not have posted.
Sure, if we're talking about a different type of password, and 2-billion-tries-per-second attacks, it'll fall in about an hour, but simply pushing that out to six words from that dictionary will still stymie that level of attack for a couple of hundred years. The size of the dictionary is much less important than the length of phrase you generate from it.
That might have even less entropy. Why not just get a bigger dictionary? Most Unix systems even come with a dictionary.
Conclusion: Don't ever use this password generator, write you own, and tell no-one about it.
4b02d9f6353a8f36fbb092f040d5a31cdf6841f2
It's currently running at 3200000 tries per second on my Xeon machine. I am probably going to get bored before I find the right combination because I calculated it could take up to 52 days. :)
But anyways, it is still a lot less time than trying to bruteforce something like Tr0ub4dor&3 in my opinion.
It seems you like challenges, if I gave you a SHA1 hash of something similar to "Tr0ub4dor&3", would you be able to crack it (without rainbow table) under 52 days ? I don't think so.
I don’t mean to fault the creator of this page, but at the same time, I would not trust this generator for important passwords, simply because you cannot know if others are getting the same 'random' results as you are.
More info on SO: http://stackoverflow.com/questions/5651789/is-math-random-cr...
PDF on the topic: http://www.trusteer.com/sites/default/files/Temporary_User_T...
> In the Javascript engines of IE (Trident), Firefox (Gecko), Safari (WebKit) and Chrome (V8), the output of Math.random() can be used to reconstruct the random seed, and thus provide both this seed and the current “JS mileage” (i.e. the number of times Math.random() was invoked).
These phrases would be easier to remember if they made grammatical sense. Like Chomsky's famous "colorless green ideas sleep furiously" - the words relate to each other grammatically, even though it makes no sense.
Imagine memorizing "married greatly snake battle" vs "married snakes battle greatly." I think the latter is easier.
This is 2011, shouldn't every server be configured to allow a guess every two seconds for 20 guesses, then every 10 minutes, or something similar?
I'm not familiar with common practices in this area, but why wouldn't all such services be configured to limit the incorrect guesses?
Blocking the IP or an increasing time between tries is, afaik, the "right way".
The main issue with website security isn't people brute forcing the website login box, it's people cracking the hashes after stealing them. So if you had two easy to crack hashes stored in the database, you crack them both and off you go.
Phrase: Three Rings for the Elven-kings under the sky, Seven for the Dwarf-lords in their halls of stone
Password: 3RftE-kuts,7ftD-lithos
Easy to remember and highly secure. I have been using this method for years.
Bonus example: Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty
4sasyaofbfotc,ann,ciL
Less secure then the last example but still strong. Especially if you use uncommon strings like the words to a song by a local band or a phrase from the newspaper or an unpopular book. That way even an attack targeting this method will take a long long time.
entropy = log2(symbols^chars)
But using 63 symbols ([a-zA-Z0-9&]) I get 65 bits for Tr0ub4d0r&3, not 28.
Your calculation is for 11 characters, each chosen completely at random out of 63 symbols. People don't chose a password that way - we typically can't generate or remember random symbols.
XKCD's calculation is for a common word + common symbol substitutions and additions: log2(#words) + log2(#capitalization options) + log2(#substitution options) + ...
The fix, of course, is to get users to stop re-using passwords between sites.
How does making passwords more memorable fix this? If anything, forcing users to use random base64 strings strikes me as more secure as they will be forced into some sort of password locker implementation by their inability to remember them.
"The science of password selection" (a breakdown of common passwords by selection practices, as taken from public leaks)
http://www.troyhunt.com/2011/07/science-of-password-selectio...
In short, passwords are chosen from:
People names: this includes a list of about 26,000 common first and last names.
Place names: this is everything from towns to states to countries and includes about 32,000 entries.
English dictionary
The most common passwords by group:
Name:
1. maggie
2. michael
3. jennifer
1. dallas
2. canada
3. boston
1. password (oh dear)
2. monkey
3. dragon
1. 123456
2. 12345678
3. 123456789This was recently demonstrated when the mtgox password database was compromised.
edit: but this shouldn't be a problem if the password is properly hashed with bcrypt or some other scheme with a work factor.
No, I posted about my own generator in 2005: http://darius.livejournal.com/38591.html (getting the words from Beowulf). Then Zooko or Kragen pointed out some even older system in response (I forget the name).
~$ pwgen -s 8 C0olz5KM
You can also allow/disallow "offline" access to your lastpass account when using these two factor options (force second factor at all times or allow single factor if offline).
In practice the attacker must cast a wider net because he doesn't know exactly which word list you use, or if you are using a completely different password scheme. This increases the difficulty.
People who want to guess a password don't just brute force at random. They use a guessing order that goes through more common classes of password first. So if correct horse battery staple becomes a popular password scheme, these will end up attacked before other password schemes. (See http://www.schneier.com/essay-148.html)
Unless you're going to use a password safe full of nasty passwords, you should pick your passwords using an unpopular method.
People seem to be massively underestimating just how long it would take to brute-force four dictionary words in a row.
If this became a popular scheme, the whole entropy argument goes out the door. It only has more entropy if we compare the two schemes on a character-by-character basis (~10 vs. ~25). Of course the longer string will appear to have more entropy.
But if a password guesser expects the pattern of the "four common words" scheme, as they might if it became popular, it's not nearly as entropic. A better comparison would be to consider each word as a single "character" from a 180,000 sized alphabet (for an English dictionary).
Calculate the entropy of that and you'll find it's in the same ballpark.
The top 500 list has an awful lot of naughty words - so the phrases are pretty easy to remember ;)
The signal to noise ratio of xkcd is fantastic! They've again zipped a great discussion in just a few frames.
Username: ___________
Password: Twelve ___(pl. noun)___ jumped over a ___(adjective)___ ___(noun)___ named ___(proper noun)___.
Maybe Randall was inspired by that post.
Edit: y0ghur7_xxx (http://news.ycombinator.com/item?id=2872827) found it: http://www.baekdal.com/tips/password-security-usability
My computer failed miserable after about 2000000 permutations and considering there is 10^13, i wont be making a rainbow table for this new type of password.
A password doesn't necessarily need to be something that is easy to remember. It just needs to be a unique token that is easy for you personally to present when needed.
I currently use a keepass file stored in my dropbox folder. I am not certain what the silver bullet to online authentication will look like. However I suspect it may not require you to remember more than one secure password, perhaps not even that.
Trust online is hard though, looking at the problems establishing trust online reminds me how clever human beings are, we sometimes make mistakes but we are pretty good at evaluating trustworthiness in the real world.
Oh and there are unfortunately way too many systems limiting your password to only 6 or 8 characters still in use today.