2

Assume the following example:

I have an online service where user can register and enter personal data. Now I want to encrypt these data. I have a private key Pr1 and public key Pu1.

  1. User logs in with password at my online service
    • Convert login password to fit a private key format = Pr2
    • Get public key Pu2 from Pr2
  2. User enters data to store them online in the database
  3. Encrypt user entered data with Pu1 and add --recipient Pu2 like Encryption with multiple different keys?
  4. Now I can copy the encrypted data from the online database to my local machine and decrypt the data with my local Pr1
  5. Users can decrypt their already entered data online using their normal password which is converted to their Pr2 every time when they log in (step 2a) but is valid the entire session

With that approach no data can be decrypted even if an attacker has access to my server with all files and the database, right? Sure, a brute force attack is possible but it should take some time as for every try a private key needs to be computed. But no private key is stored online or needs to be exchanged. So this should be pretty save.

Here the question: If this approach is secure and practicable, then there must be already something similar or better out there which has these functionalities and uses some nice security standards. What is it?

Community
  • 1
  • 1
justjulian
  • 115
  • 9

1 Answers1

0

A bunch of seemingly random thoughts re: why this doesn't tend to be how people do this...

First, for multiple user access. Typically systems I have seen that want to let two users access something with their own creds, but only protect the thing one time, is to create a key to protect the content, then protect that key with multiple credentials and store the key in this form many times. That is to say, you store the key next tot he item itself, but the key is stored N times,once for each accessor. If I grant you access, my cred is used to decrypt the key, then it is stored again with your materials.

Along the same multi-user lines, the "grant access" flow is problematic. The scheme you suggest above requires that in order for me to grant you access, the system needs to have my credential (to validate I am who I say I am & have the key in hand) plus your key (to give you access) at the same moment in time. This is pretty problematic in the real world.

This scheme does not afford the user a "forgot my password" experience. Lost password -> lost key.

This scheme assumes users pick good passwords.

This scheme means that two users with the same password have the same key.

You assert that theft of DB isn't an issue a they would have to compute all of the passwords (which means downstream keys) but in practice this isn't too hard to do, nor too expensive. And I just need to compute Password123 once and then can scan the entire db for it.

Hope this helps.

Eric Fleischman
  • 1,168
  • 6
  • 8
  • thanks for your thoughts! very helpful. i see the problems with my scheme now. could you please link a resource for your first point? so that i can read further information about it. it sounds very interesting – justjulian Sep 12 '12 at 20:17
  • I don't know of a general purpose link, but I believe EFS roughly works this way as an example (though with some of the holes filled :)): http://en.wikipedia.org/wiki/Encrypting_File_System – Eric Fleischman Sep 13 '12 at 01:15