Jump to content

Recommended Posts

I'd like to add a bit of security to my stored email addresses.  I am thinking of using mcrypt to do this. Is this a good idea?....or... Are there negative consequences of this I am not thinking of?

 

Goal is to prevent at least "trouble free" phishing of my email list if the database is compromised.

 

Thanks

Link to comment
https://forums.phpfreaks.com/topic/150584-security-of-email-addresses-in-database/
Share on other sites

I think it is a very good idea, except that you have to protect the key or else it will have been a fruitless effort. Also you have to weigh the benfit with the cost of trying to access a email address for use. It will now take at least twice as long becuase each email must be decrypted before it can be utilized.

Daniel0,

 

I guess one part of me agrees with you...but  the other part has this concern: If my database is compromised, it is much easier to send a phishing email regarding my website because that is where the email was found. In other words, someone could send an email (albeit fake) to the people in my database saying "Hey we want to update our info, send your SS#, first borns name, banking account info..." blah blah blah and have it look like it came from my website. The person receiving the email knows they've signed up on my website...thereby making it all the more believable.

 

Yeah, it seems as though the receiver of such an email should know better but it may be better to prevent it from happening (or at least attempt to make it not so easy)...in the first place.

 

I more than welcome dissenting thoughts on this!

Have you considered normalizing your storage of emails?

 

I split the email address into its local and domain parts... you can store the the domain part as normal but can then encrypt the local part. e.g joe@bloggs.com...

 

in my user table i store 'joe' in `email_local` and 1 in `domain`. then just have an association table to mach 1 to 'bloggs.com' - advantage of this is most people will have hotmail gmail etc so you cut down the amount of data stored significantly.

 

You still have the encryption to do - I'd leave that to mysql - use the aes_encrypt and aes_decrypt functions in your query - this should' be more efficient than decrypting the results in php.

 

so what you will end up with in should someone gain access to your database is a table full of domain names that they can read and a field in your user table with the local part of the email encrypted.

 

you will always have to pay for encryption/decryption but reducing the amount of data you are encrytping should always help.  Other may have better options but what I've suggested above is what I do - I'd love to improve so hopefully someone will have a better plan!!

Daniel is correct in that In this case there is no extra hit on your code IF you let the database manage the encryption - I very much doubt you will see a significant performance hit on this.

 

only point i would make here is that you sould use a class tomanage this and encrypt that file too (with zendguard or ion cube) so that your encryption salt is not available if they get ftp access too!

Daniel is correct in that In this case there is no extra hit on your code IF you let the database manage the encryption - I very much doubt you will see a significant performance hit on this.

 

No, not in your script, but the database server will most certainly take a performance hit.

 

If you for instance encrypt the email address then you will need to store it in a BLOB, but this means you cannot make any indexes, so if you have like one million rows and need to find the user with a particular address then you'll need to check every row, which will most certainly be slower than selecting from an indexed row.

ToonMariner, you way overestimate servers.  Also, just because something "can do it the slow way," doesn't mean that it should be done the slow way.

 

 

Lets say you have a popular site with email searching capabilities.  Now, lets say that there are 0-10 concurrent email address searching queries.  That will kill MySQL.  (Well, not literally kill, but MySQL wouldn't like it much.)

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.