Gurusachin
Gurusachin

Reputation: 3

secured way of sending a data stored in mysql from one person to other

I am writing a webapp using PHP and MySql. User A will post their password to the database, and PHP file of User B should access the password. User A specifies the duration of access of the password, which is stored in the database. After the completion of the duration the record in the table gets deleted automatically, so the PHP file of User B can't access it anymore.

Now what I am wondering is what is the best and secured way of storing the password in the table during the stipulated time duration, so that when the database is compromised the attacker cant get to know the password.

Upvotes: 0

Views: 50

Answers (1)

deceze
deceze

Reputation: 522042

For the data to be safe from attackers attacking your server, you must not be able to decrypt the data. If you (your server) can decrypt the data, you can assume an attacker can too having successfully broken into your server.

This means you need to encrypt the data and keep the necessary secret to decrypt it off your server entirely. The most sensible thing that comes to mind is obviously to let the user keep the secret.

A good scheme would probably be this:

  • generate a public/private key pair for each user, using the user's password to lock the private key
  • store both keys on your server
  • when user A sends something to user B, encrypt the data using user B's public key; the data is now only decryptable using user B's private key, which is locked using user B's password, which you don't have
  • when user B wants to retrieve the data, ask for/use his password to unlock his private key to decrypt the data
  • never store a password or the plaintext data anywhere on your server

The biggest problem with this is usability, since if you never store the user's password anywhere, you may have to ask him quite often for it. The other thing is that you should really know what you're doing here. Even having the password temporarily in memory can lead to breaches, not to mention that this whole thing can be really tricky to implement and is easy to get wrong if you don't understand all the concepts involved perfectly.

You could move the entire en- and decryption process to the client, so your server is never handling plain passwords or plaintext data. How feasible this is depends on your exact use case.

Upvotes: 1

Related Questions