Individuell saltning av varje lösenord löser rainbow table-problemet. Men så länge användare tillåts ha korta lösenord (Amazon och Apple tillåter exempelvis sex tecken) så är ren brute force fullt möjligt. Och det blir inte bättre i takt med att datorer blir snabbare.
Bästa alternativen verkar vara Secure Remote Password protocol som jag skrev om i förrgår eller att nyttja maximal långsamhet i Blowfish, det vill säga bcrypt à la OpenBSD. Olle Segerdahl kommenterade bloggen med dessa tips i februari i år under mitt inlägg om genererade toString().
ДДДДДДДД == 簡簡簡簡簡簡簡簡 == ©©©©©©©©?
Joseph Bonneau, doktorand vid Cambridge, upptäckte att Gawker tolkar alla icke-ASCII-tecken i lösenord som likvärdiga. Dvs du kan logga in på ett konto som har lösenordet "ДДДДДДДД" med valfritt annat icke-ASCII-lösenord med samma antal tecken, t ex "簡簡簡簡簡簡簡簡" och "©©©©©©©©".
Problemet visade sig vara en bugg i jBCrypt innan v 0.3 där alla icke-ASCII-tecken byttes ut mot '?' innan hashning. Det finns beskrivet i en advisory från februari i år.
Fyra slutsatser:
- Uppgradera om ni använder jBCrypt < 0.3.
- Använd bara ASCII-tecken i era lösenord och låt istället längden ge er säkerhet mot brute force. Det är bra när ni är utomlands också.
- Gawker kör åtminstone nu bcrypt vilket trots allt hedrar dem. Alla ni med vanliga lösenordshashar i databasen bör ta en funderare.
- Om Gawker körde bcrypt redan i våras så var det särdeles dumt att inte uppgradera jBCrypt till 0.3 när patchen kom i februari. Om de driftsatte jBCrypt 0.2 efter hacket så var det ännu dummare. Men det sätter återigen fingret på ramverks- och bibliotekspatchning. Vem håller koll på alla säkerhetsuppdateringar i olika lib man har länkat in? "Ingen" är min gissning i de flesta fall.
Gott nytt år!
