>>You shouldn't really be storing the password itself (or even the encrypted password), but rather a hash of the password. And ideally another field for the salt. So if you used something like SHA1 you'd need a field that could store 160 bits (SHA1 is fixed size, regardless of the input string). I'd probably use something like a GUID for the salt (each user records gets its own unique salt), then store HASH(Salt + Password) in the database. Now the user can enter any length password they like and your code will still work.
>>
>>As far as password policies go, I usually just use whatever password KeePass automatically generates; it appears it's a 20 character string with upper/lower case, numbers, and special characters. Or if it's a password I really need to remember I tend to use pass phrases with odd case changes and/or alt. characters.
>
>Thanks

Hmm...so it appears SHA1 is falling out of favor. SHA 2 (w/512 bit digest) is probably a better choice at this point.

Here's an interesting article about it:

http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

Still, it seems like maybe performing some translation or calculation on the salt before adding it to the password should help mitigate this somewhat. Just having the salt and password hash wouldn't be enough - you'd also need to know what the transform looked like on the salt (although I'd bet that if you could recover a few of them the transform would probably be easy to recover if you're not careful). Shrug - this encryption/hashing stuff is hard.