Your method for storing the passwords server-side is actually not very secure. Hashing the passwords without a unique salt is not a secure way to store them.
For one thing, every user with the password of 'secret' will have the same hash in your database. Secondly, if I were to steal all of your password hashes, I would just have to compute sha2 of every 6-8 (or whatever password length you are using) character string. With a 32 character salt, I would have to compute a sha2 of every 38-40 character string, making my job a more time consuming.
The thing with a salt is that - would you include the salt in the Javascript hashing system? like sha2(nonce + sha2(password + hash)) ? If so, then the salt isn't really that useful - you can then just compute sha2 of 6-8 letters + salt.
The only usefulness of the salt is if somebody steals your database and uses a rainbow table to try to get the passwords. If you don't have salts for each users, then a pre-generated rainbow table for sha1 based on common passwords is going to be very efficient at getting the passwords for each account.
If you use salt however, you are protected from the use of pre-generated tables since the attacker has to brute force all the combinations for each user. If you use sha1 or md5 it's still not too secure since sha1 and md5 are fast to calculate and getting faster with this : http://nsa.unaligned.org/hw.php
Of course, the big problem with the javascript way explained here is that you send sha2(nounce + sha2(password+salt))
This means, that anybody who get access to the database can send
sha2(nounce + hash_from_database)
So basically in this case using salt in the database prevent people from getting the password too easily (so it sorts protects the attacker from getting a password associated with an email address that he could try later on paypal), but it doesn't protect the account in any way...
And for those who think that it's unlikely for anybody to get access to the database, it happened to the reddit guys...
You can't have it both ways. If you are hashing the password before it is sent from the client to the server, you need the raw password on the server side.
(Assuming you are concatenating it with a server-provided random value before the hashing.)
You're assuming they're using a secure challenge response protocol. They're not. They're sending password-equivalent hashes over the wire, so they can say they're not sending passwords.
You'd be right to point out that this is a lot of silly acrobatics to go through to avoid a single SSL login page.
For one thing, every user with the password of 'secret' will have the same hash in your database. Secondly, if I were to steal all of your password hashes, I would just have to compute sha2 of every 6-8 (or whatever password length you are using) character string. With a 32 character salt, I would have to compute a sha2 of every 38-40 character string, making my job a more time consuming.