Let me start by stating that this is really my first foray into encryption.

I have written username/password systems, and such, and am familiar with salting and hashing passwords... but I have never really done anything with encryption.

I have an idea for a system that I want to build... and I have (what I believe to be) a clever solution for storing the user's data without knowing anything about them... but I am not sure if I am opening the door to some kind of "promise not to peek" flaw.

My idea is this: I want to be able to store encrypted information without knowing anything about the user.

The design in my head is this: the user sets up an account (username and password). An encrypted blob, keyed with the password, is created client-side (secret-key encryption via libsodium in JavaScript). The username is hashed (client-side... perhaps salted with the password?). This hash and the encrypted blob are sent to the server, where they are linked together in the database. When the user next logs in, the hash is sent to the server and the encrypted blob is sent back to the browser, where the password is used to decrypt the blob. All of this, obviously, happening over HTTPS.

Is there a flaw here? Am I overlooking something?

I want to be able to respond, even to a government subpoena, with "I don't know. And I can't find out."

Of course, malware on the client-end would be a problem... but I haven't been able to think of any way around that... and that isn't the issue I am trying to address right now. I just want to figure out a way to store customer information without know anything, at all, about my customers.

  • The payment question should either be removed or posted as a separate question, imho. Welcome to Security.SE! – dst Dec 20 '15 at 1:28
  • sorry about that... that was more a stream-of-consciousness aside than an actual question. – Nathan Pinkerton Dec 20 '15 at 1:40
  • Your system will offer no support for forgotten usernames or passwords. This is problematic. – Neil Smithline Dec 20 '15 at 2:07
  • 2
    You present a proposed solution without stating the problem you are trying to solve. This makes evaluating your proposal difficult. – Neil Smithline Dec 20 '15 at 2:10
  • I've edited for clarification – Nathan Pinkerton Dec 20 '15 at 2:18

For the sake of consistency I'll call the infrastructure operator (you) Bob, the client Alice, and the personalized government Mallory. This answer only describes a very simple attack for the government scenario, ignoring other aspects of your service.

The setting is as you describe: Bob operates infrastructure on which Alice stored an encrypted blob. Alice's access occurs through an application delivered by Bob via HTTPS.

Mallory has the resources to force Bob to cooperate in any way, and wishes to get access to the content of the encrypted blob stored on Bob's server.

To do so, Mallory changes the application Bob delivers via HTTPS in a way exposing the encryption keys (depending on Mallory's resources in some way that is not easily detectable - some months should be sufficient). Remember, Mallory is in possession of Bob's credentials, and thus can serve them properly. Mallory will receive the key the next time Alice uses Bob's service. Using the key, Mallory now decrypts the blob and does the happy dance.

The scenario is not unlikely, if Mallory really wants Alice's data.

  • Thanks for the feedback... I guess that I was hoping to avoid a situation where Mallory wants Alice's information, by not having a record that Alice has an account. Is there a way around this? Or am I shooting for something that is completely undoable? – Nathan Pinkerton Dec 20 '15 at 1:46
  • At least in America, I think it would take quite extreme circumstances for a government agency to be allowed to install malicious software on non-suspect computers. The example you mention was for server-side intrusion, not client-side. – Neil Smithline Dec 20 '15 at 2:06
  • @NeilSmithline Obviously, we can argue on whether the government is allowed to do so, but that is a completely different issue ;) - note that all it takes is to inject some JS into the server-side, it does not have to be installed (as in Alice's computer is permanently affected) - at least for lawyers I don't see why it should be handled differently. Also, remember that Alice is a high-value target in the scenario given. Everybody else is collateral damage (or could get filtered out in the unlikely event somebody actually cares). – dst Dec 20 '15 at 2:13
  • 2
    This theoretical vulnerability applies to every application. Theoretically speaking, there is no way to be 100% certain that you are completely secure in that aspect. If this is a legitimate threat, then personal (private) servers should be used to host the content and clients should use a strict set of manually installed CA certificates. Even then you'd still have to worry about the theoretical possibility of software manipulation. If everyone worried about all of these theoretical vulnerabilities nothing would ever be built to begin with. – Jonathan Gray Dec 20 '15 at 3:27
  • 1
    Why is this a problem @nathanpinkerton? You state you don't want to know anything about your customers, not that you want to be protected against measures such as these. Your requirements are still unclear to me. – Neil Smithline Dec 20 '15 at 6:34

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.