Some of us still remember "ye good old days," when computer users had to walk uphill both ways across campus, in the driving snow, to get to the central computer with their Fortran (real programmers obviously did not use sissy languages like Cobol) programs; the days before some misguided journalist co- opted the term hacker and made it equivalent to criminal and all who dabbled seriously in computers proudly called themselves hackers. In those days, passwords served a largely different purpose from what they do today. In those days, there were no attackers to speak of. Not only were the computers more or less physically secure (in the sense that they were not left laying around in airport terminals very often), but they were also so complicated to use that the bad guys probably would not have been able to do much had they actually been able to sit down in front of the green screens. Furthermore, there really was not all that much interesting information to be stolen. The main reason to even have separate user accounts was to separate users' data from each other, and to make the super user feel superior to all other users. The basic idea was that both Alice and Bob should be able to have a document with a particular name , but the thought that Alice would want to steal Bob's user account to go hack Citibank was not really a consideration. In those days, passwords were just that, words. They were short, consisted only of letters or sometimes even just of numbers , and they were stored in text files in clear text. When a user logged on, the password the user typed was simply compared to the stored one. Obfuscation of passwords in the password database was not universal until the late 1980s.
Eventually, bad guys showed up. It became clear that storing passwords in clear text was undesirable. For that reason, passwords were cryptographically "secured." In some cases, they were encrypted so that they could be decrypted for comparison during logon. More commonly, however, they were stored using some form of one-way function (OWF), such as a hash.
The process of hashing uses a cryptographic function to produce a deterministic fixed-length value for arbitrary input. The result of the function, the hash, is wholly dependent on the input and will always be the same for the same input. There are many different hashing functions, and, although there are weaknesses in many of them, most hashing functions are what are known as one-way functions (OWFs). An OWF is one that cannot be reversed, meaning that the hash cannot be reversed to obtain the input data that stored it.
One-way functions, and particularly hashing functions, are very commonly used to store passwords. Unfortunately, the vernacular does not distinguish sufficiently between those OWFs that are hashing functions and those that are not. For instance, as we shall see later, one of the password storage algorithms used in Windows is a one-way function, but it is not a hashing function. Nevertheless, its outcome is typically referred to as a hash. To avoid muddying the waters further, we perpetuate this poor practice, while pointing out when we get to that section why it is an incorrect description. Where the passwords are not obfuscated using an OWF, we do not call them hashes, but rather refer to them as encrypted passwords. In general, all of these are "stored password representations," reflecting that they are representations of the original chosen passwords that are stored on a computer system.
During logon, the same operation would be performed on the password the user entered and if the result matched the stored value, the user had entered the correct password. The file that held the passwords was often world-readable clear text to enable it to be used for various types of authentication by various users. This caused a problem, however. If Alice and Bob have the same password, they will also have the same stored value (called a hash for simplicity from now on) in the password file. Because the file was world-readable, Bob could simply grep (search) the file for other users who have the same hash as he does and, hence, the same password. To handle that problem, passwords were salted. Salting is the process of obfuscating the password hash by modifying the password using a short value before hashing. The short valuethe saltcan be stored in clear text in the password file. It need not be secret. More than likely, nobody foresaw this when salting was invented, but salting also solved another interesting problem, as discussed later.
NOTE: Saltingthe process of obfuscating the password before hashingwas invented solely to ensure that the stored password representation for two users is different even if those users have the same password.