More to the topic, I wonder if they're looking for more volunteers now.

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