6 ms·
Kind of counters the idea from this xkcd comic that longer passwords are better, even when they just contain dictionary words: https://xkcd.com/936/ https://xk
by fotcorn 10y ago
Kind of counters the idea from this xkcd comic that longer passwords are better, even when they just contain dictionary words:
https://xkcd.com/936/ https://xkcd.com/936/
- rguillebert 10y agohow so?
- ProfDreamer 10y agoI think the problem with the longer passwords in this list is that they're well known phrases like song titles or just repetitions of the username.
- creshal 10y agoAdditionally, last.fm used unsalted MD5 hashes, which are so trivial to break it's not funny any more. (john manages 24 million hashes/second on my five years old laptop for that, even crypt(3) with md5 is three orders of magnitude harder to brute force.)
- baldfat 10y agoIt I still don't understand how this gained traction. I memorize 3 passwords and they are extremely hard. The rest are not created by me and I don't have repeated passwords.
- creshal 10y ago> I memorize 3 passwords and they are extremely hard. Not everyone is a masochist. It doesn't matter whether you encode 128 bit entropy in a base95 string, or a list of ~8 random words, it's still 128 bit entropy… but the word list will be easier to memorize and to type out.
- baldfat 10y agoHow many websites? How many passwords are you going to memorize and how are you going to not repeat a password?
- creshal 10y ago> How many websites? Zero. Why would I bother memorizing them? > How many passwords are you going to memorize The LUKS password for my home laptop, the LUKS password for my work laptop, logon passwords words for each, and password manager master passwords for each. I guess I could move some of these to hardware keys, but I'm too lazy. > how are you going to not repeat a password? The same anyone is not repeating passwords: Strong password generators.
- germanier 10y agoHow? The passwords on the list might be long but that's the only thing they share with the method from the comic. Usually they are just the same short phrase (often well-known) repeated a few times. This is not what that comic suggests.
- DanBC 10y agoNot a single one of those phrases are a random mix of dictionary words.
- bwindels 10y agoIt is indeed no longer good advice, but not because of longer passwords not being better: https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html https://www.schneier.com/blog/archives/2014/03/choosing_secu... > 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.
- creshal 10y agoSchneier completely misses the point. The entropy estimates quoted by XKCD (and indeed, used by implementations) assume that the crackers are "on to this trick". For any given entropy you use to generate your password, xkcd-style passwords will be easier to memorize and type out.
- germanier 10y agoThis article is posted every time the comic is mentioned but I can't understand the argument. The calculation of password complexity in the comic is made with that in mind. It's assumed that the cracker knows the method used to generate the password, including the dictionary. The strength of this method does not rely on the fact that the password has many characters but that words are randomly chosen from a large dictionary. The attacker would need to do the same at minimum.
- thatdude 10y agoBut the words themselves follow an identifiable pattern (their spelling). As such, a 4 letter word in your password is cracked much quicker than a portion of your password being 4 characters of random info.
- creshal 10y agoThat only matters if, for some reason, your password is length limited. If your password must not be more than four letters long, then yes, choosing your tokens from an ascii table has the highest possible entropy. (Example: WPA2 PSKs, shitty websites.) If your password can have arbitrary length (or arbitrary enough, about ~120 letters), you can generate a 128 bit password with dictionary words as tokens. Sure, the password will be much longer (factor ~6), but also much easier to memorize.
- DCKing 10y agoThe XKCD comic is showing its age. The comic mentions 1000 hashes per second. Assuming the entropy estimation is accurate (is it?), and it would take 550 years with 1000 guesses per second, that's still not very impressive. A single AMD Radeon Pro Duo graphics card can perform an estimated 8 billion guesses per second on the password hashes (unsalted SHA-1). A sub $10000 cracking rig with four of them can do 32 billion per second. That would mean the 550 year guessing time of XKCD's example password has been reduced to 9 minutes due to sheer computation power alone [1]. This is why it's important for everyone to use a slow and salted password hashing function (Argon2, scrypt, bcrypt, PBKDF2) to make sure that GPUs cannot guess hashes so terribly efficiently. Note that this even ignores any benefits attackers have had cracking a large amount of unsalted passwords, which will have been substantial. [1]: Edit: Looking up the current status quo, a single Nvidia GTX Titan XP can do almost 12 billion hashes per second in oclHashcat, that's 48 billion hashes per second for your cracking rig. Down to 6 minutes it is.
- Macha 10y agoThe comic itself mentions that it's intended threat model is someone trying to remotely login to your web server/ssh whatever, not trying to decrypt stolen hashes. I doubt any web service lets you try 32 billion logins/sec.
- creshal 10y agoIdeally you generate the password for your password manager XKCD-style, and let the password generator spit out 128 bit ASCII passwords for everything else. Then an attacker needs to get a sufficiently recent copy of your password database first, and password managers can afford using much higher work factors for their master password than websites for every single user.
- snowwrestler 10y agoThe gulf is so vast between how humans use a web service and how an automated brute force attempt uses a web service, that it should be trivial to block remote brute forces. Limit attempts to 1 per second per user ID, and block IPs with 50 consecutive failed attempts per user ID. These should be invisible to a human, but totally stop the brute force of any but the most obvious passwords. These don't seem like they would be difficult to do, but I am shocked at how few web apps do this. Last I checked, Wordpress ships with no limits at all on login attempts, for example.
- atoponce 10y agoIt doesn't actually. It shows how badly flawed the XKCD comic is. The problem with the XKCD comic is that he advocates creating a passphrase without a random function. Turns out, with no surprise, the resulting passphrases are easy to guess, because they are predictable word sequences, phrases, or sentences. To illustrate, suppose you have a word list of 8,192 entries, and a cryptographically secure random function. Shannon entropy says that each word in that list then contains exactly 13-bits of entropy (2^13=8,192). According to https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27..., 8 Nvidia GTX 1080 GPUs with Hashcat 3.0 can process 200 billion MD5 hashes per second, which means 5 of those password cracking rigs, working in concert, can do 1 trillion MD5 hashes per second. So, if you have a cryptographically secure random function choosing your words from that list of 8,192 words, what are we looking at? - 1 word (13-bits): 1 in 8,192 possibilities - 2 words (26-bits): 1 in 67,108,864 - 3 words (39-bits): 1 in 549,755,813,888 - 4 words (52-bits): 1 in 45,03,599,627,370,496 - 5 words (65-bits): 1 in 36,893,488,147,419,103,232 - 6 words (78-bits): 1 in 302,231,454,903,657,293,676,544 There is no need to go any higher than that, as we'll see in a second. If the password cracker is only interested in searching 1/2 of the total combinations, then that means at each hash, after completion, there is a 50% probability that the password was found (on average). So, armed with this, it would take the password cracker: - 13-bits: < 1 second to search 1/2 the space - 26-bits: < 1 second - 39-bits: ~ .3 seconds - 52-bits: ~ 38 minutes - 65-bits: ~ 213 days - 78-bits: ~ 4,792 years It's reasonable to conclude that if your threat model is password cracking clusters working on leaked hashed password databases, and assuming the password is hashed with MD5, then at least 65-bits of entropy, or 5-6 words chosen from a list of 8,192 with a cryptographically secure random function, is a good target for a secure passphrase length. For what it's worth, Diceware has been promoting this approach for years now, where the word list is 7,776 entries (~12.93-bits of entropy per word), and the cryptographically secure random function is 5 fair 6-sided dice. The XKCD "correct horse battery staple" approach is just a simplified implementation, forgetting the random factor.
- germanier 10y agoIt does say "four random words". To be fair, that could be spelled out more clearly.