Een site mag wachtwoorden nooit leesbaar bewaren: hij slaat alleen de hash op, berekend met een functie die maar in een richting werkt. Bij het inloggen berekent hij de hash van het ingevoerde wachtwoord opnieuw en vergelijkt. Zonder salt heeft die methode een groot nadeel: twee mensen die hetzelfde wachtwoord kozen, krijgen precies dezelfde hash, en een aanvaller kan vooraf tabellen maken met de hashes van de meest gebruikte wachtwoorden. De salt lost beide problemen op.
Hoe salting werkt
Bij de registratie of bij een wachtwoordwijziging kiest de site willekeurig een unieke tekenreeks, de salt, en voegt die toe aan het wachtwoord voordat de hash wordt berekend. De salt wordt leesbaar naast de hash opgeslagen: hij hoeft niet geheim te zijn. Zijn taak is elke berekening uniek te maken.
- Vooraf berekende tabellen worden nutteloos: de aanvaller zou ze voor elke salt opnieuw moeten maken.
- Identieke wachtwoorden vallen niet meer op in een gestolen database.
- Elk account moet apart worden aangevallen, wat het werk van een offline aanval flink vermenigvuldigt.
Een salt maakt een zwak wachtwoord nog niet sterk: "Zomer2024" blijft een van de eerste pogingen bij een brute-force-aanval. Daarom combineer je de salt met een bewust trage functie zoals bcrypt, scrypt of Argon2, die de salt automatisch meenemen.
Salt, pepper en aanbevelingen
OWASP maakt onderscheid tussen de salt, uniek per wachtwoord en daarnaast opgeslagen, en de pepper, een gedeeld geheim dat buiten de database wordt bewaard, bijvoorbeeld in een kluis voor geheimen. De pepper voegt een extra verdedigingslaag toe als alleen de database uitlekt. Het uitgangspunt van de aanbevelingen is overal hetzelfde: bewaar wachtwoorden nooit leesbaar, maar alleen als uitkomst van een veilige, niet omkeerbare cryptografische functie met een salt.
Voor WordPress
In WordPress verwijst het woord "salt" naar twee dingen die je niet door elkaar moet halen.
De salt van wachtwoorden
Sinds WordPress 6.8 worden de wachtwoorden van gebruikers met bcrypt gehasht via de PHP-functie password_hash(), die voor elk wachtwoord een willekeurige salt aanmaakt en die in de hash zelf opslaat. Je hoeft niets in te stellen: het salten gebeurt automatisch.
De sleutels en salts in wp-config.php
Het bestand wp-config.php bevat acht constanten: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY en hun tegenhangers AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT. Ondanks hun naam lijken deze waarden eerder op een pepper: ze zijn geheim en dienen om inlogcookies en nonces te ondertekenen. Lekken ze uit, dan kan iemand proberen geldige cookies te vervalsen.
- Genereer ze met de officiële dienst
api.wordpress.org/secret-key/1.1/salt/of met het WP-CLI-commandowp config shuffle-salts. - Vervang ze na een inbraak: alle bestaande cookies worden ongeldig en elke gebruiker moet opnieuw inloggen.
- Kopieer ze niet van site naar site en publiceer ze nooit in een coderepository.
Ons artikel over de beveiligingsinstellingen in wp-config.php bespreekt deze constanten en andere nuttige opties. Voor de andere kant van het probleem, wachtwoorden die op meerdere sites worden hergebruikt, lees je over gelekte wachtwoorden en het verweer ertegen: een salt beschermt geen wachtwoord dat de aanvaller al kent, en daarom is credential stuffing zo populair bij hackers.