Rfc2898DeriveBytes - password length
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 &mdash; 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.