Is using dynamic obfuscation and peppers for password hashing a good idea?

Question

I've read now the whole day about password hashing and secure authentication and though I read very often that mostly every own algorithm makes the proven hashing methods just less secure, I just got an idea regarding password hashing e.g. with scrypt, salting the password and using a pepper:

1. Mutating the original password before hashing could probably improve security if using a random string every time and use that to obfuscate the password. Obfuscating with one specific schema alone wouldn't improve security but using all the time a new random string (which has to be as random as possible) would make it impossible for a hacker to get the password as long as he doesn't have that random string.

2. As you would need that random string for verifying the password you need to store and read it in some way, which makes it vulnerable of course again to hacker attacks. I would save these random strings with the uuid of the user as key and would encrypt the actual content with a password by using openssl_encrypt (a php function) on a different server.

3. Now the problem would be the password with which the obfuscation passwords are encrypted. So I came along the idea to show the user initially after registration a random sequence of dictionary words that are not stored at all and the user would be prompted to write it down. As additional protection i would use here also a pepper to strengthen the insecure dictionary passphrase. Now the user needs to answer upon every login a security answer, which is then used to decrypt the random string from the other server that is necessary to verify the normal password. If he loses this security answer passphrase he can reset his password using his email.

4. Upon Registration only strong passwords can be entered and every password is stored with scrypt hashing, a salt and a pepper (which lies on a third server). Before hashing it, it gets obfuscated. Now I wouldnt use a static pepper which is then vulnerable again, but since there is a third server anyway I would dynamically generate that pepper.

What do you think would this method add more security or would it even be less secure? This is not absolutely about using it in production environment but more about my interest in that topic itself and understanding it better.

Answer 1

What you are describing is essentially an extra salt encrypted with a key derived from an extra password consisting of dictionary words that are not chosen by the user.

I know this will appear as a rather vague and general criticism, but I see three downsides with this:

• You are rolling your own. Inventing your own systems to solve problems with established solutions seldom enhance security. In the end you are more likely to make an error in the implementation and expose yourself than you are to improve your security. (With that said, speculating about new systems can be a useful learning experience.)
• Complexity is your enemy. This introduces a lot of complexity, but it is not clear what problems the extra complexity is intended to solve.
• Usability is your friend. Who wants to ontop of your password memorise another password that you are not even allowed to pick yourself? As a user I would want to have some substantial security benefits to accept that.

Contrast this with some other common practices to increase password security, and ask yourslef what your system provides to offest the cost in complexity and usability that these systems does not:

• Encrypt all scrypt hashes (with hash, salt and all) using a HSM so that an attacker can not get hold of the encryption key.
• Use two factor authentication (e.g. with a SMS login code).