0

I'm building a simple web site in which the user can upload pieces of text (notes). A note will have a flag "private" and, in case of true, I'd like to encrypt it so that not even me (who can access the database) is able to read the private note. I know encryptions are made through a key, and the best key I can think of now for this purpose is the user password. Obviously the password is hashed into the database but I could save it during the login in $_SESSION.

Is it a good idea?

For example, in cryptobin.org the user is asked to input a password, but in my site the already signed up user inserts the password at login and I don't want to ask again something new everytime he will upload his note and, I repeat, I need all this because I want to protect his notes from me.

Probably it's not very clear to me how encryption works; in 0bin.net it's claimed that the pastes are encrypted, but no key is asked. Can you please explain this?

user3621272
  • 165
  • 1
  • 6
  • 1
    You could (should) explore PHP encryption, learn about `key`, `iv`, start at http://php.net/manual/en/function.mcrypt-encrypt.php . For your project, say, `key` and `iv` could be static per user, but random like salt. – DeDee Sep 01 '15 at 11:36
  • 1
    Saving the user's password: not a good idea. You could do the encryption client-side, so at least the password does not leave the browser. – Thilo Sep 01 '15 at 11:38
  • @DeDee: but then the service operator could decrypt the user's messages. – Thilo Sep 01 '15 at 11:38
  • First you need two way (encrypt and then decrypt it). You shouldn't use password, but you can use parts of password. Like first and third letter, last letter, etc. – web2students.com Sep 01 '15 at 11:41
  • 2
    There is a "how it works" section for 0bin: https://github.com/sametmax/0bin Essentially: browser generates random key, key is put in "hash" part of the URL (which is not sent to the server), you can decrypt if you have the full URL only – Thilo Sep 01 '15 at 11:42
  • possible duplicate of [How to encrypt/decrypt data in php?](http://stackoverflow.com/questions/10916284/how-to-encrypt-decrypt-data-in-php) – Suhail Gupta Sep 01 '15 at 11:44
  • 3
    @web2students.com How does that help in any way? – deceze Sep 01 '15 at 11:54
  • @Thilo True, though in every scenario where both encrypted data and decrypting key/iv/whatever is stored in accessible location one person can decrypt it. The true solution to that is what ProtonMail did, users have second password to decrypt emails and it happens in their browsers, frontend script processes decryption. – DeDee Sep 01 '15 at 12:04
  • Using the password prevents the user from sharing the message, though. If it is just a one-off key, you can share the key/message with other people. – Thilo Sep 01 '15 at 12:09
  • Thank you very much. Everything you said was precious information. – user3621272 Sep 01 '15 at 12:13

1 Answers1

2

Keyed encryption is based on the premise of having a secret.

plaintext + algorithm + secret → cipher text
cipher text + algorithm + secret → plaintext

You provide the algorithm, the plaintext/cipher text is the subject of interest, and the party which holds the secret has the final piece of the puzzle and thereby the ultimate power.

From this perspective the user's password is a great choice, because only the user should know it and nobody else. In practice this depends on you really not having access to this password. If you store the password server-side, then obviously you have the password and could use it to decrypt the cipher text if you so chose.

Now, what you're proposing is a temporary storage of the password in the session. That's fine, but then it becomes about risk assessment. Who could get the password from the session? Hopefully nobody except you, unless your server is compromised. That still leaves you with a temporary opportunity to decrypt the cipher text yourself if you so chose. Also, keeping the plaintext password around in any form raises the chance of it being exfiltrated to somewhere (server logs, memory dumps, etc.).

If you're being trusted with handling a secret, you need to secure everything that ever comes in contact with that secret.

It's not infeasible, but depending on how serious you are about this, how sensitive the information you're protecting is, and how many possible attack scenarios you want to prevent, this can get rather complex and goes all the way to the physical security of the servers your code is running on.

An alternative is to do all encryption client side (in native app, or Javascript in the browser), which removes a lot of responsibility from the server. It opens new problems (you now need to ensure your Javascript cannot be tampered with), but those are easier to manage.

@Thilo summaries well how 0bin works. The randomly generated secret is part of the generated URL, is not stored on the server at all, and all encryption and decryption is happening in the browser.

Community
  • 1
  • 1
deceze
  • 510,633
  • 85
  • 743
  • 889
  • 1
    "which removes a lot of responsibility from the server". That seems to be the point of 0bin. Their FAQ clearly states that they don't really care about key management by the client, all they want is to protect the server from legal issues surrounding having to store sensitive data in a form that might be stolen from them or that they could be forced to recover. – Thilo Sep 01 '15 at 12:08
  • Right. If you can relegate the server to just store blobs of random gibberish, you've removed a lot of attack points. – deceze Sep 01 '15 at 12:10
  • ... at least from yourself :-) – Thilo Sep 01 '15 at 12:11
  • The private note can't be shared, but an "unlisted" can (like pastebin). Anyway, I have decided to save the password into the $_SESSION; if the user trusts me I won't save permanently the password somewhere during the login/signup for malicious purposes, he can trust me that I won't echo the password anywhere. I'm also conscious that, as you explained, that could not be the only problem about this approach, but my site is more an exercise, not made to store critical content. – user3621272 Sep 02 '15 at 12:49