Im trying to work through the architecture for a database that I need to protect the email addresses stored in it. Its a Mongo database and each document stores two email addresses and a load of other content. I want to make sure that the document is not attributable to the email addresses, however when my program needs to access the document it can access the email addresses too. It also may need searching by email address.
My understanding. Hash the email addresses before storing using AES256 (or similar symmetric encryption standard).
Store the database somewhere other than the program (and the key).
When you need to be able to search for the email address, encrypt the email query with the key and search for this in the DB. When you find it, pull all the documents.
You can then decrypt the other email address that wasn't used for search.
Seems fine, but where do you store the key? In an enviroment variable? But if the server has been hacked, then whats the point in the encryption?
On a seperate server?
What is database encryption protecting against? Just the database dump being stolen or the server getting accessed?
Please could someone walk me through how this is done as industry standard?
Thanks
I have a website where a user can login using MVC5 Identity. (Although this question is not specific to that technology)
For a user to register with this website we must have spoken to them over the phone and an account manager must go through a registration form which sets up an "unverified" account for the user.
Following this the user is sent an email verification link, along with a generated password to login. The registration you would normally fill out pre-login is done post-login.
So I was wondering if in this scenario I can simply treat the users first login as email verification becuase the only way they get their password is from the email.
Is there any way this could be exploited and open up any security holes/allow validation without owning the email?
Edit:
Wanted to add the password is temporary (expires after a fixed period) and the user will be able to drop into a password reset form and a have a new one emailed if they don't do it in time. If the user has given us the wrong email I assume most will phone us.
I do not see this having any exploitation or holes and you are right to think this can be used as the email verification. Try it, and see how it works. Maybe after the temporary password is typed the user is prompted to type in a new password of their choosing.
my question is about the workflow of a web registration.
1) register with email + basic data
2) activate the account with a special secret link <- is this necessary?
3) allow the user to log in to the system
EDIT: I want to make the process as simple as possible without a password to choose/remember.
In more detail:
After a user is registering on a web site I sent out a confirmation with a generated password to login on the site and proceed.
Many sites sent an activation link first and then allow logging in to the system.
Is there any reason to do this additional step when I generate the password and sent it out to the user?
Thanks for your answers.
Is there any reason to do this additional step when I generate the password and sent it out to the user?
To ensure that the provided email address exists, and belongs to the person who registered the account.
I've noticed an increasing number of websites which skip this step. It seems to be a trend.
The purpose of the activation link is to guarentee that the email address provided by the user is one to which they have access. If you are generating a password and sending it via email to the user's email address, then the link is not required (because them logging in means that they read your email).
However, email is generally not a secure way to distribute information over the internet. You are sending them the password in plaintext, and you do not know how many people have access to that email account (e.g. a shared family account). I think you would be better off allowing the user to choose their own password at registration and then send them a link (offer to generate a password for them on the registration page, if you really believe that generating it is better).
The validation of an email account is usually to help prevent someone creating numerous accounts. This helps prevents spammers and various other bad people from attacking your site from different accounts.
In general you're trying to ensure that the person is who they say they are and that you have an outside means of communicating with them.
1 - to ensure that the email is belong to the registerd user.
2 - to make it harder to the people want to create many accounts (like forums where a single person have so many accounts to use them in voting or somthing).
I remembered a funny site that gives you a 10 minutes email , just to skip the process of creating a new email or even spamming your email by the sites you've registered in.
This way you make sure that the email address is valid and it will be more difficult for a spider to generate many users than without this step. Also, you might do a lot of things in your database when a user is registered and you can do these after the user is validated, to save time by not creating extra traffic on your database server for fake users.
I'm building a system that allows people to submit text and photos via email in addition to standard access on the website. I'm trying to weight the security advantages of two strategies in particular for verifying submissions from a user. Here they are as follows:
To based auth: Create a secret email address per user and present this to the user for submission. This strategy has the advantage that people can send from multiple devices that might be setup with different mail accounts
From based auth: Only accept emails from addresses that are registered in the user database. The idea being that it is impractical/difficult to impersonate registered users based on the sending address.
Can you think of other possible solutions? Which strategy of the ones proposed makes the most sense to you?
I would suggest that you not use From based authentication, at least not without some additional credentials (a passphrase, etc)
It's way too easy to forge, and certainly not difficult if you know someone's email address.
If you echo the email back to the user for confirmation, you can make things a little more difficult, but realize that your service can end up being used as a sort of spamming relay. (I could send 100 upload requests to you, with a forged FROM address, and you'd go ahead and spam the real person with 100 confirmation requests)
The better option is to check the registered email address but add the need for a code within the email subject known to the user. This way if they forge the email from address, they would still need a key to authenticate the incoming email.
I would go with "from" + confirmation, to avoid forging.
I.e. receive the email, but send a response with auth token in the subject line (or in the body) back to the "from" address. The user either will need reply, or click a link to confirm the submission.
And you post the content only after confirmation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
From security reasons, is it worth encrypting user emails before putting them into the database?
I know we hash and salt passwords but that's another story as we do not really need password originals. With emails it is different.
Knowing that the decryption key will anyway be somewhere close to the database, does it make sense to encrypt emails? I suppose if someone gets into the system, they will find the key as well, if not immediately then eventually.
What are the best-practices? Are there any other options available if I run my own servers and not on a shared/virtual hosting?
EDIT: I intend to use SQL Server. And no, it is no corporate software with security requirements, just some entertainment site I have in mind.
If you're going to need the email address in the future, then you'll have to store them in plain text.
You could encrypt them, of course, however, this is effectively security through obscurity in this case. Basically, if your application's perimeter is secure, your data within it can be plain text. Encrypting here adds complexity to you working with the data, but doesn't really stop an attacker from getting your raw data.
As you say, if he gets through your perimeter defenses, he's likely to easily get your decryption key to decrypt the email data. Encryption may slow down the determined attacker slightly, but will not add any real security to your data.
The best scenario is to hash the email address (with salt!) and store that. This allows you to check the email address against an input value (for example) and verify that the email address input is the same as what you have stored, of course, the major downside for this is that you can't know what the email address is without that additional value, so if you're wanting to (for example) regularly email your users, you'll be out of luck.
I suspect you're storing the email address because it's useful data, and you will want to do something with it (like send an email :) in which case, encrypting just adds overhead to working with that data, whilst gaining very little in return.
In this case, I would focus on securing access the database itself (i.e. your "perimeter" defenses) and ensure they are as strong as can be, whilst leaving the data in the database in plain text.
Hopefully this answer will answer your question as well.
Is it worth encrypting email addresses in the database?
In short, no, it is not worth encrypting user email addresses. You're right in thinking that a database compromise will likely result in somebody also gaining access to the keys required to break your encryption.
In general I agree with others saying it's not worth the effort. However, I disagree that anyone who can access your database can probably also get your keys. That's certainly not true for SQL Injection, and may not be true for backup copies that are somehow lost or forgotten about. And I feel an email address is a personal detail, so I wouldn't care about spam but about the personal consequences when the addresses are revealed.
Of course, when you're afraid of SQL Injection then you should make sure such injection is prohibited. And backup copies should be encrypted themselves.
Still, for some online communities the members might definitely not want others to know that they are a member (like related to mental healthcare, financial help, medical and sexual advice, adult entertainment, politics, ...). In those cases, storing as few personal details as possible and encrypting those that are required (note that database-level encryption does not prevent the details from showing using SQL Injection), might not be such a bad idea. Again: treat an email address as such personal detail.
For your entertainment site this is probably not the case, and you should focus on prohibiting SELECT * FROM through SQL Injection, and making sure visitors cannot somehow get to someone else's personal profile or order information by changing the URL.
One of the most often-cited truisms in computer security is that the
only truly secure computer is one buried in concrete, with the power
turned off and the network cable cut.
With that in mind the best way to securely store email addresses? Dont store them at all!
tl;dr Do you need their email address, or a way of sending them emails? Either trust someone who will do a better job than you or don't use the email address at all.
Why do you need to keep a record of a customer's email address? The only reasons I have run into are:
Account confirmation & authentication
Transaction & Marketing emails
Confirmation & Authentication
The core of what we want is two step authentication: Something they know and something they have. Something they know is a password, and is easy to prove since they will be the only one who knows it. Something they have is harder to prove and traditionally we use an email address since it is easy to verify. These days though there are other things we can use:
Mobile phone
An account with a trusted website (Facebook, Google, Twitter)
Mobile phone verification is simple. Send them a sms using a service like twilio.com and ask them to text back a confirmation code. We now know that the mobile belongs to the customer who wanted to register. With OpenID you can verify existing accounts with other trusted sites, and the confirmation process is handled by them.
For the customer to authenticate then all they provide is either their mobile number and password, or an OpenID authentication token. Neither require a email address (well the OpenID provider might but thats not your responsibility).
If these are not an option then you can still confirm an email address and then use it for authentication. Confirmation only requires a unique token to be stored and a link to be sent to the email address. Store a salted hash of the email address, and use that to match the account in the same way we do passwords.
Transaction & Marketing Emails
The real reason why we want to store the email address! So we can send them offers of stuff we think they need so they can delete it without reading it. Seriously though is email the best medium for this? If we have an OpenID account then why not use that for notifications? Send a Facebook message or write on their wall, #mention them on Twitter, send a text message to their mobile, build an app and push notifications at them. There are so many channels much more effective than email.
If you want to use email then use a email platform like Mandrill and MailChimp. When they register create a subscriber in a mailing list on MailChimp. Store the subscriber id with the account. For transaction emails ( reset password, account updates ) fetch the subscriber and pass the stored email to Mandrill to send the email. For mass marketing just send to the mailing list in MailChimp.
The only thing stored in the database is the subscriber id. It also gives all the benefits of using a email platform, unsubscribes, open and click through rates, e-commerce tracking etc. Email platforms will do a better job of delivering emails that you. They will also do a better job at protecting the privacy of their data than you. Let them do the hard work of database security so you can focus on getting more customers.
I think that when people can come in your database you are anyway screwed :)
It doesn't make a lot of sense to just encrypt your email addresses. Beside that there will be a lot of other information in your database that you would not like to be gathered, the decryption key will be indeed within reach at the same time your database is open.
I would like to suggest to find your layer of security and data integrity on a higher level. So the prevention of people entering your database.
And why would email addresses be so important? Most people will anyway get spam or their email addresses will otherwise be available somewhere on the web.
Depends on how often you access the addresses. If you read them once in a while, it might make sense, but this would be one of the last security issues I would spend time on.
I do not encrypt user e-mails. The point is to protect the database; the keys are accessible anyway if you actually want to use the e-mails once they are stored.
Do check the address for validity and possible SQL injection, though.
If the application server and database are on separate servers, it would generally increase security to have all or parts of the database encrypted.
Even if they are on the same machine, a hacker may not figure out where your password is stored (although I wouldn't rely on that).
I generally wouldn't encrypt the emails at the application level, instead relying on database-wide encryption offered by most enterprise databases.
Of course if you're using something like MySQL, then you have no choice but to do it at the application level.
I normally tell my clients it isn't worth the trouble encrypting a database, however if you have stricter privacy requirements it may make sense to do so.
Encrypting database content is always a tricky consideration. Clearly the content is useless unless it can be unencrypted, and if that has to happen without human intervention, then you're storing both the cyphertext AND the key somewhere. If that somewhere is on the same machine, then one might wonder why you even bothered.
Well, there's a few reasons why you might want to do this. One is because you're required to do so because of some company policy. Another is that perhaps your database is housed in a more hostile environment than that machine that accesses it.
In general, encrypting database content isn't going to win you any awards, but if you can justify it, then you clearly have at least some motivation to do so.
yeah could be helpful for the user if you hash it with salt. I had a code before which i used that I use salt and hash then I can decrypt it. Flow is that once user will register you then hash and salt (encryption process) it. Then if you need to fetch the encrypted data there will be decryption.