tags:

views:

62

answers:

2

Hi,

I had an idea for password security.

When a website was generated it would create 2 shuffled copies of all keyboard characters, a random length salt. Further more it would create a random offset number for salt.

Example.

$password = "Password";
$offset = 3;
$salt = "f00";
$saltedPw = "Pasf00sword";


$setOne = 'ftwgDtrE354.....';
$setTwo = '$5grFIPV9@.....';

$pw = encryptFunc($saltedPw, $setOne);
$pw = encryptFunc($pw, $setTwo);

salt, offset, setOne and setTwo would be stored in a php file meaning if the db was compromised and/or stolen the passwords couldn't be easily easily decrypted.

Does this sound like a fairly strong way to secure a password? If not what is wrong with it?

+4  A: 

Just store your passwords hashed with a unique salt per user. Don't try to invent your own security model.

It's rare that you really need the ability to decrypt user passwords.

philfreo
+1 for "don't invent your own security model." This isn't exactly new ground being covered and there are already solutions available for these problems that have been scrutinized by the security community for years. If you *think* you *may* have stumbled across some clever new way: you most certainly didn't.
deceze
I wasn't trying to be clever or to invent a new method of encryption. I just wanted feedback on whether the double shuffle method would provide sufficient obfuscation
JasonS
+4  A: 

This is a great example of obfuscation, not of real security. You're just adding more steps to obscure the secret, you're not making it inherently secure. If somebody knew the steps you're taking, your "security" would be gone. Since you're relying on a secret, your security is only as strong as the security that guards the secret. It doesn't matter if the secret is one key, two keys, or a hundred keys and a simple algorithm. If your server is compromised and your encrypted passwords are stolen, your secret is probably well within reach of the attacker as well.

The proper technique to use is to hash passwords, making them undecryptable by the non-reversible nature of hashes. Even you can't get the original password back. The only way to guess a password is by brute-forcing it, which moves the security to technical feasibility. You can make it even less feasible to brute-force your passwords by salting each with a random salt, which prevents mass-pre-computation (rainbow tables).

Are you seeing the difference in approaches? :)

deceze
I understand hashing, however I have a need for 2 way security. Doesn't 2 way security depend on obfuscation? Otherwise how else would it be decrypted?
JasonS
You should probably explain *why* you need passwords to be decrpyted. The standard approach for passwords these days is non-decryptable, so if you have a genuine need to decrypt them you're doing something significantly different from everyone else.
Spudley
@Jason Encryption ("2 way security", as opposed to hashing) always relies on a secret key in some form. The fact that you're not using one key but two and are performing a little dance around the encryption process does not make the encrypted password any more or less secure, it just makes the encryption function slightly more lengthy. If the two keys are still stored in the same place (on the same server) where an attacker would find them both together, it's a completely moot procedure. You also don't need to salt the password before encrypting it, salts only really make sense with hashes.
deceze
Thanks, this was the type of answer that I was looking for.
JasonS