Good practice is not to unnecessarily restrict password length, so that appropriately-long passphrases (perhaps 35-45 chars for 6/7 dicewords) can be used. (See e.g. Should I have a maximum password length? where a maximum of 1K is suggested, to protect against DoS without restricting users' ability to set long passwords.)
bcrypt is also commonly recommended (see e.g. Do any security experts recommend bcrypt for password storage?, http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html)
It is also recommended to use a salt (random, and stored with the password hash) -- I believe 32-bits (4 characters) is often recommended. (I understand the salt-size rationale to be "enough that the number of combinations is much bigger than the number of user records AND is enough to make rainbow tables infeasibly large" -- 16 bits is enough for the second part but may not be enough for the first.)
But AIUI bcrypt only hashes 55 bytes -- with 4 chars for the salt that leaves 51 for the password.
I'm guessing that we shouldn't just bcrypt(left(password,51)) and ignore the last characters.
Should we just limit users to 50 characters in their password (enough for nearly everyone, but not definitely enough)?
Should we use something like bcrypt(sha256(salt+password)) instead, and allow up to 1K characters? Or does the addition of the sha256 (or sha512?) step reduce the overall security somehow?
Do scrypt or PBKDF2 have similar length restrictions?
(The last question is just for interest, really -- I realise that the space-hardness/FPGA-resistance, and relative newness of scrypt, and the GPGPU-resistance of bcrypt compared with PBKDF2 are far more important considerations in deciding which hash to use.)