Your 8 char random password now means nothing

[Andreas Lilja]

Anyone know how my bank doesn't get hacked daily? I'm totally mind blown'ed.

 

 

[SpaceGhostC2C]

3 minutes ago, colonel_mortis said:

If the brute force algorithm just randomly chooses passwords from the space of permitted passwords, that's true, but that's not a useful assumption.

If the password length is limited to 32 characters, the length of real passwords is not uniformly distributed across the space of permitted passwords. To a first degree approximation, shorter passwords are more common, and when combined with the fact that the search space goes up exponentially a random search doesn't make sense. Trying passwords from shortest to longest is still a brute force attack, but it is more likely to find a password earlier in the search. Under this search scheme, which I would argue is much more likely to be used by someone who really did want to brute force your password without a dictionary, a 9 character password is much more secure than an 8 character password (specifically, 26x if the password is known to be all lowercase letters, with the difference increasing as the alphabet does).

The thing is, once it's not pure brute force, then it's not really about the length, although it may be about the length ex post. What I mean is that, as you said, shorter passwords will be prioritized because, and only if, they are more common. It makes sense for refined algorithms to go from the most likely to the least likely according to some previous knowledge on the way people chooses password, which at this point happens to mean an ordering in terms of password length. But that's not rleated to how many combinations of N characters there are, only to observed behavior by humans. You may think this is all academic ("whatever the reason, shorter passwords are going to be tried first, hence shorter passwords are less safe"), but the point I was trying to make is that ultimately being "weird" is what will make you more resilient to these refined brute-force attacks, and what is rare now may not remain rare in the future (and therefore, the number of combinations of a given length isn't what matters, but the distribution of passwords among the population). Perhaps more important, there is no general advice that can make everyone safer in this respect, since we can't all be rare at the same time: each of us is safer by deviating from what most people do, but we cannot all increase our safety simultaneously by deviating in the same way (we would just create  a "new normal", and algorithms would adjust accordingly).

The only way to put the algorithm makers in their worst case scenario (i.e., all passwords are equally likely and no refinement is useful) is for all of us completely randomizing our passwords, allowing for the shortest, longest, or most stupid ones as well (OK, maybe with a few blatant exceptions ).

[SpaceGhostC2C]

18 minutes ago, colonel_mortis said:

Assuming an alphanumeric password, there are 62⁸=218340105584896 different 8 character passwords, and 62+62²+62³+62⁴+62⁵+62⁶+62⁷+62^8 = 221919451578090 different passwords of up to 8 characters, which is 1.6% more.

As long as you respect the order of non-blanks, you can have blanks in any of the N positions for shorter-than-N passwords, so I'd say that if the maximum password length is 8, and the number of non-blank characters is 62, then you have 63⁸ -1=248155780267520 since blank is just another option for each of the positions (and I'm ruling out no password as a password ). While bigger, it's the same order of magnitude, so I stand corrected, it's not "way, way higher" as I claimed.

 

[colonel_mortis]

8 minutes ago, SpaceGhostC2C said:

The thing is, once it's not pure brute force, then it's not really about the length, although it may be about the length ex post. What I mean is that, as you said, shorter passwords will be prioritized because, and only if, they are more common. It makes sense for refined algorithms to go from the most likely to the least likely according to some previous knowledge on the way people chooses password, which at this point happens to mean an ordering in terms of password length. But that's not rleated to how many combinations of N characters there are, only to observed behavior by humans. You may think this is all academic ("whatever the reason, shorter passwords are going to be tried first, hence shorter passwords are less safe"), but the point I was trying to make is that ultimately being "weird" is what will make you more resilient to these refined brute-force attacks, and what is rare now may not remain rare in the future (and therefore, the number of combinations of a given length isn't what matters, but the distribution of passwords among the population). Perhaps more important, there is no general advice that can make everyone safer in this respect, since we can't all be rare at the same time: each of us is safer by deviating from what most people do, but we cannot all increase our safety simultaneously by deviating in the same way (we would just create  a "new normal", and algorithms would adjust accordingly).

The only way to put the algorithm makers in their worst case scenario (i.e., all passwords are equally likely and no refinement is useful) is for all of us completely randomizing our passwords, allowing for the shortest, longest, or most stupid ones as well (OK, maybe with a few blatant exceptions ).

