1

I had this idea to permanently conceal user password by requiring minimum length then stripping certain characters. For example if the user password is secret123, the system will strip it down to ecrt12, add random characters to it like ecrt12!@#$%^&* before hashing, adding salt, etc, then storing to DB.

Granting all common practices were also used like:

  • unique salt per user
  • system pepper
  • bcrypt/scrypt or whatever latest best crypto algo available

To summarize in code:

$hash = hash($modifiedpassword.$uniquesalt.$systempepper) // iterated to 1000s.

In the event an attacker manages to reverse all hashes, the best info they could ever recover is ecrt12!@#$%^&* and not the original secret123. Even if they hack the system code, they will never know what characters were stripped.

My question now is as security experts, would you recommend this practice of stripping/appending the original user password?

| improve this question | |
  • I don't see how this method could possibly work. What do you do with the result of all this hashing? What use could it possibly be? If you want to conceal it forever and don't mind writing it in a form that's not usable, why write it to the database at all? – David Schwartz Apr 30 '12 at 6:55
  • @DavidSchwartz The hashes are usable. I am not sure if I get your question but if you are asking how to authenticate on login (since passwords have been stripped), the system just repeats the process on login. It strips predefined character positions from the password and appends the previously added salt. – IMB Apr 30 '12 at 8:33
  • How can it re-add the same random characters? – David Schwartz Apr 30 '12 at 9:47
  • 2
    The three salts do no more than one salt. This is complexity for the sake of complexity. – David Schwartz Apr 30 '12 at 10:20
  • 1
    there's no difference between "adding six random characters to the password and adding a salt" and "adding a salt six characters longer than I first thought of". @DavidSchwartz is saying the cases are degenerate. – user185 Apr 30 '12 at 13:36
5

How would you guarantee that the "same" random characters are used every time the same user enters their password? You can only guarantee that if you write them down (or otherwise deterministically generate them), so "!@#$%^&*" in your "password" is actually just another part of the salt.

This leaves you in a situation where you've converted the user's password from "secret123" to the regular expression "^.ecret12.$", which reduces the password's effective complexity from 9 characters to 7 characters. An attacker who tries "pecret129" will be allowed in.

To answer the question directly and to borrow a quote from ewanm89 below: no. I don't recommend doing that.

| improve this answer | |
  • 3
    To sum up, no we do not recommend it. – ewanm89 Apr 29 '12 at 10:18
  • 2
    @IMB they may not have the full password, but they only have two characters to guess. It's like playing Mastermind: en.wikipedia.org/wiki/Bulls_and_cows – user185 Apr 29 '12 at 10:41
  • 2
    Yes it is, but it's harder to discover a longer password from a hash than it is to discover a shorter password and then mess around guessing a couple of cleartext characters. Cryptographic hash functions are designed with that in mind. – user185 Apr 29 '12 at 10:50
  • 3
    not to mention, if I was to do an online attack where I just start cycling through passwords I stick in the box (albeit slowly if there are other protections) it's easier. This doesn't make finding the password from the hash any easier or harder, and it does make a bruteforce attack easier). Ultimately it serves no purpose other than doing more work in the password function, and negligibly at best. Just bcrypt(password.length + password + salt) and be done with it. – ewanm89 Apr 29 '12 at 10:54
  • 1
    @IMB: Your logic is incorrect. In your example, it's pretty obvious that "secrt12" is "secret12". So he will be able to guess them. And the removed characters means he'll have fewer combinations to guess to find "secrt12". Consider if the password is "foo,bar". That's harder to guess than "foobar". But if you let him do it in two steps by removing the comma before hashing, then it isn't any harder. – David Schwartz Apr 30 '12 at 10:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.