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?

Luis Sieira
  • 103
  • 5
  • what happens when the user changes their password? – schroeder Aug 27 '15 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 '15 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 '15 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 '15 at 23:04
  • How could Billy get the key? It's supposed to stay just in the server's working memory... On the other hand, I was thinking about some kind of password wallet, like in an unified mail inbox and so... If the attacker gets the user password, he can access everything. With the server key, he'd access the hash of the active sessions (and then the data). – Luis Sieira Aug 27 '15 at 23:06
  • @LuisSieira chocolate bar, heartbleed, malware infection – oleksii Aug 27 '15 at 23:25
  • 1
    Your description mentions md5 but I don't see it in the main text. – JDługosz Aug 27 '15 at 23:51
  • @oleksii What's the chocolate bar a reference to? – David Zech Aug 27 '15 at 23:53
  • @DavidZech social engineering, bribes or insider attack. – oleksii Aug 28 '15 at 09:51

1 Answers1

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.

Nic Barker
  • 1,170
  • 7
  • 11