4

I'm looking at whats nessecary to create a small accounts server for a video game I'm programming in my spare time. User privacy is a very important topic for me, and I don't want to keep anything about my users that isn't really needed to provide the service I'm offering. I don't feel I have the right require that info, and I don't really want the responsibility of protecting that info (Don't get me wrong though I'll still do whatever is nessecary to protect what I do take).

My primary idea for this is to store unsalted email hashes as the account identifiers, the usual salt+hash password, and no other identifying information. I haven't really seen mention of this done previously so I'd like to confirm that the idea is sound. With this system I can still send emails to users for things like password recovery since they will still need to send me their plaintext email to log in.

Is this a good idea? If I retain IP addresses for logging purposes and link IPs to accounts, will a hacker be able to match the IPs elsewhere and work out/guess many emails anyway? Is a large list of user IPs valuable to anyone?

Are there any other methods for minimising identifying and private information while still ensuring that each user can only log into their own account (such as password alternatives)?

Improve this question
  • 2
    Hashing emails would make it difficult for you to send emails to warn users that your db was stolen, and they need to change their password. Or notify them of maintenance. Or... You should probably concentrate on securing the registration/login page from harvesting attempts. You may need to provide more details about what you're doing with respect to IP logging. – Clockwork-Muse May 26 '14 at 10:50
  • I'm looking to log IPs into an audit history of requested services and outcomes so that if it seems one particular IP keeps failing at sensible communication (possibly a hacker looking for weaknesses or whatever), I can lock them out for a while. I suppose that history info is only useful for that purpose for a couple of days anyway. – Numeron Jun 5 '14 at 1:24
  • There are existing solutions for that, some free, for most/all existing servers (or as a purchasable piece of hardware). Your current idea is a good naïve first solution - it'll stop/slow basic attacks, but determined attackers have better tools, including running distributed (using multiple connections). Depending on the network, even multiple legitimate users may appear to be coming from the same IP (through NAT). Many ISP issue dynamic IPs to consumers, which are often changed if the connection to the modem drops. See if existing solutions work for you first. – Clockwork-Muse Jun 5 '14 at 10:28
0

Is this a good idea?

Yes and No. I don't think there is any harm of storing hash($email) instead of $email You're gaining privacy over usability since you will not be able to send an email to all users at the same time. Collision will be your biggest problem here. I am assuming you are using a collision-almost-free hashing function to avoid collision (e.g. sha512)

If I retain IP addresses for logging purposes and link IPs to accounts, will a hacker be able to match the IPs elsewhere and work out/guess many emails anyway? Is a large list of user IPs valuable to anyone?

A hacker who is on-path and doing man-in-the-middle CAN match accounts with IPs by simply sniffing the network packets. He/she can even hijack these accounts if you use constant cookies for sessions.

Think about a situation when you have mutiple accounts coming from the same network (same IP) The IP address of each client will not be different.

Improve this answer
  • Thanks, yes I'll be using a "collision free" function. – Numeron Jun 5 '14 at 1:25
  • Great. I don't think using that would reduce your over-all performance since you're using it to hash emails, which is a very short string :) Good luck! – AK_ Jun 5 '14 at 7:55

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.