I've been reading about password storage, and have basically found 2 commonly used techniques.
- encrypting all of the passwords stored with a single key.
- Using hashes
Is there a flaw in storing the password "encrypted by itself", i.e. encrypting a txt which says password1 with the password password1 without storing it unencrypted, and when a user wants to log in, decrypt, compare and grant access (or not)?
I am not very literate in this topic, so, can somebody enlighten me?
This has three weaknesses over using hashes with salt.
- It's vulnerable to a dictionary attack: anyone who gets hold of your password file can try common passwords (like
password1) and see if they self-encrypt to the stored value. Worse, depending on how you do the encryption, this could be done offline, before getting hold of the password file, with the results stored in a lookup table so that when someone gets your file then it can be cracked instantaneously.
- It requires a variable amount of storage, which is less database-friendly. A hash has a fixed-length output, but encryption length varies with the length of the input.
- It can't easily be iterated. The really proper way to do it is to use a hash with salt, but to iterate the function a few thousand times (i.e., hash, then hash again, then hash again...). This means that verifying a password can still be done in a second or two (depending on how many times you hash), which is usually not problematic; but it's much, much harder to crack because every password you try now needs to be hashed a few thousand times. There's no obvious way of doing that here, because encryption will probably increase the length (when you add in initialisation vectors and so on).
Really, there's no reason at all to do this, when there's a solid and well-established technique that does it much better.