Indeed, that is very true. Dictionary attacks are far more effective than a pure brute force, so having a password that nobody else has ever used, and which you haven't used anywhere else, is by far the best defence.

However, as the original article demonstrates, if it's stored as an NTLM hash, even a pure random 8 character password can be brute forced in a practical attack, so the only defence against that is to make your random password longer.

Just now, SpaceGhostC2C said:

As long as you respect the order of non-blanks, you can have blanks in any of the N positions for shorter-than-N passwords, so I'd say that if the maximum password length is 8, and the number of non-blank characters is 62, then you have 63⁸ -1=248155780267520 since blank is just another option for each of the positions (and I'm ruling out no password as a password ). While bigger, it's the same order of magnitude, so I stand corrected, it's not "way, way higher" as I claimed.

 

A blank character is distinct from any other character ("password" is not the same as " password", "password ", "[NULL]password", or anything else like that*), so you can't have "no character" in the middle of a password. It's just the number of blanks that matter, not their position.

 

*(assuming of course that a sensible hash function which distinguishes those cases is used, but I'm not aware of any password hashing schemes for which this is not the case)

[SpaceGhostC2C]

2 minutes ago, colonel_mortis said:

A blank character is distinct from any other character ("password" is not the same as " password", "password ", "[NULL]password", or anything else like that*), so you can't have "no character" in the middle of a password. It's just the number of blanks that matter, not their position.

I wonder if it would be possible to randomize blanks and send your password as "pass[NULL]word[NULL]", "[NILL]pa[NULL]ssword", etc every time, and once decrypted you reconstruct the password by removing blanks (=/= spaces). My intuition is that this would actually be very bad if you know it's the same password being sent each time, but good if you can't distinguish it from a password change?

[dfsdfgfkjsefoiqzemnd]

Not worried.  My passwords are made using 4 numbers, not 8 characters.  So it looks like I'm safe from this.

 

 

Mandatory viewing :

 

 

[colonel_mortis]

2 minutes ago, SpaceGhostC2C said:

I wonder if it would be possible to randomize blanks and send your password as "pass[NULL]word[NULL]", "[NILL]pa[NULL]ssword", etc every time, and once decrypted you reconstruct the password by removing blanks (=/= spaces). My intuition is that this would actually be very bad if you know it's the same password being sent each time, but good if you can't distinguish it from a password change?

That wouldn't give any benefits.

 

Over the wire (between your browser and the server, assuming you are logging into a website), the password is encyrypted using an encryption algorithm like AES-GCM. As part of that encryption, random data is added, so that next time you log in the encrypted version of the password is completely different (in fact, AES provides CPA security, which means that even if the attacker knows your password, they can't tell whether the encrypted message contains that password or not). This means that adding random nulls doesn't increase the security over the wire.

 

In the database, the value stored is a one-way cryptographic hash of the password. This means that you can't decrypt the stored value to learn the password - the only way to check whether the entered password is correct is to hash it and see if the result matches. If nulls are inserted into the password at random, checking the password would mean hashing and comparing it with all combinations of null placements. This makes it much more computationally intensive to use, without adding much complexity for an attacker. If you're just interested in increasing the complexity, many hash algorithms have a configurable "difficulty" setting, which can be turned up for a more effective increase in difficulty.

 

To make two hashes of "password" give different values, to make brute forcing more difficult, a salt is added to the hash, which is a random (but known and stored with the hash) value. This means that the attacker has to brute force separately for each salt value, which makes it much harder for them without adding much complexity for the user.

 

Lots of clever people have spent a long time designing algorithms that are fast for legitimate users but hard for attackers. Trying to find neat tricks for making things more secure is a great way to learn about the design decisions that have been made, but they almost universally won't offer a security benefit.

[SpaceGhostC2C]

2 hours ago, colonel_mortis said:

Lots of clever people have spent a long time designing algorithms that are fast for legitimate users but hard for attackers. Trying to find neat tricks for making things more secure is a great way to learn about the design decisions that have been made, but they almost universally won't offer a security benefit.

It's not like I was going to revolutionize a topic I know little of in a forum post 

But thanks for the explanation, it's what I was looking for and then some 

[Jayl0cked]

On 2/14/2019 at 12:10 PM, corrado33 said:

Very cool. It's worth noting that the time to brute force a password goes up exponentially with length (simply because the number of possible combinations also increases exponentially). Complexity only helps a bit. That's why it's smart to have a long, memorable password with just a few non common substitutions (don't use $ for S) and a few punctuation points in there. 

 

For example: For an 8 character password only including upper and lower case letters (52 characters), that's 52 nPr 8 = 3E13 combinations. Add 10 symbols in there and that's 62 nPr 8 1.3E14 possible combinations.

 

Now, make the password 9 characters long and you get 52 nPr 9 1.33E15 possible combinations and 62 nPr 9 = 7.36E15

 

So a 9 character password that has no special characters is better than an 8 character password with special characters.

 

EDIT: It's also worth noting that using words and sentences, as mentioned in the XKCD may not be entirely safe either. Words can be treated as "units" so instead of saying that a 9 character word is 9 pieces of complexity, it can be treated as 1. A 4 word password can be cracked the same way a 4 character password could with a dictionary attack. (Although words are more secure because there are more of them...)

 

Best advice: Use a memorable combination of words that's long but also has random symbols sprinkled throughout. E.G. Ca#_1UMP;Ov@r[Mo0NN

Cat Jump Over MooNN, easy to remember, then you just need to remember "pound for t, 1 for J (or just remember it as "lump" and laugh every time), the ";" then "Ovar" with @ and a 0 for the 2nd 'o' and double Ns.

 

EDIT: I played around with this once. Remember the game "Balloons tower defense?" Well I wanted to calculate the order to buy buildings to make the most money in the end-game. So I brute forced every action the player could take in relation to a certain building (the farms). Basically the player could either buy another farm, upgrade existing farms, or sell farms. I let this play out for 40 moves. 

 

When I let the program run.... it eventually came up with a 20 GB text file. Yes, you read that correctly. A 20..... GB.... text file. I had to find a program to even open the damn thing let alone read it. (Vim works great for large files btw). Eventually, by including more strict conditions, (like not allowing the player to buy a farm then immediately sell it.) I got the file down to something more manageable (like 7 GB or so), then I ran my analysis program on it to determine which combination of moves was the best. That took all night, but eventually I solved it, and it made me so happy. But the scale of the whole project just amazed me. These dictionaries for passwords can be freaking MASSIVE. Turns out the answer was exactly the strategy that most people in the game already used. But I got  a lot of similar strategies so I was still happy.

I've always thought intuitively, and said to friends, family small phrases that have meaning to you are better than a simple four - eight letter alphanumerical password. 

SO for exmample: 0v3rTHEmoon,C4tJumped
or <4tJump3dOver-m00n or some kind of combination of this phrase. 

One i've always liked: Sh3rlocknevers@ysit'selementarymydearW4ts0n. 

easy enough to remember but  much more difficult to brute force. 

[BobVonBob]

36 minutes ago, Jayl0cked said:

I've always thought intuitively, and said to friends, family small phrases that have meaning to you are better than a simple four - eight letter alphanumerical password. 

SO for exmample: 0v3rTHEmoon,C4tJumped
or <4tJump3dOver-m00n or some kind of combination of this phrase. 

One i've always liked: Sh3rlocknevers@ysit'selementarymydearW4ts0n. 

easy enough to remember but  much more difficult to brute force. 

Don't bother with letter substitutions. Every password guessing program worth its salt (ha! security joke) has rules to check every variation of that stuff, things like replacing an a with a 4 or @ or replacing o with 0 mean nothing in terms of security unless you're only worried about a human guessing them.

[jake9000]

Just use a flipping password manager and 2fa. Do not save any data of value to a site that doesn't offer 2fa.

Passwords are only as strong as the database they are being stored in and you really shouldn't assume whatever website you signed up for knows what they're doing.  For example, I couldn't help but notice msi.com didn't display a 'dipshit disclaimer' anywhere in their registration form even though they email you a plain-text password and encourage you to keep it with your records. Yeah MSI, I'm calling you out. You should not have the capability to even know the password! It should be hashed and salted before it reaches your server!!

According to the online-domain-tools.com password checker, the pw displayed below should take about 8 sextillion years for a botnet to crack. Doesn't look like it'll matter, though!

Passwords have zero value. It does not matter how fancy your password is. You should assume they're all in a pastebin somewhere anyways.

 

[BuckGup]

I need a full benchmark of speeds

[corrado33]

10 hours ago, SpaceGhostC2C said:

That's assuming the password is restricted to be 8 characters without special symbols in the first case, and to be exactly 8 characters with or without special symbosl in teh second case. The number of combinations when your password can have different lengths is way, way higher.

Eh, not really WAY higher. 62 NPR 8 = 1.36 E14. 62 NPR 8 + 62 NPR 7 + 62 NPR 6... 62 NPR 1 roughly = 1.38 E 14. The number of permutations when you consider lower character passwords is not significant in this case. Sure, it's 2 E 12 more which is a very.... very large number, but it's nothing in comparison to 1.38 E 14. 

 

While you are correct that I didn't account for this initially, I knew that it wouldn't matter in the long run. 

 

10 hours ago, SpaceGhostC2C said:

Eh... No. There are a little more words than characters, since words already are formed by many combinations of characters, so 4 words would never be as bad as 4 characters.

I suppose. I was just thinking that you could take words and treat them like units, or chars. Then you have a different file with all the combinations of say... the 1000 most common words and names in the english language. In essence, this makes sense. If somebody is using a "random" word password like "giraffe pencil card truck". You say that'd be a relatively secure password. It's very long, and hard to brute force via characters. But, if you take those 1000 most common words and names and apply the same math above to them.... but this time only allowing for 4 words (because 4 words is likely going to be getting close to the password character limit anyway) then you get 1000 nPr 4 = 9.9E11. A number that's 3 orders of magnitude lower than even an 8 character password brute force. So, by all means, I'd say if you were brute forcing a password that you know may contain words, it may be beneficial to use this dictionary before you use your character brute forcing dictionary. You'd have to go up to the most common 4000 words/names to be on the same order of magnitude as a normal 8 character password. (People (who speak english) have anywhere from a 700 word to a 10,000 word vocabulary, with those above 5,000 generally considered to be good writers or editors.) And these passwords are what... 24 characters long? Good luck cracking that by character brute force. Of course, in reality you'd have to include alternate spellings of words, common substitutions, capitalization, etc. So that'd knock your "number of words" down significantly. That's why I suggest that if you DO use words in your password, misspell them.

[corrado33]

5 hours ago, BobVonBob said:

Don't bother with letter substitutions. Every password guessing program worth its salt (ha! security joke) has rules to check every variation of that stuff, things like replacing an a with a 4 or @ or replacing o with 0 mean nothing in terms of security unless you're only worried about a human guessing them.

Yeah but that's not the point. The point is that if you use substitutions, the "complexity" of the password goes up, and the "space" (total number of possible combinations of characters) increases a bit. Sure, someone may have a brute force program that only considers letters, but if you throw a few weird characters in there it'll never be cracked (assuming the website allowed you to put weird characters in there.) Sure, the effect would be the same if you just threw a bunch of characters at the end of your password, but still. 

[NeuesTestament]

10 hours ago, SpaceGhostC2C said:

but the point I was trying to make is that ultimately being "weird" is what will make you more resilient to these refined brute-force attacks

So with a refined Brute Force attack it can theoretically be safer to have a Password that just consists of one single letter because they are not expecting someone to have a password with just one digit ?

Okay, this is an rather extreme example but that's the idea isn't it?

[corrado33]

10 hours ago, 2FA said:

Yep, people are confusing brute force attacks with dictionary attacks.

Wait, I thought brute forcing was just using a dictionary of every single possible combination of the available character set and using the hash algorithm to generate an equivalent file of the matching hashes. Theoretically, this could be done a long time in advance, then they'd simply have to search the hash file for your hash, then they know your password. 

 

Is this a dictionary or brute force attack? 

 

Regardless, I'm sure SOME hacker out there has a dictionary, however if you assume alphanumeric characters (62) and that each 8 character password takes up 9 bytes, and the text file has very little overhead.... the size of the file would be 1.2 petabytes. The file for the hashes (the important file) would be much.... much larger. That's a large dedication to hacking if you have the storage to pull that off. 

[corrado33]

9 hours ago, SpaceGhostC2C said:

I wonder if it would be possible to randomize blanks and send your password as "pass[NULL]word[NULL]", "[NILL]pa[NULL]ssword", etc every time, and once decrypted you reconstruct the password by removing blanks (=/= spaces). My intuition is that this would actually be very bad if you know it's the same password being sent each time, but good if you can't distinguish it from a password change?

Uh, what you're talking about is removing characters from passwords before hashing them, in which case the order of the blanks wouldn't matter because they'd be removed before the password gets hashed. This is... extremely bad practice because the passwords "pass word" and "p assword" and "passwor d" would all have the same hash. The correct way to do it would be to use the null character in the hash, and then the hacker wouldn't care, it's just another character, and the program would be able to spit out your password (nulls and all) perfectly. Or at least a password that also matches your hash (which is possible.) 

[BobVonBob]

1 hour ago, corrado33 said:

Yeah but that's not the point. The point is that if you use substitutions, the "complexity" of the password goes up, and the "space" (total number of possible combinations of characters) increases a bit. Sure, someone may have a brute force program that only considers letters, but if you throw a few weird characters in there it'll never be cracked (assuming the website allowed you to put weird characters in there.) Sure, the effect would be the same if you just threw a bunch of characters at the end of your password, but still. 

It doesn't go up enough though. There are only 2, 3, or maybe 4 substitutions for each letter. You would need to make a 16+ character password entirely out of ambiguous characters before the number of possibilities started to cause an issue for a password cracking software, and by that point your password would be secure for different reasons. Now throwing some garbage character that doesn't fit into the middle of a password? Calcul$atorsWinWars. That's a massive complexity boost. Putting a 4 instead of an A is a doubling of password possibilities, which is nothing.

 

Throwing characters at the end is less secure than that, because that's what everyone does. Password crackers expect for there to be symbols at the end or between words because that's where us fallible humans put them most often. There are way more passwords that go Wordswordswords123! or Words1words2words3! than there are Wo1rdswor2dsw3ord!s.

[2FA]

10 hours ago, corrado33 said:

Wait, I thought brute forcing was just using a dictionary of every single possible combination of the available character set and using the hash algorithm to generate an equivalent file of the matching hashes. Theoretically, this could be done a long time in advance, then they'd simply have to search the hash file for your hash, then they know your password. 

 

Is this a dictionary or brute force attack? 

 

Regardless, I'm sure SOME hacker out there has a dictionary, however if you assume alphanumeric characters (62) and that each 8 character password takes up 9 bytes, and the text file has very little overhead.... the size of the file would be 1.2 petabytes. The file for the hashes (the important file) would be much.... much larger. That's a large dedication to hacking if you have the storage to pull that off. 

Brute force refers to trying every single combination in the key space. A dictionary attack uses a specified list of combinations, called a word list. You could say a dictionary attack is a subset of a brute force, but they do mean specific things.

[Kamina]

Mine is way more than 8 characters.

[darrenvox]

some  people just have to find a better way to live their life...and not all you forum members just rhe people who perpetrate the act of this!!

[corrado33]

3 hours ago, CCWong said:

Any website worth their salt (this is a hashing pun), does not just store your password as a simple hash. Just look at Dropbox post-hack:

 

Your password gets hashed to a uniform length (more than 8 characters, btw), then it is hashed again with a salt, then it is encrypted with a global pepper.

 

This kind of brute forcing is only relevant if the service storing passwords is grossly incompetent, and if that is the case you were already screwed.

This wouldn't really affect hacking time though if the hacker was using a dictionary attack. Simply make your dictionary with all of the above encryption, hashes, etc. Right? Or am I missing something?

[HarryNyquist]

7 hours ago, corrado33 said:

This wouldn't really affect hacking time though if the hacker was using a dictionary attack. Simply make your dictionary with all of the above encryption, hashes, etc. Right? Or am I missing something?

To make an accurate dictionary for that particular stack, you'd have to know the pepper value, then you'd have to replicate the random salt that bcrypt uses to hash each password. That doesn't sound like it'd be particularly vulnerable to a dictionary attack to me, especially since the bcrypt salt+hash string is hashed with that unknown pepper value.

[CookieSmasherGus]

Well fudge. All website now should update their minimum password requirements to be at least 10 random characters long, randomized, unique... Some don't even accept special characters. It's really frustrating 

[Juanitology]

On 2/14/2019 at 4:10 PM, Firewrath9 said:

thats why they have a cooldown after you guess a password. 3 seconds after every mistake = .3H/s

 

this reminds me of something:

https://xkcd.com/936/

the cooldown is implemented when attempting to login. if you have a password hash dump from that site you don't need to ping the site for every login attempt, you just need to guess the right combination of characters that will produce that hash and voilá.