cengland0 (2/10/2012)
Generally companies require you to change your passwords every 30, 60, or 90 days so a brute force doesn't work in these cases either.
Two points here: The companies which do this so it to their own staff, not to their customers - so customer passwords have to be safe for a much longer time than the internal passwords to which these change frequencies apply. So something good enough to be safe for rather more than several years will be needed, unless the attitude to customer security changes.
Besides, the pasword I use for my most secure stuff is a couple of hundred characters long and I'm not going to create and learn to remember a new one of those every 90 days. I lost my PGP keys way back when because I was persuaded to change my passphrase regularly - and of course couldn't even revoke them, so they are still on public servers somewhere, since only someone who knows them can revoke them.
Sending the clear text from the application to the database is dangerous because the trace command can pick that up and be captured by anyone with full access to the database. Having it hashed in the application makes it so only the salt and hashedpassword values are sent to the database and they are no longer clear text at that point. You can look in the table or do whatever trace command you want and you will not be able to see the user's original password anywhere in the database.
One can perfectly well use encryption (preferably asymmetric, of course) between the database and the app, and do the hashing in the database - or one could if the database were capable of doing the hashing; for long term high security, SQL Server currently isn't.
The idea that passwords have to be passed to the database in unencrypted form is just plain false, and is not a reason for not doing the hashing in the database. The real reason is the SQL Server doesn't have the required hash functions. SQLS 2012 will improve things a little with the addition of SHA2-256 and SHA2-512 to the hashbytes repertoire, but it's still missing the crucial thing: a seriously slow hash; and that means that it can't do the hashing needed for lasting high security.
Of course banks and investment managers and so on providing customers with a web interface don't have a security model that delivers either high security or lasting security - they impose nonsense like a password must be alphanumeric (no symbols) and/or the alpha part of the password is case insensitive and/or the password must be between 6 and 12 characters, they rubbish the vulnerabilities in their security models that are demonstrated by competent security experts (look at how VISA and MasterCard treat the Cambridge University security research team), some of them even hold passwords in clear.
Tom