Salting adds a unique, random value to a password before hashing it, ensuring that even identical passwords produce different hashes and defeating precomputed rainbow-table attacks.
Key Points: • A salt is generated randomly per password and stored alongside the hash (not secret, but unique per user). • Without salting, identical passwords hash to identical values, letting attackers spot duplicate passwords and use precomputed hash tables. • Spring Security's BCryptPasswordEncoder handles salting automatically and embeds the salt within the encoded output string. • Verification re-derives the hash using the stored salt and compares it to the stored hash via matches(), never by decrypting. • Salting alone doesn't slow brute-force attacks—that's why BCrypt also adds a tunable, deliberately slow work factor.
Example: Two users who both choose "password123" end up with completely different stored hashes because BCrypt generates a different random salt for each, so an attacker can't tell they share a password just by comparing hashes.
Interview Tip: A concise interview answer is:
"Salting adds a random value to each password before hashing, so identical passwords produce different hashes and rainbow-table attacks become useless. Spring Security's BCryptPasswordEncoder handles this automatically, generating and embedding a unique salt for every password it encodes."