Taggat med: Scrypt

Så lagrar Dropbox ditt lösenord

Att Dropbox blev hackade och samtliga lösenord hamnade på vift 2012 är något som är välkänt. Av analys visade det sig att hälften av lösenorden var SHA1-hashade och andra hälften använde sig av bcrypt-hash. Detta troligtvis pga en pågående övergång från SHA1 till bcrypt.

Det har hänt en hel del sedan 2012 och Dropbox avslöjade nyligen hur de lagrar sina lösenord på ett säkert sätt.

Först och främst använder Dropbox precis som Facebook (se nedan) flertalet lager, som en lök. Att använda SHA512 före bcrypt är främst av två anledningar: överbelastningsattack om långa lösenord används samt att vissa implementationer av bcrypt kortar ner lösenordet till 72 bytes.

bcrypt används med en cost på 10 (arbetsfaktor/work factor) samt en unik salt för varje användare. Detta steg tar ungefär 100ms på Dropbox servrar.

Sista steget är AES256 med en global nyckel som är samma för alla hashar. Detta är för att om hela databasen blir snodd eller servern där lösenorden lagras så finns det ett extra skydd med en nyckel som är svår att hitta.

Dropbox lösenord

Även Facebook använder flertalet lager för sina lösenord (läs mer här):

Facebook lösenord

Dropbox har sedan tidigare utvecklat zxcvbn som ser till att användarna väljer bra lösenord först och främst. Även så kan vi anta att Dropbox kontinuerligt bevakar läckage av lösenord på nätet och informerar användare om just deras lösenord finns med eller går att knäcka.

Givetvis kan man alltid argumentera att det nu finns säkrare alternativ till bcrypt såsom argon2 och scrypt. Men bcrypt har bra stöd i många programbibliotek och har funnits ända sedan 1999. Dock uppger Dropbox att de har mer erfarenhet av bcrypt men kommer troligtvis att uppgradera till argon2.

Även uppger Dropbox att de kommer i framtiden att överväga att använda en HSM (kanske CrypTech?) för att lagra den globala nyckeln. Denna nyckel roteras också regelbundet uppger de på sin blogg.

Så lagrar Facebook lösenord

På en konferens nyligen så avslöjade Facebook hur de lagrar sina lösenord. Eller rättare skrivet hur de hashar sina lösenord.

  1. $cur  = ’plaintext’
  2. $cur  = md5($cur)
  3. $salt = randbytes(20)
  4. $cur  = hmac_sha1($cur, $salt)
  5. $cur  = cryptoservice::hmac($cur)
  6.         [= hmac_sha256($cur, $secret)]
  7. $cur  = scrypt($cur, $salt)
  8. $cur  = hmac_sha256($cur, $salt)

1. Det första steget är tämligen självförklarande.

2. Gör först en MD5 av lösenordet. Detta ligger troligtvis kvar pga historia då detta troligtvis enbart var det enda steget. Om en användare loggar in och enbart har en md5 så kommer lösenordet att uppdateras med det nya systemet enligt nedan.

3. En salt på 160 bitar är genererad slumpmässigt. För att förhindra kollisioner så bör den vara minst 64 bitar pga antalet användare och övriga bitar är troligtvis för att framtidssäkra.

4. En HMAC med sha1 skapas som sedan skickas in i nästa steg.

5. Detta steg är för att inneha en central kontrolldel och att förhindra offline eller online forceringsattacker mot lösenord.

7-8. scrypt för att försvåra forcering samt skapande av regnbågstabeller. Vi har många gånger tidigare skrivit om scrypt. Samt sista steget är för att göra databasen med lösenord mindre.

Facebook håller även koll på lösenordsdumpar som publiceras på internet och förekommer ditt lösenord i en sådan dump så kommer Facebook att varna dig.

Bedömt så har Facebook lagt mycket kraft bakom lösenordshashningen och det ser mycket bra ut.

Joachim Strömbergson
Joachim Strömbergson

Joachim Strömbergson som är säkerhetsexpert på företaget Assured som också har tittat på Facebooks sätt att lagra lösenord kommenterar enligt följande:

