6

I'm working on a web app where was considering how to keep user's identities totally anonymous.

However I've come to the conclusion, there's not too much I can do - except concentrate on securing the database from being hacked.

Is this the general consensus here on StackOverflow or are there any methods I may have missed?

So I thought about:

  • A straight bcrypt hash and salt however this then leads to contacting the user for various reasons.
  • Password resets. I could save recovery question/answer but then of course the answers would need to be readable so that defeats things.
  • Another point was say they forgot those security questions or a username I had generated on registration. No way to link them to an account.
  • Also what came to mind (assuming I conquered the above) restricting duplicate users. If I hashed/salted searching through would be quite 'heavy' on processing? I could simply keep a long list of emails used but then the issue again linking that to an existing account?

Interested to hear your thoughts.

Thanks.

userMod2
  • 8,312
  • 13
  • 63
  • 115
  • Am I correct in thinking you want users to log in with email/password and then you want your system to encrypt all their personal info so they are unidentifiable? – Aaron Franco Mar 28 '16 at 15:43
  • You could consider using Sqrl for user validation. https://www.grc.com/sqrl/sqrl.htm . The system uses public key crypto to sign a users session instead of a password. You identify the user based on a key derived from a client secret. This way you don't have to wory about loosing passwords. since there are no passwords to be lost. I haven't tried it, but from listening to Steve Gibson on his podcast it seems well thougth out. – Espen Brekke Mar 30 '16 at 06:55
  • @AaronFranco yes thats correct. – userMod2 Mar 30 '16 at 10:10
  • I'm interested to hear how this project is going? @userMod2 – 13aal Apr 25 '16 at 21:38
  • With modern tech, you may be able to achieve this with Blockchain. – Aaron Franco Jan 11 '18 at 16:25

2 Answers2

3

I think a scenario you describe could be possible. You could give the user a decryption token when they login. The token could be assigned to a variable in the app on the front-end, so if they leave the site or page, the token would be lost and they would have to login again.

Using the token, the app can decrypt encrypted data coming from the server. So, all data could be encrypted using the token. Then, if password changes are required, you could generate a new token when you generate a new password, and your server would have to decrypt then re-encrypt all their data using the new token. In this way, you could have all your server files, code, and databases encrypted while using SSL so all data would be anonymous until it reaches the user for display. The user logging in would be the only way to get the token to decrypt any data coming from the server. This would reduce server performance considerably.

This technique is used by Atmel in their microchips to have 100% encryption from device to cloud. Which makes sense for a chip because a user doesn't have to interact with it visually. In the case of a webapp, there needs to be some way to decrypt the data for display. Which limits the possibilities.

Here are a couple of links that might be useful in doing this: https://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services https://www.fourmilab.ch/javascrypt/javascrypt.html

Here is a link to the Atmel chip that uses the above mentioned security method. http://www.atmel.com/products/security-ics/cryptoauthentication/

Aaron Franco
  • 1,560
  • 1
  • 14
  • 19
  • Interesting - can see how this would work however the user would now have to remember a token - rather than their email/mobile. I guess that token could be made into a simple one? – userMod2 Mar 30 '16 at 23:37
  • The user never sees the token. They only use Email & Password, to fetch the token from your server. The token would be the only thing sent from the server that wouldn't be encrypted. – Aaron Franco Mar 30 '16 at 23:37
  • Ah ok - but on the server side/DB there is still a link from the token to the user right? – userMod2 Mar 31 '16 at 09:09
  • The user data is entirely encrypted, so the token is a vague reference to an initial hash created on the client with email/password. Sending that hash would be the only way to retrieve the token. – Aaron Franco Mar 31 '16 at 10:19
2

Well first, the only way to be completely anonymous is to never go online. Nothing, and I do mean nothing, is completely secured. Any hash, encryption, DB, etc can be cracked. If a malicious "hacker" really wants the information they will find a way to get it no matter how hard you try.

Now having said that, what you describe is possible, for example look at Tor, proxies, VPN, etc if you completely encrypt every bit of information that is taken from the user, then you are into something. This can however become an issue if something goes wrong, for example say you triple hash, and multi-salt all the hashes and come across a problem where you need to decrypt the users information (for sake of argument, the FBI requests it) a single salted hash with an MD5 encryption can take anywhere from 2-5 hours to decrypt/crack. You've encrypted all the information including IP, username, password, email, name, etc now you're looking at potentially more then a day to decrypt a single user.

However, you could do something along the lines of making an encrypted tunnel into your browser that the user HAS TO access in order to run the browser (kind of like a VPN), then from there throw proxies in the browser URL to further the anomity. That way the user is in an encrypted tunnel with a different IP, and using an IP other then the one given through the tunnel. You could even go as far as hopping IPs every so often, and changing proxies.

Now let's get to securing the database, i would suggest multi salting hashes, securing them with a pass phrase, and deleting the pass phrase from the computer that the database is on. This can also prove troublesome if you need to access the hashes for decryption.

I say go for it, the worst that's going to happen is you'll have a slight trace of the user. But remember, if you successfully create this, people with malicious intent will try to exploit it, just to see if they can.

13aal
  • 1,634
  • 1
  • 21
  • 47