Blog

New Idea: Using Password To Encrypt User's Data


Credit CardI have a new idea about encrypting user's sensitive data - like credit card info and other. First, we store the logged in password in an 1 way hash like sha1 with salt, different from how it is stored in the database. We will call this hash password hash #2. ( I made up this term ) Let's say we have a password "BlackBoots" stored on the database as hash: "6c225a179ee7a4c92d7f3afef4019f2b55a00042". Upon login we will salt/mix it with "JumpingCroc" producing password hash #2 "ba95c56465470ce40db96df485620c5e8cb2be2e". We will store this password hash #2 on session (or cookie?) for later use. like:
$password = $_POST['password'];
$salt = 'JumpingCroc';
$_SESSION['password_hash2'] = sha1( $password . $salt );
Obviously, this has to be done upon login

Encryption of sensitive data

Whenever new sensitive data like credit card info is added by the user, the data will be encrypted using the password hash #2 as the key/salt; Before we store it in the database. So: Let's say we have credit card number 4123 4567 8901 1234, and we have to store it securely on the database, we will use reversible encryption, using "ba95c56465470ce40db96df485620c5e8cb2be2e" as the key. Something like:
$encrypted = mcrypt_encrypt(
      MCRYPT_RIJNDAEL_256,
      hex2bin($_SESSION['password_hash2']),
      "4123 4567 8901 1234",
      MCRYPT_MODE_CBC
   );
We used the user's password as the key encrypt his own data, so basically none among the database, the server files or anything will give clue for access to the encrypted except from the user. This obviously would only work if you store their password in a non-reversible way. like SHA1. Cause if you store the password in raw form, then you can just use that password to decrypt the data. note: I discovered while writing this post that 40 characters made by SHA1 is not valid because 256 encryption only needs 32 characters. So there should be a work around. Maybe like hex2bin on the example above.

Decryption of sensitive data

padlocksNow to decrypt it, the user must be logged in, hence, enabling the system to get password hash #2 again from the logged in password. The system will use it to unlock the encrypted data from the database. something like:
$credit_card = trim(
   mcrypt_decrypt(
         MCRYPT_RIJNDAEL_256,
         hex2bin($_SESSION['password_hash2']),
         base64_decode($db_credit_card),
         MCRYPT_MODE_CBC
      )
   );
Note: When the user changes password, the encryption must be renewed on all the encrypted data on the database, using the new password. If the data fails to decrypt with the key, then the data is totally useless, corrupted. In case of credit card info, they should be just deleted and let the user re-input the credit card data. In case of files, then the user lost his file; Probably would be a problem. Therefore as developer, we should know when to re-encrypt the data. (We can also store the "encryption date" so we can ask the user their password on that date, if they could remember it)

Worst Case: Hacked, database stolen, files copied

Worst case scenario, hacker got access on your database and files. He got a copy of your database and files and got away with it. On the database he got encrypted credit card data, on the server files he found the encryption algorithm we used and the secret salt. He discovers that we use this "password hash #2" thing I have mentioned. He will try to reverse the process by trying passwords. The hacker can only produce password hashes from all sort of password then try it one by one if it decrypts the data. With brute force technology, this "trying one by one" could be as fast as thousand to millions tries per second, depending on his computer power. But it will still be a reasonable amount of time before he successfully cracks a single user's data, that is, successfully guess the password of a user. This is way lot better than the hacker being able to crack thousands of user data instantly after he figures out your encryption algorithm/method, or worse, if you don't encrypt the credit card data at all. Same goes for developers of the system, developers will have no direct access to the sensitive data, even if they have all the data of the system, he has to do brute force too like a hacker. Therefore reduces the risk of getting the data leaked because of wrong recruitment or ex-employees with grudges.

Conclusion: Wanna try it!

This is so far the best idea I have for credit card storage. This is probably how the industry already does it, but I only thought of it just now. I will probably implement it on the next project that would require such feature. Other ideas: hash stored on hidden/secure local file, session id used as key/salt, calculated salt/key from user id, key from user's address, key from user's IP   Test File: blog1235-using-password-as-encryption-key.php

Comments (0)


Add a Comment





Allowed tags: <b><i><br>Add a new comment:


A Few Accomplishments

Integer eu ante ornare amet commetus vestibulum blandit integer in curae ac faucibus integer non. Adipiscing cubilia elementum integer. Integer eu ante ornare amet commetus.

Possibly broke spacetime

Integer eu ante ornare amet commetus vestibulum blandit integer in curae ac faucibus integer adipiscing ornare amet.

Terraformed a small moon

Integer eu ante ornare amet commetus vestibulum blandit integer in curae ac faucibus integer adipiscing ornare amet.

Snapped dark matter in the wild

Integer eu ante ornare amet commetus vestibulum blandit integer in curae ac faucibus integer adipiscing ornare amet.

Contact Me

Integer eu ante ornare amet commetus vestibulum blandit integer in curae ac faucibus integer non. Adipiscing cubilia elementum integer. Integer eu ante ornare amet commetus.