# Will I jeopardize security if I store the first three characters (hashed) in a separate table?

In order for a customer service representative to identify a customer, they'd like to ask the customer for the three first characters of her password.

The minimum length of the password is currently eight characters, a "big" salt is used, and the hashing solution is BCrypt.

The idea is to hash and store the first three characters separately.

• This is a bad identification policy, which allow attacker spoof as the service provider, acquire the info, then spoof as the user. This is how some telco mess up and allow SIM card theft and issue to the phisher (which perform further attack on the user online banking ) Commented Sep 6, 2017 at 15:08

If an attacker gets access to the stored hashes and knows that each of these only encodes a single character he can brute-force this character with very few guesses. The salt does not protect against this since it is part of the stored password hash and thus known to the attacker. The slow-down done by bcrypt does not help either since only a few characters are to guess.

Even worse, once the attacker got access to the first 3 characters of the password this easy way brute-forcing the remaining characters is considerably less effort as if the password would need to be brute-forced in full.

If there is no separate hash for each of the first 3 characters but only one hash over all three together it is not as insecure as with three one-letter passwords but still totally insecure.

In order to make the problem of storing one or few instead of all characters of a password in a separate hash more clear show the math involved consider the following an example:

• Assuming that a password consists of 100 random digits.
• When brute-forcing this password at once an attacker would need to check at most all 2^100 permutations and on average the half which is still too much for practical attacks.
• But, if all these digits are stored in separate hashes and the attacker thus gets a positive feedback already after cracking the digit for a specific position he only needs at most 10 attempts for each position and thus 10*100 attempts in total. This makes the password trivially to crack within a short time even if each attempt would take a full second. And no salt will protect against this.
• If you don't hash a single digit but only combinations of 3 digits it gets a little bit better but is still far from secure. In this case each of these hashes for 3 digits would need at most 1000 tries. With 33 of such hashes (and one for a single digit) o store the original 100 digit password an attacker would need at most 33*1000+10 attempts, i.e. it is still absurdly insecure.
• Thanks a million @steffen. However the interpretation should be "store the first three characters in one table". What would the math be then? Commented Sep 6, 2017 at 7:16
• @MartinR-L: the attacker in this case does not have to crack three one-character "passwords" with feedback after cracking each but instead one three-character "password" with feedback only after the three characters. This is better than three one-character passwords but still totally insecure. Just do the math: with a-zA-Z0-9 used this will be 62^3 (238328) brute-force tries at most and half on average. Commented Sep 6, 2017 at 8:11
• @MartinR-L furthering SteffenUllrich's point ... say someone got there hands on the hashes in this database, and are easily able to brute force the 3 characters. They could then call customer service, give these 3 characters and ask to reset there password ... game over. Commented Sep 6, 2017 at 16:42
• @CaffeineAddiction But "getting one'e hand on the hashes of the database" is a separate issue. Commented Sep 7, 2017 at 6:05
• @SteffenUllrich There's no external API nor GUI that exposes the three characters. It will only be checked by a CS representative (who's on a separate system behind all kinds of security measures). Commented Sep 7, 2017 at 6:23