Is there a way for a "hacker" to know your password length and if you used numbers or symbols

Question

I understand that you make a password more secure by increasing its length and by adding numbers and symbols since you increase the number of possibilities that a hacker would have to brute force. However, would he know beforehand the length of the password and if you used numbers or symbols? Or would he only find out slowly as his brute force machine chugs away?

Answer 1

Even most weak hash routines like MD5 do not reveal the length or diversity of characters in your password until the matching hash is found.

This is thanks to something called the Avalanche Effect of cryptographic hashes.

This holds true even more so for strong hashes. The attacker would not have any clues about the password until the brute-force successfully finds a match.

It is important that the developer uses a unique salt per user, so to prevent the use of pre-existing Rainbow Tables.

Answer 2

The way passwords are stored these days takes care to avoid revealing anything to the attacker. The stored form of the password has a fixed length, and even the system owner cannot find the original password which produces this fixed-length representation -- in theory, the only way to find whether you have the correct password is to enter it and be logged in successfully.

A brute-force attack tries every possible password, starting from the empty string, every possible 1-character string, every possible 2-character string, etc. A dictionary attack attempts passwords from a collected dictionary of strings which have been used as passwords or could be used as passwords, often with variations in capitalization and spelling (e.g. try permutations of upper and lower case or common substitutions).

Revealing details about acceptable passwords helps attackers tweak their attacks to reduce the size of the search space, which means they can focus their work better and get done (or give up) faster. For example, if they know the password has to be at least 12 characters long, they can bypass any guesses which are 11 characters or less. Similarly, if they know there has to be at least one digit and one punctuation character, they can skip those dictionary entries which do not meet these criteria, and/or avoid creating guesses which fail a known criterion. (However, these criteria may still be useful, because they force users out of the even shallower pool of all-alphanumeric passwords.)

Answer 3

Assuming that your application properly stores the users passwords by hashing them with a good encryption routine such as bcrypt, having the data from the database will only give you one bit of information: the salt. Everything else will be encrypted and likely the exact same size for all passwords (at least in binary; you can transform such in decimal digits and the size will eventually vary, but it won't be representative of the number of characters in the password.)

Is it possible for a hacker to know the length of your password?

As others mentioned, if you have that information, such as a minimum and maximum number of characters, then you at least offer such a limit to the hacker. So between 8 and 32 gives that hacker a smaller range of attacks than 8 and 256, or even, unspecified (and your app. makes sure to truncate if longer than an unspecified, but still pretty large maximum.)

There is, of course, another possibility. If the hacker somehow has access to your packets, then the hacker may get some information there. Especially between a rather small or a rather large password. The TLS connection, even if you can't decrypt the password, is likely to give up a partial bit of information in that regard. Scientists who work at cracking existing encryption schemes have made such comments, that a certain amount of parameters can be guessed with relatively good estimates from encrypted data. For example, if you have a sentence, it is likely to include many spaces. With certain encryption schemes, that can help break the message. And even if it takes a month or two to break your password, it is likely good enough since you probably don't change your passwords that often... That being said, this is very complex work and I don't think that too many black hat hackers would bother in that direction.

What about the set of allowed characters?

As for what characters can be used in a password, this indeed has a huge impact. The best way to look at it is to calculate the number of possible combinations. This is pretty simple math, although the more rules you add, the more complicated it becomes.

First, let's say your password is only allowed to include 5 digits (0-9). The math is:

10 ^ 5 = 100,000

Now lets add letters, a to z, you get another 26 possibilities per character:

(10 + 26) ^ 5 = 60,466,176

That's a potential of 604 times more possibilities the hacker would need to check to find your password.

Finally, if you force the user to have at least 2 digits and 2 letters, the 5th character can be any digit or letter, you actually decrease the number of possibilities like so:

10 ^ 2 * 26 ^ 2 * (10 + 26) = 2,433,600

Nearly 25 times less than letting the user really do whatever he wants. Adding other constraints such as never repeat a letter or a digit again reduces the total number of possibilities...

10 * 9 * 26 * 25 * (8 + 24) = 1,872,000

So what I want to get through here is that the number of possibilities is affected by many factors. Just adding more characters to a password gives a simple brute force attack less of a chance to ever find the password. However, most attacks make use of dictionaries which have a limited set of passwords, including very strong passwords of many mixed characters. According to Pwned there are over 555 million passwords that have been added to the hacker's dictionary. With such a large number, even a dictionary attack does not have much of a chance, I think, but it is still a lot less than what possible passwords you could enter with a system that allows any Unicode characters with at least 8 characters and no indicated upper limit (but let's say our software uses 256 max.)

As of May 2019, the number of assigned Unicode characters is around 277,000.

The math for Unicode shown above does not take in account the possibility that you use UTF-8 or some other such encoding. Also the total number of characters is probably not realistic because no one can type them all on their keyboard, but I'm hoping that one day we'll have tool that simple generate random buffers of data and not passwords.

Here is my Shell script, using bc, to calculate the powers and the sum shown above:

out=sum.bc
rm $out
count=8
while test $count -lt 256
do
    echo "277576^$count+" >>$out
    count=`expr $count + 1`
done
echo "277576^256" >>$out
bc <$out

Answer 4

as george bailey stated, it is not possible. the secure practice for storing a password is to add a salt and then hash it a large number of times. as soon as it is hashed the first time a human would not be able to tell what components a password contains, though common computers are powerful enough nowadays that they could easily crack the entire password at once if it is only hashed once. but there's no way to crack a hashed password "in parts"

now the reason it was made like this is because if you knew that there were, for example, five numbers and three letters in the password, then you could use this to crack the password. how ? there are scripts which can generate an extremely long list of every possible combination of five-numbers-and-three-letters, and then you could use another script that attempts each password on the generated list until it is cracked.