What is password hashing and salting?

‍Password hashing is a process in which a password is converted into a character string of a fixed length using a hash function. This character string - the so-called hash value - looks completely different from the original password and (theoretically) cannot be recalculated. Typical algorithms for this are e.g. bcrypt, scrypt or Argon2.

 ‍1. protection in the event of data leaks

If a database is compressed and the passwords are stored in plain text, any attacker can access the accounts immediately. Hashes, on the other hand, are unreadable - and even individually different thanks to additional security mechanisms such as salting, even with identical passwords.

‍2. one-way function

Hash functions are irreversible - in other words, even the platform operator cannot reconstruct the original password. This is an important principle of the “zero knowledge” principle in IT security.

‍1. standard in IT security

Hashing (in combination with salt and a secure algorithm) is a recognized best practice standard and is indirectly required in the GDPR and in security standards such as ISO 27001, among others

Hashing and encryption are often confused, but they fulfill different purposes. Encryption is a reversible process - this means that a password or message can be encrypted with a key and later decrypted again with the matching key. The aim is to keep the information confidential over a certain period of time.

Hashing, on the other hand, is irreversible. A hashed value cannot be meaningfully converted back into the original password. This is why hashing is ideal for verifying passwords: When logging in, the password entered is hashed again and compared with the saved hash - without ever having to save the password itself.

Short:

Encryption = recoverable (e.g. for data transmission)
Hashing = one-way function (e.g. for password verification)

‍A secure hash function for passwords must fulfill specific requirements:

• Slowness (computational intensity): To make brute-force attacks more difficult
• Salt support: To prevent rainbow table attacks
• Resistance to parallel processing: Prevents efficient GPU or ASIC attacks
• Future-proof: Algorithm should be actively maintained and security-tested
• Memory hardening (for Argon2): Makes attacks with dedicated hardware more difficult

‍A salt is a randomly generated character string that is included in the hash in addition to the password. This ensures that even identical passwords generate different hashes. Without a salt, an attacker could use pre-calculated hash tables (known as rainbow tables) to recognize passwords immediately. The salt makes this method practically useless, as the attacker would have to recalculate for each hash and each salt.

Example:

• User A & B both use “password123”
• Without salt: same hash → easy to attack
• With salt: completely different hashes → more secure

‍The following algorithms in particular are considered best practices for secure password hashing today:

• bcrypt: Widely used, well tested, supports salting and is configurable in terms of computing time
• scrypt: Additionally memory-intensive → makes attacks with specialized hardware more difficult
• Argon2: Winner of the Password Hashing Competition (PHC), currently considered the most modern standard (especially Argon2id)

These algorithms offer protection against modern attacks and can be configured to meet security requirements.

‍MD5 and SHA-1 were not originally designed for password security, but for fast integrity checks. This is precisely their problem: they are far too fast and therefore ideal for brute force or dictionary attacks. What's more, both algorithms are now cryptographically broken, meaning that there are real methods for generating collisions, i.e. two different inputs with identical hashes. This not only makes them insecure, but also completely unsuitable for passwords.

‍When logging in, the check proceeds as follows:

• The user enters their password.
• The system takes the corresponding salt and hash from the database.
• It hashes the entered password with the same salt.
• The result is compared with the stored hash.
• If the values match, authentication is successful.

The actual password is never saved or compared directly - only the hash values are decisive.

Computing intensity (also known as work factor) is a security feature: the more computing time a hash requires, the more difficult it is for attackers to try out millions of hashes per second. Modern algorithms such as bcrypt or Argon2 can be configured so that a hashing process takes 200 milliseconds, for example. This is not a problem for legitimate users - but it is a massive obstacle for attackers who want to test billions of passwords.

Important: The work factor should be checked regularly and adjusted if necessary as the computing power increases.

‍The biggest risks are

• Complete identity theft: If plain text passwords are leaked, accounts can be taken over directly.
• Credential stuffing: The same passwords are often used on several platforms - attackers automatically test them on other sites.
• Loss of image and trust: A data leak with plaintext passwords can ruin a company's reputation in the long term.
• GDPR violations and fines: Failure to protect personal data can result in legal consequences.

‍The changeover is technically demanding, but feasible:

• Implement a new hash method (e.g. bcrypt instead of SHA1)
• Continue to use existing passwords for the time being, but:
• Use the new hash algorithm at the next login or password reset
• Optional: ask all users to change their password to speed up migration
• If necessary, introduce versioning of the hashes (e.g. hash with prefix: $2y$ for bcrypt)

It is important to make the changeover transparent and secure - including tests, logging and, if necessary, notifying users.