0

I would like to make a key/string/token encrypted string to send it to the user via email.

This encrypted KEY would have encrypted data (resource id) and would be stored in the database along with valid column. It is meant to be used only once, and after use the key would become invalid.

Upon user entering the key on a form the server would decrypt the key, find the resource (based on data inside key) and create an access token (for authorization) for user. The key will become invalid at the end!

This is all to avoid account creation as users are not going to utilize the resources more than once and I am not saving the data. Also, the idea is to limit the use of a resource to users that I pick and send them a key.

Is this the right system?

P.s The code is more or less irrelevant as I am asking about the process and security aspect

1 Answer 1

1

Your scheme isn't wrong, but it's very cumbersome for the simple goal you're trying to achieve, and it has some problems.

If you want to give users access to a resource, the simplest approach is to directly send them access tokens. The workflow would be as follows:

  • The server generates a random token, hashes it (with a general-purpose algorithm like SHA-256, no need for bcrypt/scrypt/Argon2 here) and stores the hash together with a reference to the resource in the database. The purpose of hashing is to avoid leaking all tokens in case of a database breach. It's also a good idea to store a timestamp, so that you can find out how old the token is and possibly enforce an expiration date.
  • The server sends the plaintext token to the user by e-mail.
  • When the user enters the token (or simply clicks on a link), you hash it and then look up the corresponding resource in the database.

There's no need for and encryption here, because the token by itself is meaningless and doesn't have to be hidden from the legitimate user (just everybody else).

The problems of your approach are:

  • You have to keep the encryption key secret. If it's leaked, this means users who know the key can decrypt and change the resource ID they've received. Depending on whether other resource IDs can be guessed, it might be possible to access those resources.
  • To revoke access to the resource, you have to disable the entire resource. This is a problem if, for example, at some point you find out that you want to give more than one person access to a resource. Or if you no longer want a particular user to have access to the resource while keeping the resource itself intact.
  • In your scheme, the encrypted resource IDs have no defined expiration date. Unless the user quickly accesses the resource and thereby invalidates it, the resource ID can remain in the inbox and still be valid for a very long time. Since unencrypted e-mail isn't a particularly secure medium, this is a risk. Unencrypted e-mails can leak, and e-mail accounts can get compromised at some point. In that case, there's a good chance the attacker can access the resource, maybe weeks, months or years after the e-mail has been sent.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .