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?
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? :)
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.