Would it be a good idea security-wise to store salts with their last character removed, and then bruteforce the last character to further the amount of time it would take to create rainbow tables and such? This is assuming the hashing algorithm in use is Whirlpool.

This would make logins take a little longer, but it would be a restriction on bruteforcing speed that cannot be bypassed like other methods can.

Thank you in advance.

2 Answers 2


Assuming that you're using per-user salts (i.e. a different salt for each user account), rainbow tables are already an impractical means of attacking the hashed passwords (rainbow tables are typically used where there is either no salt or a salt which is common to all accounts and preferably known to the attacker ahead of time).

Where you're using a password hashing scheme such as bcrypt, if you're looking to make this "harder" for an attacker it's best to use the mechanisms provided by the scheme (e.g. the work factor) rather than inveting your own.


First: Salts are not meant to be secret. So, I'm not sure what is accomplished by this approach.

Second: if you have to brute-force the salt, then the attacker can too. What I'm assuming is that your approach depends on the attacker not knowing your custom encryption scheme, and this is a bad idea. The strength of encryption is that it is secure even if an attacker knows your scheme. If you are using a secure encryption algorithm, then you don't need to try to "improve it" (often improving a known scheme weakens it).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .