Kysymys:
Suositeltu iteraatioiden määrä käytettäessä PKBDF2-SHA256?
Tails
2011-05-20 03:32:55 UTC
view on stackexchange narkive permalink

Olen utelias, onko jollakin neuvoja tai viitekohtia määritettäessä kuinka monta iteraatiota on "tarpeeksi hyvä" käytettäessä PBKDF2: ta (erityisesti SHA-256: n kanssa). Varmasti, "tarpeeksi hyvä" on subjektiivinen ja vaikea määritellä, vaihtelee sovelluksen &-riskiprofiilin mukaan, ja mikä tänään on "tarpeeksi hyvä", ei todennäköisesti ole huomenna "tarpeeksi hyvä" ...

Mutta kysymys on edelleen mikä teollisuuden mielestä on tällä hetkellä "tarpeeksi hyvä"? Mitä vertailupisteitä on saatavilla vertailua varten?

Joitakin löytämiäni viitteitä:

  • syyskuu 2000 - suositellaan yli 1000 kierrosta (lähde: RFC 2898)
  • helmikuu 2005 - AES Kerberos 5: ssä "oletusarvo" 4096 SHA-1-kierrokselle. (lähde: RFC 3962)
  • syyskuu 2010 - ElcomSoft väittää, että iOS 3.x käyttää 2000 iteraatiota, iOS 4.x käyttää 10000 iteraatiota, osoittaa, että BlackBerry käyttää 1: tä (tarkkaa hash-algoritmia ei ilmoiteta) (lähde: ElcomSoft)
  • Toukokuu 2011 - LastPass käyttää 100000 SHA-256-toistoa (lähde: LastPass)
  • kesäkuu 2015 - StableBit käyttää 200 000 SHA-512-toistoa (lähde: StableBit CloudDrive Nuts & Bolts)
  • elokuu 2015 - CloudBerry käyttää 1000 SHA-1-iteraatiota (lähde: CloudBerry Lab Security näkökohdat (pdf))

Arvostan muita viitteitä tai palautetta siitä, kuinka määritit, kuinka monta iteraatiota oli tarpeeksi hyvä sovelluksellesi.

Lisätaustana harkitsen PBKDF2-SHA256: ta menetelmänä, jolla hajautetaan käyttäjän salasanoja tietoturvatietoiselle verkkosivustolle. Suunniteltu PBKDF2-suola on: käyttäjäkohtainen satunnaissoola (joka on tallennettu tyhjään tilaan jokaisen käyttäjätietueen kanssa), XOR'tettu globaalilla suolalla. Tavoitteena on nostaa salasanojen pakottamisen kustannuksia ja välttää paljastamasta käyttäjiä, joilla on sama salasana.

Viitteet:

  • RFC 2898: PKCS # 5: Salasana- Perustuva salausmääritys v2.0
  • RFC 3962: Advanced Encryption Standard (AES) -salaus Kerberos 5: lle
  • PBKDF2: Salasanapohjainen avaimen johtamistoiminto v2
