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!

Hur spara applikationslösenorden?

En evig fråga för systemutvecklare och driftansvariga är – hur sparar vi lösenorden som applikationen behöver? Det är ofta flera lösenord som har med applikationen eller applikationsservern att göra. Lösenord till databasen, lösenord till certifikat, lösenord till keystores, lösenord för maskin till maskin-koppel och så vidare.

Alternativen som står till buds

Det finns följande enkla men osäkra alternativ:

• Lösenord i klartext i konfigurationsfil
• Lösenord i klartext i koden

Sen har vi de bra mycket säkrare men också jobbigare alternativen:

• Krypterade lösenord i konfigurationsfil med nyckel i koden (kan vara en masternyckel för hela applikationen)
• Krypterade lösenord i kod eller kodnära konfigurationsfil och lösenord i driftnära konfigurationsfil (känns lite bakvänt men ibland har man större förtroende för driftansvarig än för utvecklarna, t ex vid outsourcing)
• Krypterade lösenord i en LDAP eller liknande

Och så har vi hybriden:

• Krypterade lösenord i konfigurationsfil med delad nyckel – halva i koden, halva i konfigurationsfil.

Till sist har vi de väldigt säkra och grymt jobbiga alternativen:

• Lösenord i huvudet på driftansvariga (anges vid varje driftsättning medelst många svordomar)
• Drakonisk hårdvarulösning

Standardlösningar?

Mig veterligen så finns ingen standardlösning på det här i vaniljsmaken på Java EE. Istället så bestämmer varje team sig för hur man ska göra med lösenorden. Synd.

I lakritsjava (=enterprise) så finns det färdiga lösningar. IBMs WebSphere kör tyvärr default med en naiv XOR (ref):

"WebSphere Application Server stores passwords XOR encoded in the XML configuration files."

Men man kan plugga in valfri krypteringslösning genom att implementera deras CustomPasswordEncryption-interface eller sätta customPasswordEncryptionClass och customPasswordEncryptionEnabled i PropFilePasswordEncoder.bat/sh. Bra grejer.

i .NET-världen kanske det ser annorlunda ut, inte minst tack vare integrationen med Windows API:er som Data Protection API (CryptProtectData). Men jag är ingen klippa på .NET. Någon som kan hjälpa till? Kristofer?

Vad ska man brygga om man brygger hemma?

OK, men för oss som inte har betalat för en WebSphere-licens, vad står till buds? En XOR-kryptering med statisk nyckel i koden kanske?

Nja, så här säger min kollega Lars Johansson om XOR-kryptering:

XOR ger visserligen "perfekt sekretess" (bevisat av Shannon 1949), men det förutsätter följande:

1. Nyckeln måsta vara lika lång som klartextmeddelandet.
2. Nyckeln måste vara fullständigt slumpmässig. Så fort en nyckel återanvänds går det att knäcka kryptotexten!

Båda dessa ovanstående krav gör att perfekt sekretess med XOR inte går att realisera i praktiken. Använd en etablerad kryptoalgoritm i stället, t.ex. AES. Då är det inte lika noga med nyckellängden (256 bitar duger gott). Nyckeln bör dock fortfarande ha bra slump/entropi.

Vi borde skärpa oss lite

Jag tror de flesta tycker det här är för jobbigt och har alla maskinlösenord i klartext eller med defaultskydd. Vi borde skärpa oss lite. AES-kryptering med nyckeln i källkoden borde vara ett minimum. Gärna genom en snygg öppen källkodslösning som alla kan planka :).

Vad tycker ni andra? Hur gör ni?