Webmasters: You should always hash and salt your password list

Every so often I register with some new website or service and am horrified to receive an email confirmation that shows my password in plaintext.  Let’s consider some of the reasons why that’s A Bad Thing™.

1. If the website can send my password in plaintext (and typically include my username), someone else can see it and can gain joint access or exclusive access to my account.  Seriously, people:   Email is not secure unless encrypted, and almost nobody encrypts email these days.
2. If the website can send my password in plaintext, it almost certainly means that they are storing my password in plaintext.  Why would that be a bad thing, you ask?  Because not if but when a website gets hacked, the attacker can collect the passwords and impersonate the users or gain exclusive access to their accounts.
3. If the website stores my password in plaintext, they are probably putting it verbatim in a database field that recognizes certain characters as delimiters.  That places limits on the characters that I am allowed to use in my password (i.e. no spaces, no punctuation, …), which in turn reduces the strength—more formally, the entropy—of the passwords, and forces me to adapt my strong passwords to arbitrary rules.

With those considerations in mind:

1. Passwords should always be stored as hashes, also known as message digests.  This means that if an attacker compromises a website, they will not know what the original passwords were, though they may be able to impersonate users by using the hashed passwords.
2. Password hashes should also be salted with some identifier unique to that site, so that the same password produces a different hash from one site to another.  That means that a hash obtained on one site frequented by a particular user doesn’t help the attacker break into other sites for that same user (i.e. Google and Facebook).  This is what LinkedIn failed to do.