…so why do they exist?
For each of your online accounts there is a record in a database (just like a row in excel) at the company that reads like this:
| Database Row | passwordHash | Account Id | |
| 100 | mary@email.com | 7a2ccf251ecb20b2b84ce0e3c3f72a29 | #1000 |
No self-respecting company ever actually knows or stores your password. It hides that password – even from itself – with a one-way encryption technique called hashing.
Hashing is a topic on its own, but, for now those details don’t really matter[1]. Let's just describe it as a consistent way of scrambling your original plaintext in such a way that nobody can figure out the original plaintext from the hashed mess. Can you tell Mary’s plaintext from the hash it generated in the table above?
Back on the company web page, the next time Mary enters her email address along with her chosen password, Secure, the server finds row 100 (using the email address as selector) and runs that same hash algorithm[2] against the plaintext sent to them by Mary, i.e. Secure, and if the result is exactly 7a2ccf251ecb20b2b84ce0e3c3f72a29 (as in the above table) then it opens up the details of account #1000 [3].
Without a password column in the database table the alternative process would be to open up account #1000 to anyone entering mary@email.com into the webform.
Authentication
Annoying, but useful then, our dreaded password serves as an authentication method.
[1] The design choices of the hashing approach (there are many) really do matter; just not for our purposes here.
[2] For what it’s worth, in this case, for simplicity, MD5.
[3] Anyone can make a hash; try it yourself: http://www.miraclesalad.com/webtools/md5.php