fredag 31 december 2010

Icke-ASCII blir '?' i lösenord hos Gawker

Jag har ägnat ett par dagar åt att rota i vettiga lösningar på lösenordshantering i kölvattnet av Gawker-hacket och alla de knäckta lösenordshasharna.

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:
  1. Uppgradera om ni använder jBCrypt < 0.3.
  2. 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å.
  3. Gawker kör åtminstone nu bcrypt vilket trots allt hedrar dem. Alla ni med vanliga lösenordshashar i databasen bör ta en funderare.
  4. 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!

2 kommentarer:

Anonym sa...

De flesta lösenord hos Gawker var sparade med gamla DES-baserade crypt() funktionen (12-bit salt och max 8 tecken input, endast ASCII) och alltså INTE bcrypt. Detta medförde att de flesta lösenord kunde knäckas inom väldigt kort tid. Mer läsning: http://intrepidusgroup.com/insight/2010/12/crypt3-rainbow-tables/ http://blogs.wsj.com/digits/2010/12/13/the-top-50-gawker-media-passwords/

John Wilander sa...

Ah, sant. Även duosecurity-länken i mitt inlägg hade info om DES crypt(3). Jag bara gissade att om de hade gamla jBCrypt 0.2 nu så borde de haft det tidigare också.

Var det månne en crypt(3)/bcrypt-mixad miljö hela vägen och efter hacket så övergick till bara bcrypt utan att installera ny jBCrypt-version?