Security and lax syntax
Imagine you’re sitting in the pub trying to remember a film title and you just can’t, for the life of you, summon up more than the fact that it begins with an ‘N’ (or maybe a ‘D’) and it definitely has something to do with cars. Then your friend says “Casablanca” and you say “YES! That’s it!” Sound familiar?
Despite being totally unsure of any details a moment before, you know beyond any doubt that you have it the instant somebody suggests the correct answer. It’s the difference between recall and recognition that divides frustrated vagueness from confident certainty. That same basic idea has an important role in computer security.
Passwords should not normally be stored as readable text. Instead, modern systems store a cryptographic representation that allows the application to check whether the password entered during login matches the original without needing to store the original password itself.
This is usually described as password hashing, rather than encryption. Encryption is designed to be reversible with the correct key, whereas a secure password hash is intended to be one way. Current guidance from OWASP recommends dedicated password-hashing algorithms such as Argon2id and advises against using fast general-purpose hashes such as MD5 or SHA-1 for password storage. :contentReference[oaicite:0]{index=0}
When a user creates a password, the system processes it with a password-hashing algorithm and stores the resulting value. When the user logs in again, the supplied password is processed in the same way and securely compared with the stored result.
However, hashing alone is not enough. If two users choose the same password and a system hashes both identically, an attacker may be able to recognise those matching values or use precomputed lists of common password hashes.
This is why secure systems use a unique random salt for each password. A salt is additional data included when generating the password hash, so identical passwords produce different stored values. Both OWASP’s password storage guidance and NIST’s Digital Identity Guidelines recommend salted password hashing. :contentReference[oaicite:1]{index=1}
Modern password-hashing functions are also deliberately computationally expensive. This slows down attackers attempting millions or billions of password guesses after obtaining a database of password hashes. OWASP currently recommends Argon2id for new applications, with alternatives such as scrypt or PBKDF2 where appropriate. :contentReference[oaicite:2]{index=2}
Older algorithms illustrate why this matters. For example, the MD5 hash:
5f4dcc3b5aa765d61d8327deb882cf99
is famously associated with the word password. Because MD5 is extremely fast and commonly used passwords have already been hashed and catalogued countless times, simply storing an unsalted MD5 hash offers very little protection against an attacker with access to the password database.
Another commonly encountered value is:
d41d8cd98f00b204e9800998ecf8427e
This is the MD5 hash of an empty string. Values like this can sometimes reveal programming errors where an application has accidentally hashed missing or empty input.
Good password security therefore depends on more than simply replacing a password with a hash. Developers should use established password-hashing functions, unique salts, appropriate computational cost settings and secure framework functions rather than inventing their own authentication system. OWASP provides detailed authentication guidance for developers, while NIST publishes broader digital identity and authentication recommendations. :contentReference[oaicite:3]{index=3}
The principle remains much the same as our pub example. A well-designed system does not need to recall your password. It just needs a secure way to recognise whether the password you provide is correct.