I am working on a fitness app, and it is going to have the following user data: email, first name, last name, birth date, height, weight over time, Body Mass Index over time and heart rate over time. This data is very personal and private to some people.

I was thinking of using AES to encrypt their email address, first name and last name so that if this data ever got compromised they cannot be identified. I would keep the key on the app server, and the database on a separate server.

This is however painful to do, as I use their email address for identification, so I need to store a hashed email, a crypted email, a crypted first name and a crypted last name. Furthermore this interferes with logging solutions as you need to ensure sensitive values are not logged. Finally, I would like to use the MySQL AES functions, but then I would have to pass the key over the wire into a stored procedure, and this just seems like an incredibly bad idea, so it would have to be done in app I imagine.

What is the recommended strategy here given this particular context? Is this over kill?


I don't think that the assumption that somebody can never be identified if email address, first name and last name is safe.

If the user also uploads their weight data to another service the weight data of a few months should be enough to identify them uniquely.

I don't think it makes sense to develop your own ideas about what data safety is supposed to mean. If you want to treat heart rate data seriously, than you should treat them as medical data. That means you follow the HIPAA standards.

Given the list of data you provide, you should ask yourself whether you really need to know your users first name and their last name. If you don't know them you can't leak them.

| improve this answer | |
  • Thanks, there is no reason for me to have their names, except for sending emails with nice greetings, so I will ditch storing them. I will probably just get rid of the heart rate data, it is not necessary and I sure as hell don't want to get bogged down with adhering to HIPAA standards. – Lee Jan 12 '14 at 23:40
  • @lee : I'm not sure that you have absolutely have to adhere to HIPAA when you store heart data, I think plenty of applications out there don't. I made the recommendation more in the spirit of recommending best practices. But I'm no expert... – Christian Jan 13 '14 at 2:22
  • 1
    @lee: you almost certainly need to store at least the email address, and it's almost always very easy to derive a name from an email address anyway — so this provides very little security benefit, but probably makes your application worse for users (emails starting with "Dear User", possibly getting caught in spam filters, etc). Direct answer: I think it is indeed overkill to store names/emails in an encrypted form — you'll need to have the key on your server anyway, and adding complex encryption will only increase the chances that you'll introduce a bug and make the app less secure, not more. – Joel L Jan 13 '14 at 13:59
  • @JoelL that is what I was worried about, complexity was getting out of hand. So you reckon it is fine to keep first names and last names seeing as people usually have an email address of something like name@gmail.com? – Lee Jan 13 '14 at 14:26
  • @lee — Yes, definitely. It might be "less secure" than not storing any data, but all security is about tradeoffs, and I wouldn't say this one (not storing names) would be worth it. (For a nice middle ground you could choose to only store First name + Last initial.) – Joel L Jan 13 '14 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.