1

I need a secure way to temporarily store my users contact information in a mysql database.

I don't want my customers sensitive information ending up in the wrong hands, so this is what I'm looking for:

  • Only the intended recipient should be able to decrypt the info (usernames are unique and could maybe be used as signature/key?)
  • The encryption has to be handled completely within the function, no external programs or services, in other words invisible for the end user.
  • Simple, bulletproof, and easy to understand since I'm far from a security expert, and possible loopholes could pass me by.

Does anyone have any tips for me? Articles to read, frameworks I could look at or even some example code? Any help is deeply appreciated.

Elias Van Ootegem
  • 74,482
  • 9
  • 111
  • 149
justanotherhobbyist
  • 2,124
  • 4
  • 28
  • 38
  • 2
    But where would you store the key? Password hashing aims to protect against a compromised server, so it's hard to keep a secret from the attacker. – CodesInChaos Oct 06 '13 at 13:03
  • 1
    Salt your hash, amongst other things: http://php.net/manual/en/faq.passwords.php – logic-unit Oct 06 '13 at 13:05
  • 4
    md5 **isn't encryption**. it's **hashing**. that's something completely different. you can't reverse md5 like your first paragraph suggests (but you could brute-force or use rainbow-tables). doesn't really look like you "_have a decent understanding of encryption_" – oezi Oct 06 '13 at 13:06
  • What exactly are you trying to secure? Passwords? Usually you hash them with some 1-way hashing algorithm that is hard to crack i.e (bcrypt) and when a user sends you their password you first hash it and compare it against what's in your database. – gmaliar Oct 06 '13 at 13:08
  • Allright, I'll edit my post, but how come it always ends up the same hash? By decent understanding I understand the concept of public/private keys etc. I understand the different pieces but not how to put them togheter. – justanotherhobbyist Oct 06 '13 at 13:08
  • you need to look at `mcrypt` library in php. – Rajesh Oct 06 '13 at 13:09
  • I need to encrypt their contact information. – justanotherhobbyist Oct 06 '13 at 13:09
  • it ends up with the same hash because the same input always results in the same output. thats the whole point of hashing something - you can reproduce the hash from a given password (for example) and check for that so you don't have to store the original password on your server (which could be stolen). – oezi Oct 06 '13 at 13:10
  • _"and as you probably know can easily be decrypted from any machine using md5(5f4dcc3b5aa765d61d8327deb882cf99)"_ ... Wow, I think you need to check on that m8. `md5` is a _hash_, not an _encryption_. Hashes are one-off's, one-way algorithms. md5 is weaker than sha256, but it's not _that_ easy to break... as in: it does take _some_ time – Elias Van Ootegem Oct 06 '13 at 13:10
  • I've seen mcrypt when researching, is it safe? – justanotherhobbyist Oct 06 '13 at 13:10
  • @hustlerinc: [depends on the cypher](http://www.php.net/manual/en/mcrypt.ciphers.php) you're using, but it is if you use it well... but for passwords, you're better of using salted sha256 hashes – Elias Van Ootegem Oct 06 '13 at 13:11
  • 1
    i strongly recommend to read http://stackoverflow.com/a/4948393/288773 wich explains the difference between hashing and encryption really well. – oezi Oct 06 '13 at 13:12
  • If you want an answer about encryption, I'd recommend dropping the bit about md5 (as you now know, that's not encryption), and explain exactly what you want to encrypt. For instance credit card info has PCI regulations, so it matters. – Rich Bradshaw Oct 06 '13 at 13:26
  • Not sure who -1'ed this question, it's a legit question from soneone trying to learn. – OneOfOne Oct 06 '13 at 13:26
  • I've edited it for you, to help get the right answers, and not just another 'debate' about md5. – Rich Bradshaw Oct 06 '13 at 13:27
  • @RichBradshaw I only used md5 example to show a bad way to store it, pointless repeating what so many others allready said. And why does what I want to store matter? It's sensitive information passed between 2 users, not too long. – justanotherhobbyist Oct 06 '13 at 13:29
  • Also, as you might already realise, you need to store the key on the server, so if the server is compromised, so is the key. However, if only the database is compromised, this will help. – Rich Bradshaw Oct 06 '13 at 13:29
  • I'm on your side hustlerinc – too many people try to explain salting on every question that even mentions MD5, I've slightly rephrased to stop that happening for you! MD5 isn't encryption, so wouldn't help at all in this case. – Rich Bradshaw Oct 06 '13 at 13:30
  • @RichBradshaw if the server is compromised it's gonna do a complete rewrite of itself (not the database, the entire harddrive), so that the logic of the hash isn't exposed, all they have if they manage to hack into the database is a bunch of random numbers and characters. Would this be safe? – justanotherhobbyist Oct 06 '13 at 13:32
  • If the database is compromised the data wouldn't be accessible, but if the whole server was, it would be possible to retrieve the key most likely. By compromise, I mean, you might have a PHP script that allows file access or something, not that it's necessarily physically compromised. – Rich Bradshaw Oct 06 '13 at 13:46

