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?

9
  • what happens when the user changes their password?
    – schroeder
    Commented 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 Commented 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
    Commented 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
    Commented Aug 27, 2015 at 23:04
  • 1
    Your description mentions md5 but I don't see it in the main text.
    – JDługosz
    Commented Aug 27, 2015 at 23:51

1 Answer 1

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.

You must log in to answer this question.

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