Rfc2898DeriveBytes - password length

Question

Trying to find related answer for a long time, but not convinced yet.

What I am trying is to encrypt using RijndaelManaged. To create Key, I am passing password, salt and iteration to Rfc2898DeriveBytes.

I was thinking to add constant if user entered password is below specific length before passing it to Rfc2898DeriveBytes.

So far what I found that adding constant will not add any benefit to security. Let suppose attacker get an access to database containing encrypted data along with salt, but not to constant will give him a bit harder time. Although in the end he will find that constant.

Or it is "really and extremely" safe to pass any length password to Rfc2898DeriveBytes without getting worried?

Does passing shorter or lengthier password affect key derivation process in term of which one is better and most recommended?

So far what I know that random salt and more iteration is important.

Following is the code, should I remove adding constant to password or keep it?

(Note: password length restriction to user is not applied at GUI, user can pass 1 character or even more than 10 characters)

string constant = "AnyConstantToMakePasswordBigger";

if (password.Length < 8)
{
  password = password + constant;
}

RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] salt = new byte[8];
rng.GetBytes(salt);
Rfc2898DeriveBytes derivedKey = new Rfc2898DeriveBytes(password, salt, 1000);
aes.Key = derivedKey.GetBytes(keyLength);
.....

Welcoming any positive or negative comment and responses.

Answer 1

There's no advantage to padding short passwords with a (non-secret) constant.

• It doesn't make the password hashes any harder to crack by brute force guesswork: if an attacker can program a computer to try common passwords like abc, 123, swordfish, etc. (and they can, with very little effort), they can also just as easily make it try abcAnyConstantToMakePasswordBigger, 123AnyConstantToMakePasswordBigger, swordfishAnyConstantToMakePasswordBigger and so on.

• It doesn't make the hashing algorithm (PBKDF2-HMAC-SHA1, according to CodesInChaos) any harder to break (not that anyone knows how to break it anyway).

  In fact, technically, the HMAC-SHA1 algorithm does internally pad the password to 512 bits (= 64 bytes); it just happens to pad it with null bytes (and then XOR each byte with 0x36 for the inner hash calculation, and 0x5C for the outer one). Note that, given the way SHA-1 and pretty much any other modern cryptographic hashes work, padding with null bytes is no more or less secure than any other fixed padding.

Padding the password with a secret constant (often called "pepper"), however, can improve security in some scenarios — specifically, if an attacker gains access to the password database (e.g. through an SQL injection vulnerability), but not to wherever the secret constant is stored. However, if you want to do this, you should add the pepper to all passwords, not just to short ones.