StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I don't know if there is much sense in encrypting data with user's password hash, <em>especially</em> if you keep hash itself in the database. In that case anyone who can access the encrypted data can also access the password hash and decrypt the data.</p> <p>Another approach would be to encrypt the data with the application-specific key salted with some user-specific data. However, then you face another problem: how to securely store the application key. To that question I do not know an easy answer, but keeping it in your source code is probably good enough if you fear that your database data can be compromised, but not the source code itself, e.g. if your database is stored off-site (think Amazon S3).</p> <p>Salting the app key with the user's password helps if you keep only password's hash in the database, but can introduce another security flaw: you have to keep user's password in clear text in the applications session.</p> <p>As for technical solution, it is quite simple and <a href="http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html#function_aes-encrypt" rel="noreferrer">sample code is available</a>. You could modify it as follows to encrypt the data with the application password salted with password hash:</p> <pre><code>INSERT INTO secure_table VALUES ( 1, AES_ENCRYPT( 'plain text data', CONCAT(@application_password, @user_password)) ); </code></pre> <p>In any case you would have to store your application password somewhere so I don't think that there is an easy approach that provides perfect security.</p> <p>Another approach I can think of is to ask user for a short PIN which you could use as an encryption key. The PIN would not be stored in the database, <em>but</em> you would need to ask user for it every time you access their data.</p> <p>And of course your have to think of is the feasibility of the encryption. You won't be able to index or to search it without decryption. It is probably required for a limited set of data (e.g. credit card number), but I wouldn't go to far with it.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload