1

My boss came up with a strange idea in my opinion. He doesn't want to keep email addresses in the database. However, we use them to log people in, and we keep newsletters to those who actively gave consent. Also, every now and then, we have to contact the whole bulk of people. Even with those 3 cases, he doesn't want them clear in the database.

So he came up with this: after normalizing them (trimming space, lower casing them and a couple more conversions), I should strong hash them. This would give us access to the "login" part.

After that, he understood we still need email addresses for those that signed up in the newsletter. So he suggested to keep another field with an encrypted email address, but nil to those that don't want a newsletter. Enough to say, the key to decrypt the email address needs to be in the server, so that the process can be done automatically.

The third case. Those cases where we really need to contact them. It turns out keeping the whole encrypted list is okay, as long as the password is stored in paper. This means that every time we needed to get all the email addresses, human intervention is needed. Worth noting that email addresses are clear in the database until we also run a process where we introduce the "paper password", moment where clear email addresses are deleted. This process is done weekly, so there are 6 days with a good sum of clear email addresses.

Honestly, I could buy the hash part, but the other two could seem more of a problem for the everyday employee (partial email address searches was also a thing to look for specific clients that could have badly entered the email address in the process and needed a little bit of help) than for any hacker, that could anyway gain access to the code, or brute force the paper-password ones.

Does it make sense to try to obfuscate email addresses at that level?

  • 3
    I assume you are talking about email addresses and not the actual emails? Apart from that - security and usability often contradict each other. What the right balance is depends on your specific situation, i.e. how costly it would be if addresses gets leaked and if the usability impact is acceptable for the decreased risk of compromise. Only - not enough is known about your situation. – Steffen Ullrich Sep 19 '18 at 15:13
  • hey @SteffenUllrich, yeah sorry, I meant addresses. I corrected every case I found! Yeah, we're all grumpy now, because we went through a security tasks batch, and most of them make our lives "harder" (but also safer, I hope!) – Guerrillero Sep 19 '18 at 15:21
  • I'm not gonna write out an entire answer, but none of these seem completely absurd, and they all seem effective at their goal, but whether they're work the effort or not depends entirely on your threat model and your appetite for risk. – Adonalsium Sep 19 '18 at 15:28
  • @Adonalsium individually they don't look absurd, but the final application is absurd, to me. Anything related to users has the email at its core. If they're current users, it's not safe to me, to keep an encrypted field with the password in the same server. – Guerrillero Sep 21 '18 at 9:10
  • Beware about "lower casing them". For the LHS there is no standard there and hence no guarantee that this part is case-insensitive. Also you have internationalized email addresses now, and lowercasing/uppercasing are not reversible operations in all cases. As for the RHS, if the domain name is internationalized also and not in its xn-- form, you still get perils in upercasing/lowercasing things when you do not have any language context. – Patrick Mevzek Jan 4 at 20:44
2

Welcome to stackexchange.

The hashing of the email for the purposes of login seems reasonable. There is no real reason not to do it, most sites just don't care enough, which is rather sad.

Encrypting the emails for newsletter may seem rather useless, but it can actually help if done right. The trick is to isolate the web server, so either run it under a limited user, or use firebird or other virtualization method. Then make sure the key is somewhere the web server does not have access and make a cron job for sending the emails. Preferably don't use a web server at all or use another one for the email sending.

In both cases, for the newsletter and for contacting clients, you should use asymmetric cryptography instead, so that you can encrypt the mails without the key. Alternatively use a ratchet setup.

However, I must say this seems a bit excessive just to protect some e-mail addresses. Unless you work for some company the clients would not want to be associated with, such as Ashley Madison, it seems completely unnecessary.

  • Thanks for the response. Yeah, I also thought it would be very extreme, but let's say the chief already panicked a little bit with a side project he has, also addresses related. – Guerrillero Sep 19 '18 at 15:24

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.