För att sammanfatta min känsla efter 5 sekunder är att man är duktig och använder seed, man har till och med vad som ser ut att vara ytterligare en hemlighet vilket gör det än svårare att försöka göra regnbågsattacker. Vidare använder man dessutom scrypt för att införa work factor som försvårar uttömmande sökning.

Källa på informationen är det som Facebook uppgav vid konferensen Real World Crypt 2015.

Uppdatering: Per Thorsehim tipsar även om att Alec Muffett från Facebook höll en presentation vid konferensen Passwords 2014 i Norge där han berättar mer i detalj:

Facebook lösenord

Finalister i Password Hashing Competition

Password Hashing Competition (PHC) är en tävling som går ut på att hitta nya bra algoritmer för att hasha lösenord. Det finns tyvärr i dagsläget inte så många bra kanidater att välja på: scrypt och bcrypt. Bakom tävlingen står en grupp med kryptografiska experter såsom Peter Gutmann, Colin Percival och Matthew Green.

Tävlingskriterierna är enligt följande:

  • Skydd mot beräkningar i GPU/FPGA/ASIC
  • Skydd mot tid-minneskompromisser
  • Skydd mot sidokanalsläckage
  • Skydd mot kryptografiska attacker
  • Elegans och enkelhet
  • Dokumentationskvalité
  • Kvalité på referensimplementationen
  • Allmän sundhet och enkelhet av algoritmen
  • Originalitet

Det har nu presenterats 12 finalister som är följande:

Argon, battcrypt, Catena, Lyra2, Makwa, Parallel, POMELO, Pufferfish, yescrypt (som vi skrev om i Maj 2014).

För att läsa mer om dessa finalister kolla in password-hashing.net.

yescrypt

Efter bcrypt och scrypt kommer yescrypt

Nyligen så höll Solar Designer en presentation under konferensen PHDays 2014 om yescrypt. Yescrypt är en förbättring av bcrypt, scrypt och PBKDF2 som ska göra det svårare att knäcka lösenord.

Att det blir svårare att knäcka lösenord som använder sig av yescrypt beror på ett par olika faktorer såsom att det är svårt att använda hårdvara (GPU etc) för att knäcka lösenord.

Yescrypt är också ett av 22 bidrag till tävlingen Password Hashing Competition som går ut på att hitta en efterföljare till dagens lösenordshashingalgoritmer.

Nackdelar finns det dock, det är tämligen svårt att implementera yescrypt. Programmerare som försökt att implementera scrypt vet hur svårt detta har varit. Tyvärr så uppkommer det om och om igen att läckta lösenordsdatabaser ej använt hashalgoritmer, nu nyligen var det eBay.

PDF med presentation hittar du här:

YescryptDiskussion hittar du på Reddit samt källkod för test återfinnes på Github.

 

 

Sårbarheter uppdagade i TrueCrypt

Säkerhetsföretaget iSEC Partners med Andreas Junestam som teknisk projektledare har genomfört en granskning av den populära krypteringsmjukvaran TrueCrypt (TC). Granskningen påvisar totalt 11 stycken felaktigheter varav fyra är av allvarlighetsgrad medium och fyra har låg allvarlighetsgrad samt tre är enbart för information.

Granskningens fokus låg på bootloader samt Windows kernel-drivrutinen och inga eventuella avsiktliga bakdörrar identifierades. Dock innehar TC en dålig kodstandard:

Overall, the source code for both the bootloader and the Windows kernel driver did not meet expected standards for secure code.

Den dåliga kodstandarden leder inte bara till att eventuella sårbarheter introduceras lättare samt svårare att upptäcka utan även att det blir en högre tröskel för nya utvecklare som vill bidra till projektet.

En av de allvarligare sårbarheterna som identifierades var att nyckelderivatafunktionen PBKDF2 enbart används med 1000 eller 2000 iterationer vilket är för lågt. Exempelvis så rekommenderades 1000 iterationer att användas år 2000 (enligt RFC 2898). Detta finns även dokumenterat på TrueCrypt.org.

Förhoppningsvis kommer TC att i framtiden ge användaren möjlighet att öka antalet iterationer eller helt gå över till Scrypt.

Här kan du läsa granskningsrapporten som PDF:

Granskning av TrueCrypt

 

Läs mer här:

Eller på TKJ:s blogg.