[riskable]

No. Time to start using proper password hashing algorithms (e.g. scrypt) with added protections such as requiring n rounds of hashing.

Tip: To require 65535 rounds of hashing on a Debian or Ubuntu system just run this:

    sed -i -e 's/sha512$/sha512 rounds=65535\n/g' /etc/pam.d/common-password

(Note: Assumes you're still using the default hashing SHA-512 hashing algorithm)

[distances]

There was an earlier discussion about KeePassX, where I mentioned I used 10 million rounds of the AES encryption. Someone commented that it doesn't really add much additional strength.

I'm not familiar enough with the topic to understand why it would be so. I wonder if there is some basis for that claim?

[dogma1138]

[Disclaimer: This is assuming you aren't talking about key schedule, since you use odd terminology, and even then how do you get to 10M rounds is beyond me] Because you use the same key, not to mention the same IV most likely, unless you are storing 10M IV's some where... Doing 10M rounds of AES is just stupid(ly) expensive.

Also verifying the decryption with 10M rounds, means, 10M CRC checks, and if you are using it on a non-ECC system there is a good chance that many attempt to decrypt anything stored like that will fail due to single bit errors.

[Freaky]

He's talking about KeePass's key derivation algorithm - SHA256 the password, make a random 256 bit key, AES-encrypt the hash N times using the key, and SHA256 the result.

10 million iterations is about a second of work on a typical desktop.

[mioelnir]

Typical being AESNI accelerated?

[distances]

I don't have expertise on the subject as was probably already evident. For me it's a setting in KeePassX, and that's it.

With the 10 million config, opening the password database takes just a bit over a second on i7-4800MQ which should come with AES-NI. I can't say if the software is using that or not.

On my Android it takes 4 seconds, so very acceptable still.