0

I have an authentication system, where the passwords are stored with bcrypt hash (node passport module).

My server generates a random key (128bytes) at startup.

Whenever a user logs in, the server calculates the SHA-1 of his password (right after a successful authentication), encrypts it using AES with the randomly generated key, and temporarely stores it in a database, along with the other hash.

This SHA-1 sum will be used as an AES key to encrypt/decrypt user information that will be stored in the same database.

Is this method safe?

Improve this question
9
  • what happens when the user changes their password?
    – schroeder ♦
    Aug 27, 2015 at 22:23
  • He is requested to provide the old one. Then everything is decrypted/recrypted. There should not be so much information; and the user is supposed to be able to provide this data again if he forgets the old password and has to renew it via his e-mail
    – Luis Sieira
    Aug 27, 2015 at 22:42
  • 1
    I can think of an attack when Billy gets a key from the server and a database dump. That's enough to render such defence useless. A better way would be to design a system where a server has no ability to decrypt data - only user.
    – oleksii
    Aug 27, 2015 at 22:57
  • @oleksii if the business case is for the server to never have access to that data, sure, but we don't know what the requirements are.
    – schroeder ♦
    Aug 27, 2015 at 23:04
  • 1
    Your description mentions md5 but I don't see it in the main text.
    – JDługosz
    Aug 27, 2015 at 23:51

1 Answer 1

Reset to default
1

The general response to this is correct - if your server is storing a copy of a key that's used to encrypt something in memory, there is a chance that an exploit will allow it to be stolen. (See: heartbleed)

I think it's definitely worth asking in this case why you need to store a hash and an encrypted version of the password. I can see a system in which you're logging into another service on a user's behalf and need their password, but since you mention:

and temporarely stores it in a database, along with the other hash

I suspect this is not the case. There are very strong arguments for not using a reversible algorithm to store passwords in a web database, and I would like to understand your reasoning for wanting to do so.

Improve this answer

You must log in to answer this question.

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