2 Answers2

0

Well, the question is actually a very good one. There is one way to ensure this kind of problems dont happen though. But first i'd like to clear out the difference between hashing and encrypting

Hashing is when we convert the subject into a long hash. This is very hard to reverse and requires a lot of resources to do it. We usually hash passwords e.t.c. Encrypting is when we want to store data securely but want to be able to get it back, we convert it into another long thing but we can also reverse it easily(If we know the key)

You can use what is called a 'salt' to protect hashes like your password, since we know that Hash(x) is gonna be VERY different from Hash(x+y), we can use that. Although i wouldnt use MD5 if i were you, it is still great but collisions have been seen in it(A lot of hashing algorithms have them, but being found reduces their security). I recommend you use sha256/sha512. They are very secure and no known collisions have been seen in them so far.

Me being nerdy aside, your problem is very simple. I am going to use the hash function of php in my example. Since you said the usernames are unique, you can use this for a very safe hashing system

$password = YOUR_PASSWORD_HERE;
$username = USERNAME_OF_USER;
$safe_hash = hash("sha512",$password.$username);

This merges the two username and password and hashes them with the sha512 algorithm(Change the algorithm if you want). This is very safe as 'password'.'user1' is having a unique and different hash than 'password'.'user2'

If you want to make it even more secure, you can add other stuff like creation times, last names,first names, mobile number, email, creation time, anything that you know and is preferably unique really.

As for encrypting the data(So that you can get it back if you want to) you can use mcrypt. You can use mcrypt_encrypt and mcrypt_decrypt. You can specify the cipher you want to use and also the mode you want to use. Then when you want your data back, you can again give mcrypt the key, algorithm, mode and the nonsense output that mcrypt_encrypt gave you and you'll have your original data.

I recommend using a very secure key by using hashes, since its very hard to reverse engineer them. Using a sha-256 hash with a good and unique string(I recommend mixing multiple pieces of data in the hash string) will help you secure the data needed.

Aayush Agrawal
  • 1,354
  • 1
  • 12
  • 24
  • This answer isn't related to the question. – Rich Bradshaw Oct 06 '13 at 13:47
  • @RichBradshaw How come? Is it because it's a salted hash and not "true" encryption? – justanotherhobbyist Oct 06 '13 at 13:50
  • I updated the answer with encryption aswell. You can use that in case you want to get the data back – Aayush Agrawal Oct 06 '13 at 13:59
  • aayush – thanks – the question wasn't that clear at first. hustlerinc – hashing is not encryption. It's not 'bad' or 'false' encyrption, it's just not encryption. You use it for a totally different purpose, primarily because it only goes one way – you can't 'decrypt' a hash. – Rich Bradshaw Oct 06 '13 at 14:12
  • @RichBradshaw does this mean a hash when used correctly is safer than encryption? Since it can be decrypted with a key, and those are easier to access than physically accessing the server to read the hashed information? Sure logging in through ftp and manipulating the files would be dangerous too, but more difficult for the end user to expose than a private key. – justanotherhobbyist Oct 06 '13 at 14:17
  • A hash can not be decrypted. the md5 of `1` is `c4ca4238a0b923820dcc509a6f75849b`. The md5 of a copy of Ubuntu Linux (several hundred megabytes) is `5d5d1a7da2a0659b163d4f8bd70fbe6f` – note that they are the same length. The hash does not contain all the information in the original data. They don't go backwards, and are used for passwords for this exact reason. For contact details though, this is completely useless. – Rich Bradshaw Oct 06 '13 at 14:42
  • @RichBradshaw Why is it useless for contact details? What should be used instead? – justanotherhobbyist Oct 06 '13 at 15:26
  • It's useless because it only goes one way – you can not decrypt a hash – that's the whole point! Bit like cooking an egg – you can't go back to the whole egg. aayush suggests mcrypt_encrypt and mcrypt_decrypt. These are more like locking and unlocking a box, which is what you want. – Rich Bradshaw Oct 06 '13 at 15:27
  • @RichBradshaw But the data is never supposed to leave the mysql server, so in this case a salted hash should be the best solution am I right? It will be hashed and dehashed on the same machine. Sorry about all the nooby questions. – justanotherhobbyist Oct 06 '13 at 15:48
  • YOU CAN NOT DEHASH A HASH! Please listen to what everyone is telling you! Hashes are one way. Dehashing doesn't exist! If you take the hash of say, an email address, how will you get the original email address back? YOU CAN'T! That's literally the point of a hash! – Rich Bradshaw Oct 06 '13 at 15:59
  • @RichBradshaw You get what I'm trying to say, read the hash in plain text on the webserver that created it. My formulation might be wrong but still not an incorrect statement. It is ofcourse readable on the machine that first created the hash. You didn't really answer the question, capslock or not. – justanotherhobbyist Oct 06 '13 at 16:08
  • The capslock weren't angry ones :) It's not readable on the machine that created the hash. Hashes are one way. You don't want a hash, you want encryption. It's important that you realise this, as otherwise you can't look up the right stuff. Hash = one way. Encryption = you can undo it again. – Rich Bradshaw Oct 06 '13 at 16:38
0
  1. I wouldn't use md5, use sha1 or sha256.
  2. Use a per-user-salt, example :
$salt = bin2hex(openssl_random_pseudo_bytes(6));
$password = sha256($account_creation_time . '-' . $salt . '-' . $plain-password);

Then store $salt, $password and of course the account creation time in the database.

OneOfOne
  • 95,033
  • 20
  • 184
  • 185
  • That's what I said ^. – OneOfOne Oct 06 '13 at 13:15
  • 1
    Sorry, dead tired ATM, didn't see that o.0, I'll have a cup of coffee before I comment again :P – Elias Van Ootegem Oct 06 '13 at 13:17
  • Say for the simplicity of the example I "salt" the encryption with the recipient username, and the message, then I only show the info if the intended user is trying to read it, this would be fairly safe unless someone gets a hold of my .php files and start reverse engineering right? What if they get a hold of them (very real possibility) can they decrypt from another machine or will it stay as the hash? – justanotherhobbyist Oct 06 '13 at 13:19
  • Hashes are one-way, only way they can get the password is to try every possible combination of letters/numbers mixed with that salt and account creation time from the database, but if they have access to your database you have bigger problems anyway. – OneOfOne Oct 06 '13 at 13:23
  • Yeah, thats what harddrive overwrites are for. Truecrypt supports that right? :) – justanotherhobbyist Oct 06 '13 at 13:24
  • 1
    It's worth nothing that this answer has nothing to do with the question. – Rich Bradshaw Oct 06 '13 at 13:46