It's really a shame there's so little overlap between the security people and the people creating non-security standards.
Security is all in the defaults. It's a crying shame that whomever came up with type=password for HTML input tags didn't make it require an attribute holding the id of another field holding the salt, and have form submission submit something like base64(md5_hmac(password, hostname + ' ' + salt)) (md5 was considered good at the time) as the field's form value. All of the tutorials would have people using the username as the salt, which isn't good. However, we'd be in a much much better place than we are now if the easiest way to bumble your way through creating a login meant taking a salted hash of the password directly from the submitted form. We'd still have tons of data that could be stolen to authenticate to the same site, but at least the salted hashes would need to be cracked in order to use the stolen credentials to authenticate to any other host. Also, people would need to go out of their way to store plaintext passwords in databases.
Better yet, when it became clear that people were using forms for auth data because the browser's HTTP 401 response dialogs were ugly, they would have created a new HTML header tag to allow the page to specify the HTML element IDs of the username and password fields, so that a web browser could send an HTML login screen as the body of an HTTP 401 response.
Of course, HTTP basic auth should never have been allowed.
As it stands, we're in the crazy place where UI designers are forced to make security decisions that really should be shoved way down the stack and made transparent to them.
Edit: clarified the name used for 401 response dialogs
HTTP responses are incredibly difficult to work with. I was under the impression that a login form should return 200, as the HTML page that loaded was indeed returned OK. I can't find any documentation that actually says, and a lot of live websites don't seem to do one or the other consistently.
You are right though, HTTP basic auth should have always returned some sort of salted hash. It was probably only omitted for simplicity.
Security is all in the defaults. It's a crying shame that whomever came up with type=password for HTML input tags didn't make it require an attribute holding the id of another field holding the salt, and have form submission submit something like base64(md5_hmac(password, hostname + ' ' + salt)) (md5 was considered good at the time) as the field's form value. All of the tutorials would have people using the username as the salt, which isn't good. However, we'd be in a much much better place than we are now if the easiest way to bumble your way through creating a login meant taking a salted hash of the password directly from the submitted form. We'd still have tons of data that could be stolen to authenticate to the same site, but at least the salted hashes would need to be cracked in order to use the stolen credentials to authenticate to any other host. Also, people would need to go out of their way to store plaintext passwords in databases.
Better yet, when it became clear that people were using forms for auth data because the browser's HTTP 401 response dialogs were ugly, they would have created a new HTML header tag to allow the page to specify the HTML element IDs of the username and password fields, so that a web browser could send an HTML login screen as the body of an HTTP 401 response.
Of course, HTTP basic auth should never have been allowed.
As it stands, we're in the crazy place where UI designers are forced to make security decisions that really should be shoved way down the stack and made transparent to them.
Edit: clarified the name used for 401 response dialogs