CODEWITHSUNDEEP
securityencryptionhashpasswords
Pau C
Pau C

Reputation: 783

Password Manager security

I'm coding a Password Manager for school and I'd like to know what should I improve or change. This is how it works:

To save the main password I create a file with a the password hashed with PBKDF2 512bytes output on top of SHA3-512. Using a random 128byte salt and a random number of iterations(which range it's the point of the question). All this data is saved on the file and scrambled using a pseudo-random Generator which seed is generated from the password itself (this way is harder to get the salt).

Then the file where the passwords are stored is Encrypted with AES 256, and the salt is generated from the user PC pseudo unique identifiers.

When the user chooses a password, the requirements are: Minimum 10 characters and not to be on the 100.000 most used passwords list (I got this list somewhere on the internet, might be outdated)

Well, I've questions, which are: What is the current standard iteration count for PBKDF2? Is PBKDF2 the output byte length important? I mean more length = more security?

And would a longer salt give me extra security?

The salt its saved on the file so it's "possible" to retrieve it , is there a better way to "hide" it than just scrambling the bytes?

Upvotes: 0

Views: 291

Answers (1)

Artjom B.
Artjom B.

Reputation: 61932

What is the current standard iteration count for PBKDF2?

There is none. The iteration count is not specified in a standards document. Use as many as possible without annoying the user. Keep in mind that this is usually determined by setting a target amount of time (for the actual hardware) such as 0.1 seconds up to 2 seconds and then trying multiple iteration counts in order to get closer to that mark (use binary search if you don't have a PBKDF2 implementation with logging which you can abort).

Of course, you should not define the number of iterations yourself, but rather let the user define it (Keepass does it like that). It is basically a benchmark with a target time.

The number of iterations is the main driver of security in PBKDF2 and is basically the slowdown for attackers provided that you don't request more output that the output size of the underlying hash function.

Is PBKDF2 the output byte length important? I mean more length = more security?

Yes, it is important, but only up to a point. If the output is small, say 64 bit, then it is easier to find a collision (some input that hashes to the same output) than a hash with a 128 bit output. This is why short hash functions should not be used nowadays. Anything that outputs 256 bit is fine. Note that SHA-512 can be implemented such that it runs faster on 64-bit platforms that SHA-256.

And would a longer salt give me extra security?

No, a salt is there to distinguish between multiple uses of the same password or key. Using the same salt would enable an attacker who stole the password database to brute-force all users' passwords at the same time and not one after the other. Having a 64 bit or 128 bit salt is sufficient enough to prevent the generation of rainbow tables (but a large iterations count basically takes care of that).

Having a salt at all is only relevant if you think that the attacker can run an off-line brute-force attack on multiple password containers of your users at the same time (thus breaking into multiple user machine beforehand).

The salt its saved on the file so it's "possible" to retrieve it, is there a better way to "hide" it than just scrambling the bytes?

No, the salt is not supposed to be secret. Its only purpose is the randomization of the output even and especially when the same password was used. Simply generate a random salt from a good randomness source and store it as is. Of course, if you use authenticated encryption (AES-GCM or similar), then you should pass the salt as additional authenticated data in order to detect (malicious) manipulation.

Helpful resource: pbkdf-2 tag on Cryptography.

Upvotes: 2

Related Questions