Vaikka merkitsen tämän vastaukseksi, arvostan silti kaikkia viitteitä, jotka dokumentoivat kuinka monta iteraatiota muut sovellukset käyttävät ... Kiitos.
Globaali suola ei lisää mitään ylimääräistä suojaa sateenkaaripöytiä vastaan. Jos käytät yleistä suolaa estämään offline-murtamisyrityksiä, kannattaa ehkä [harkita HMAC: n käyttöä] (http://security.stackexchange.com/questions/19243/should-password-hashes-be-encrypted-or sen sijaan. Harkitse myös bcryptin tai scryptin käyttämistä PBKDF2-SHA256: n sijaan, koska ne on suunniteltu nimenomaisesti hitaasti hajauttamaan salasanoja.
Pakollinen huomautus kaikille tänne tuleville: Nykyään kannattaa vakavasti harkita parempien avainten venytysalgoritmien käyttöä kuin PKBDF2, koska se on erittäin hajautettavissa. Pidä [Argon2] (https://fi.wikipedia.org/wiki/Argon2) uusimpana asiana (voittaja vuodesta 2015) tai scrypt tai niin.
Viisi vastused:
#1
+239
Thomas Pornin
2011-05-20 17:43:14 UTC
view on stackexchange narkive permalink

Käytä sovelluksessasi enimmäiskierrosten lukumäärää, joka on siedettävä ja suorituskykyinen. Kierrosten lukumäärä on hidastumiskerroin, jota käytät sillä perusteella, että normaalissa käyttöolosuhteissa tällaisella hidastumisella on sinulle merkityksetön vaikutus (käyttäjä ei näe sitä, ylimääräiset suorittimen kustannukset eivät tarkoita isomman palvelimen ostamista ja pian). Tämä riippuu suuresti toimintaympäristöstä: mitä koneita kyseessä on, kuinka monta käyttäjän todennusta sekunnissa ... joten kaikille sopiva vastaus ei ole.

Laaja kuva menee näin:

  • Järjestelmän yksittäisen salasanan vahvistusaika on v . Voit säätää tätä aikaa valitsemalla kierrosten lukumäärän PBKDF2: ssa.
  • Mahdollinen hyökkääjä voi kerätä f kertaa enemmän suorittimen virtaa kuin sinä (esim. Sinulla on yksi palvelin ja hyökkääjällä on 100 isoa tietokonetta, joista jokainen on kaksi kertaa nopeampi kuin palvelimesi: tämä johtaa f=200).
  • Keskimääräisellä käyttäjällä on entropian salasana n bittiä (tämä tarkoittaa, että käyttäjän salasanan arvoittaminen sanalla "uskottavat salasanat" vie keskimäärin 2 n-1 yritystä).
  • Hyökkääjä löytää järjestelmäsi hyökkäyksen arvoisen, jos keskimääräinen salasana voidaan murtaa alle p ajassa (se on hyökkääjän "kärsivällisyys").

Tavoitteenasi on, että yhden salasanan rikkomisen keskimääräiset kustannukset ylittävät hyökkääjän kärsivällisyyden, jotta hän ei edes yritä, ja keskittyy edelleen toiseen, helpompaan kohteeseen. Yllä kuvattujen merkintöjen avulla tämä tarkoittaa, että haluat:

v · 2 n-1 > f · p

p on sinun hallinnassasi; se voidaan arvioida käyttäjän salasanoilla suojattujen tietojen ja järjestelmien arvon suhteen. Oletetaan, että p on yksi kuukausi (jos se kestää yli kuukauden, hyökkääjä ei vaivaudu yrittämään). Voit pienentää f ostamalla isomman palvelimen; Toisaalta hyökkääjä yrittää tehdä f isommaksi ostamalla isompia koneita. Raskauttavaa on, että salasanojen murtaminen on häpeällisesti rinnakkainen tehtävä, joten hyökkääjä saa suuren tehon käyttämällä GPU: ta, joka tukee yleistä ohjelmointia; joten tyypillinen f vaihtelee edelleen muutaman sadan luokasta.

n liittyy salasanojen laatuun, johon voit jotenkin vaikuttaa tiukan salasananvalintakäytännön kautta, mutta realistisesti sinulla on vaikea saada n arvoa, joka ylittää esimerkiksi 32 bittiä. Jos yrität ottaa käyttöön vahvempia salasanoja, käyttäjät alkavat aktiivisesti taistella sinua vastaan ​​kiertotavoilla, kuten muualta saatavien salasanojen uudelleenkäytöllä, salasanojen kirjoittamisella muistilappuille ja niin edelleen.

Joten jäljellä oleva parametri on v . Kun f = 200 (hyökkääjä, jolla on tusina hyvää grafiikkasuoritinta), yhden kuukauden kärsivällisyys ja n = 32 , sinun on v oltava vähintään 241 millisekuntia (Huomaa: Kirjoitin alun perin "8 millisekuntia" tähän, mikä on väärin - tämä on yhden päivän kärsivällisyys yhden kuukauden sijaan). Joten sinun pitäisi asettaa kierrosten määrä PBKDF2: ssa siten, että sen laskeminen yhdellä salasanalla vie vähintään niin paljon aikaa palvelimellasi. Pystyt silti vahvistamaan neljä salasanaa sekunnissa yhdellä ytimellä, joten suorittimen vaikutus on todennäköisesti vähäinen (*). Itse asiassa on turvallisempaa käyttää enemmän kierroksia kuin, koska tunnustetaan tosiasia, että 32 bitin arvoisen entropian saaminen keskimääräisestä käyttäjän salasanasta on hieman optimistista; toisaalta, harvoissa hyökkäyksissä ei käytetä kymmeniä tietokoneita yhden kuukauden ajan yhden salasanan murtamiseen, joten ehkä yhden päivän "hyökkääjän kärsivällisyys" on realistisempi, mikä johtaa salasanan tarkistuskustannuksiin 8 millisekuntia.

Joten sinun on tehtävä muutama vertailuarvo. Edellä mainittu toimii myös niin kauan kuin PBKDF2 / SHA-256-toteutus on nopeaa. Esimerkiksi, jos käytät täysin C # / Java-pohjaista toteutusta, saat tyypillisen 2-3 hidastuskertoimen (verrattuna C: hen tai kokoonpanoon) suoritinta vaativiin tehtäviin; yllä olevissa merkinnöissä tämä vastaa f : n kertomista 2: lla tai 3: lla. Vertailun lähtötilanteena 2,4 GHz: n Core2-keskusyksikkö voi suorittaa noin 2,3 miljoonaa SHA-256-peruslaskentaa sekunnissa (yhdellä ydin), joten tämä merkitsisi kyseisessä suorittimessa noin 20000 kierrosta "8 millisekunnin" tavoitteen saavuttamiseksi.


(*) Huolehdi siitä, että salasanan vahvistamisen kallistaminen myös tekee palvelimestasi alttiimpia palvelunestohyökkäyksille. Sinun tulisi soveltaa joitain perustoimia, kuten tilapäisesti mustalle listalle asiakkaiden IP-osoitteet, jotka lähettävät liikaa pyyntöjä sekunnissa. Sinun on kuitenkin tehtävä se, jotta voit estää online sanakirjahyökkäykset

+1 loistavasta vastauksesta, jos voisin, antaisin toisen +1 häpeällisesti yhdensuuntaisesta linkistä :-)
Tämä on hieno tapa ajatella sitä - kiitos!
Ajatus vain: Voisitko pitää ~ 20k kierrosta asiakastietokoneella ja kuin 1k kierrosta palvelimella? Jos hyökkääjä aloittaisi arvaamalla "normaalit salasanat", hänen on silti suoritettava 21 000 kierrosta. Ja jos hän aloittaisi avaimilla, hänen täytyisi tehdä vain 1k kierrosta, mutta entropian tulisi olla paljon korkeampi. Puuttuuko minulta jotain? Minusta näyttää hyvältä ratkaisulta.
@cooky451: voit tehdä sen, mutta sitä voi olla vaikea määrittää. Asiakkaat voivat käyttää monenlaisia ​​laitteistoja, joista osa on erittäin heikkoa laskennassa. Verkkokontekstissa tämä tarkoittaa myös Javascriptiä, etkä saa paljon iteraatioita PBKDF2: n _Javascript_-toteutuksesta (se _tulee_ toimimaan paljon paremmin Java-sovelman kanssa, mutta se on vielä yksi matojen tölkki).
En ymmärrä miten päädyit 8 ms: iin esimerkissäsi. Jos f = 200, p = 30 * 24 * 60 * 60 * 1000 ?, n = 32. Sitten v on 241 ms? Muutin yhden kuukauden millisiksi. Etkö ole varma, mitä teen väärin. Kiitos vastauksesta
Se tulee 241 ms: iin. Itse asiassa, jos liität 8 ms kaavaan, saat noin 23 tuntia "hyökkääjän kärsivällisyydeksi". Mikä on paljon alle kuukausi (yhdelle 32-bittiselle entropiasalasanalle) ... Ja riittävän alhainen, jos suositeltavaa 8 ms: n arvoa todennäköisesti nostetaan.
Tässä on nopea komentosarja PBKDF2-vertailua varten (Huomaa: aika ilmoitetaan sekunteina): https://gist.github.com/sarciszewski/a3b1cf19caab3f408bf8
Olen samaa mieltä arviosi kanssa yhdellä selvennyksellä: iteraatioiden lukumäärän ei pitäisi perustua siihen, kuinka kauan * laitteistosi kestää toiminnon suorittamisen.Sen on perustuttava siihen, kuinka kauan * hyökkääjän * laitteisto voi suorittaa operaation.Jos sinulla on heikko laitteisto, se ei ole hyvä tekosyy iteraatioiden = 1 valitsemiseen.Pitkässä selityksessäsi kuvataan tätä edelleen kohtuullisella tavalla, mutta etukäteen tekemäsi johtopäätös on "niin paljon kuin luulet olevan kunnossa ympäristössäsi".Sen pitäisi todellakin olla "mitä tahansa hyökkääjän estämiseksi hänen ympäristössään".
Päivitämme nykyisen sovelluksemme salausta.Korkea iterointi aiheuttaa kuitenkin massiivisen suorituskyvyn, koska järjestelmämme on joskus käsiteltävä tuhansien merkintöjen salaamista / salauksen purkamista.Joten näyttää siltä, että meidän on käytettävä hyvin matalaa iteraatioarvoa - luultavasti enintään 1000.Joten minulla on kysymys, pitäisikö meidän edes vaivautua niin alhaisen arvon kanssa?Miksi ei vain mennä '1': n kanssa?
#2
+33
rook
2011-05-20 04:00:30 UTC
view on stackexchange narkive permalink

Suorita openssl speed komentorivillä saadaksesi käsityksen siitä, kuinka nopeasti sanomat sulautuvat. Voin laskea noin 1,6 miljoonaa sha256-hajautusta sekunnissa tai noin 145 miljardia arvausta päivässä neliytimisellä 2,2 GHz: n hiekkasillallani. Jos jollakin on salasana, joka on englanninkielisessä sanakirjassa ja käyttää yhtä sha256-kierrosta, sanaluettelon lataaminen levyltä kestää kauemmin kuin luettelon iterointi hajoamisen rikkomiseksi. Jos teit PKBDF2-SHA256: n muutamalla sadalla tuhannella kierroksella, murtuminen kestää muutaman minuutin. Vahvan salasanakäytännön noudattaminen auttaa paljon .

Todellinen vastaus: Kuinka paljon aikaa sinun on poltettava?

Hyviä puolia. openssl nopeus - mukavaa! Mutta 200 000 kierrosta, 2 M kierrosta sekunnissa, se on vain 10 sekuntia. Pieni sata tuhatta sanaa sisältävä sanakirja vie muutaman tunnin. Mutta joo, jopa monilla kierroksilla, huono salasana on huono ....
AilikpivttCMT kiinteä.
#3
+17
nealmcb
2011-05-21 00:53:20 UTC
view on stackexchange narkive permalink

Thomasin vastaus tarjoaa hyödyllisen perusmallin ja tiedot. Mutta hänen asettamallaan tavoitteella ei ole minulle järkeä. Tyypillinen hyökkääjä tietää iteraatiomäärän vasta, kun hän on todella hakkeroinut sivuston ja tarttunut hash-tietokantaan. Sen jälkeen he eivät edetä vain siksi, että käytät suurta iterointilukua. He yrittävät murtaa niin monta kuin pystyvät, ja julkistaa hajautukset, joten muut yrittävät murtaa ne tulevina vuosina yhä tehokkaammalla laitteistolla. Joten "p" ja "f" lisääntyvät molemmat kauan hakkeroinnin jälkeen.

Todellisia käyttäjän salasanoja ei myöskään ole mallinnettu monimutkaisuusmittarilla, kuten 32 bittiä entropiaa. Artikkelista Reusable Security: New Paper on Password Security Metrics on hyödyllistä tässä suhteessa, ja se dokumentoi sen, mitä olemme jo pitkään tunteneet: monet käyttäjät valitsevat helposti arvattavat salasanat, ja siellä on pitkä pyrstö. Tämä tarkoittaa myös sitä, että hyökkääjät löytävät aina joitain, jos he yrittävät tarpeeksi kovasti.

Sanoisin, että todennäköisempi tavoite olisi suojata mahdollisimman suuri osa käyttäjistäsi salasanojen murtumiselta. Esim. PDF: n taulukosta 4.2.1 käy ilmi, että jos onnistut rajoittamaan hyökkääjääsi jonkin hyökkäyskampanjan aikana keskimäärin miljoonasta yrityksestä hajautuksesta 500 000: een, saatat suojata 5%: n salasanat. käyttäjiäsi (olettaen, että sekoitus sisältää enemmän 7-merkkisiä salasanoja kuin yli 8-merkkisiä salasanoja, mikä vähentää säröillä olevaa osuutta 35 prosentista 30 prosenttiin). Tietysti käyrän tarkka muoto ja sijainti siinä vaihtelevat suuresti.

Joten haluaisin vain enimmäismäärän, jonka voit budjetoida, kunhan se ei viivästy todelliset käyttäjät, jotka kirjautuvat normaalisti. Ja sinun pitäisi lisätä arvoa, kun laskentakapasiteetti kasvaa vuosien varrella.

#4
+3
Martin Thoma
2019-06-01 11:57:06 UTC
view on stackexchange narkive permalink

Ota tämä hyvin pitkäksi kommentiksi. Olin utelias, kuinka nopeasti tavarat kulkevat henkilökohtaisella kannettavalla tietokoneellani (Thinkpad T460p, Intel i7-6700HQ). Tiedän, että suolattujen salasanojen murtamiseen on olemassa erityislaitteita, mutta jos sinulla on verkkopalvelu, sinulla ei todennäköisesti ole erityistä laitteistoa sitä varten.

Arvioinnin tulokset

Oletusarvo on werkzeug.security.generate_password_hash on tällä hetkellä (2019-06-01) pbkdf2:sha256:150000.

Kuten voit katso, suoritusaika kasvaa lineaarisesti kierrosten / iteraatioiden määrän kanssa. Tämä tarkoittaa, että oletus kestää keskimäärin 281 ms koneellani.

enter image description here

enter image description here

  sha512, 1 iterointi: min: 67,1μs, keskiarvo: 72,2μs, maksimi: 310,9μssha512, 15000 iterointi: min: 38462,8μs, keskiarvo: 40291,2μs, max: 44842,4μssha256, 15000 iterointi: min: 27167,6 μs, keskiarvo: 28118,0 μs, maks .: 30826,0μssha512, 1000 iteraatiota: min: 2636,7μs, keskiarvo: 2694.3μs, maks .: 3579.0μssha256, 1000 iteraatio: min: 1870.7μs, keskiarvo: 1888.8μs, max: 2477.0μsmd5, 15000 iteraatio: min: 21126,2μs, keskiarvo: 21864.8μs, maks .: 23799.3μssha512, 1 iterointi: min: 23.4μs, keskiarvo: 26.9μs, max: 40.6μssha512, 1000 iteraatio: min: 2586.7μs, keskiarvo: 2761.1μs, maks .: 3120,6μssha256, 1000 iteraatiota: min: 1823,3μs, keskiarvo: 1834,6μs, max: 2008,5μssha512, 15000 iteraatio: min: 38507,9μs, keskiarvo: 40210,8μs, max: 47430,3μssha256, 15000 iteraatio: min: 27257,1μs, keskiarvo: 28454,0 μs, max: 31213.5μsmd5, 15000 iterointi: min: 21219.9μs, keskiarvo: 21842.4μs, maks .: 24305.0μs  

C ode

#5
+1
ModernMachine
2012-06-19 20:48:48 UTC
view on stackexchange narkive permalink

Moderni kone, joka on varustettu kahdeksalla nykyisen sukupolven grafiikkasuoritimella, laskee noin 9 miljardia SHA-256 hashia sekunnissa tai noin 777 triljoonaa hashia päivässä, ja nämä GPU: t voivat suorittaa sääntöihin perustuvia sanakirjahyökkäyksiä.

Tämän päivityksenä lokakuussa 2014, [https://hashcat.net/oclhashcat/](https://hashcat.net/oclhashcat/), nopeudet ovat jopa 12,3 miljardia SHA-256-hajautusta sekunnissa (ja 4,5 miljardia SHA-512-hajautusta sekunnissa) kyseiselle 8 GPU-koneelle käyttäen AMD R9 290X -näytönohjaimia.
Mikä on päivitetty tilasto nyt?
per https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 SHA-256 ~ 23 miljardia hashia sekunnissa, SHA-512 ~ 8,6 miljardia hajautusta sekunnissa, käyttäen 8x Nvidia GTX 1080


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...