Kysymys:
Suosittelevatko tietoturva-asiantuntijat salasanan tallentamiseen bcryptia?
Sam Saffron
2010-09-16 05:05:57 UTC
view on stackexchange narkive permalink

Pinnan bcryptissä Niels Provosin ja David Mazieresin suunniteltu 11 vuotta vanha suojausalgoritmi salasanojen hajauttamiseksi, joka perustuu NIST: n hyväksymässä blowfish-algoritmissa käytettyyn alustustoimintoon, näyttää melkein liian hyvältä olla totta. Se ei ole altis sateenkaaripöydille (koska niiden luominen on liian kallista) eikä edes alttiina raa'ille voimahyökkäyksille.

11 vuotta myöhemmin monet kuitenkin käyttävät edelleen SHA2x: ää suolan kanssa salasanan tiivisteiden ja bcrypt is ei ole laajalti hyväksytty.

  • Mikä on NIST-suositus bcrypt (ja salasanan hajautus yleensä) suhteen?
  • Mitä tunnetut turvallisuusasiantuntijat (kuten Arjen Lenstra ja niin edelleen) sanovat bcryptin käytöstä salasanan hajautuksessa?
Aiheesta tämä on mielenkiintoinen luku: http://www.tarsnap.com/scrypt/scrypt.pdf
katso myös: http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt/1561245#1561245
Kyllä, bcryptillä on monia taitavia kannattajia, vaikka tietenkin haluat virittää iteraatioiden määrän suorituskyvyllä ja virittää muut puolustukset DoS-hyökkäyksiä ajatellen. Katso myös [Kuinka suojata salasanat turvallisesti? - IT-turvallisuus] (http://security.stackexchange.com/questions/211/how-to-security-hash-passwords) ja [Salasanan hajautus lisää suolaa + pippuria tai riittääkö suolaa?] (Http: // turvallisuus. stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough)
@tkbx Joitakin vuosia sitten, ehkä. Itse asiassa MD5: tä ei enää pidetä turvallisena. Katso esimerkiksi [MD5, jota pidetään tänään haitallisena] (http://www.win.tue.nl/hashclash/rogue-ca/) vuodelta 2008.
Tarkoitin, että kukaan turvallisuusasiantuntija suositteli bcryptia. ": P"
Nopeana huomautuksena otan henkilökohtaisesti joko bcrypt tai pbkdf2 (alustasta riippuen) ja vertailin erilaisia ​​asetuksia. Riippuen siitä, mihin käytän sitä, käytän asetuksia, jotka aiheuttavat sille tietyn ajan. Kuten työpöytäsovellukselle, haluaisin kohdistaa noin 80 ms: iin (minulla on suhteellisen nopea kannettava tietokone), tai palvelimelle, jonka olisin vertaileva palvelimella ja jonka tavoite riippuu odotetusta liikenteestä.
Vastaa otsikossa olevaan kysymykseen: Kyllä.Olen vanhempi tietoturvaarkkitehti ja kirjoitan säännöllisesti salauskäytäntöjä asiakkaillemme.bcrypt on yksi algoritmeista, joita suosittelen nimenomaan salasanan hajauttamiseen.
Nykyään, vuonna 2019, tavoittelin Argon2: n, kun hajautan salasanoja.
Viisi vastused:
#1
+631
Thomas Pornin
2011-08-19 23:30:27 UTC
view on stackexchange narkive permalink

Bcrypt: llä on paras maine, joka salausalgoritmille voidaan saavuttaa: se on ollut käytössä jo jonkin aikaa, käytetty melko laajasti, "herättänyt huomiota", mutta on silti katkeamaton toistaiseksi .

Miksi bcrypt on jonkin verran parempi kuin PBKDF2

Jos tarkastelet tilannetta yksityiskohtaisesti, näet itse asiassa joitain kohtia, joissa bcrypt on parempi kuin, sano, PBKDF2. Bcrypt on salasanan tiivistystoiminto, jonka tavoitteena on olla hidas. Tarkemmin sanottuna haluamme, että salasanan hajautusfunktio on mahdollisimman hidas hyökkääjälle , mutta ei sietämättömästi hidas rehellisille järjestelmille . Koska "rehelliset järjestelmät" käyttävät yleensä valmiita yleisiä laitteistoja (ts. "PC"), jotka ovat myös hyökkääjän käytettävissä, parasta, mitä voimme toivoa, on tehdä salasanan hajautus N kertaa hitaammin sekä hyökkääjälle että meille. Säädämme sitten N , jotta emme ylitä resurssejamme (joista suurin osa on käyttäjän kärsivällisyyttä, joka on todella rajallista).

Haluamme välttää, että hyökkääjä saattaa Käytä jotakin muuta kuin PC-laitteistoa, joka antaisi hänelle mahdollisuuden kärsiä vähemmän kuin meistä bcryptin tai PBKDF2: n merkitsemästä ylimääräisestä työstä. Etenkin ahkera hyökkääjä saattaa haluta käyttää GPU: ta tai FPGA: ta. Esimerkiksi SHA-256 voidaan toteuttaa erittäin tehokkaasti GPU: lla, koska se käyttää vain 32-bittisiä logiikka- ja aritmeettisia operaatioita, joissa GPU on erittäin hyvä. Hyökkääjä, jolla on 500 dollaria grafiikkasuoritinta, voi näin ollen "kokeilla" paljon enemmän salasanoja tunnissa kuin mitä hän voisi tehdä 500 dollarin arvoisella tietokoneella (suhde riippuu näytönohjaimen tyypistä, mutta 10x tai 20x suhde olla tyypillinen).

Bcrypt riippuu suuresti taulukon pääsyistä, jota muutetaan jatkuvasti koko algoritmin suorituksen ajan. Tämä on erittäin nopeaa tietokoneella, vielä vähemmän GPU: lla, jossa muisti on jaettu ja kaikki ytimet kilpailevat sisäisen muistiväylän ohjauksesta. Siten hyökkäyksen saama hyöty GPU: n käytöstä on melko vähäinen verrattuna siihen, mitä hyökkääjä saa PBKDF2: lla tai vastaavilla malleilla.

bcryptin suunnittelijat olivat tietoisia asiasta, minkä vuoksi he suunniteltu bcrypt ulos salakoodista Blowfish eikä SHA- * -toimintoa. He huomaavat artikkelissaan seuraavat:

Tämä tarkoittaa, että salasanatoiminnon tulisi olla mahdollisimman tehokas asetukselle, jossa se toimii. Kryptan suunnittelijat eivät tehneet tätä. Ne perustuivat salaukseen DES: ään, erityisen tehottomaan algoritmiin, joka voidaan toteuttaa ohjelmistoissa monien bittisten siirtojen vuoksi. He alensivat laitteistohyökkäyksiä osittain siksi, että salausta ei voida laskea DES-kalustolla. Valitettavasti Biham löysi myöhemmin bittilevityksenä tunnetun ohjelmistotekniikan, joka eliminoi bittitransponointien kustannukset laskettaessa monia samanaikaisia ​​DES-salauksia. Vaikka bittien yhdistäminen ei auta ketään kirjautumaan nopeammin, se tarjoaa hämmästyttävän nopeuden salasanahakujen raakoittamiseen.

mikä osoittaa, että laitteisto ja miten se pystyy on tärkeää. Jopa samalla tietokoneella kuin rehellinen järjestelmä, hyökkääjä voi käyttää bittilevytystä kokeilemaan useita salasanoja rinnakkain ja saada siitä vauhtia, koska hyökkääjällä on kokeilla useita salasanoja, kun taas rehellisessä järjestelmässä on vain yksi kerrallaan.

Miksi bcrypt ei ole optimaalisesti turvallinen

Bcrypt-kirjoittajat työskentelivät vuonna 1999. Tuolloin uhka oli mukautettu ASIC, ja porttien lukumäärä oli hyvin pieni. Ajat ovat muuttuneet; nyt hienostunut hyökkääjä käyttää isoa FPGA: ta, ja uudemmissa malleissa (esim. Xilinxin Virtex) on upotettuja RAM-lohkoja, joiden avulla he voivat toteuttaa Blowfishin ja bcryptin erittäin tehokkaasti. Bcrypt tarvitsee vain 4 kt nopeaa RAM-muistia. Vaikka bcrypt tekee kunnollista työtä vaikeuttaakseen GPU: lla parannetun hyökkääjän elämää, se ei tee kovin paljon FPGA: ta käyttävälle hyökkääjälle.

Tämä sai Colin Percivalin keksimään scryptin vuonna 2009. ; tämä on bcrypt-tyyppinen toiminto, joka vaatii paljon enemmän RAM-muistia. Tämä on edelleen uusi muotoilu (vain kaksi vuotta), eikä läheskään yhtä laajalle levinnyt kuin bcrypt; Pidän sitä liian uudena suositeltavaksi yleisesti. Mutta sen uraa tulisi seurata.

( Muokkaa: scrypt osoittautui olemaan täyttämättä lupauksiaan. Pohjimmiltaan se on hyvä sille, mitä se oli suunniteltu tekemään, Toisin sanoen suojaa tietokoneen pääkiintolevyn salausavain: tämä on käyttöympäristö, jossa hajautus voi käyttää satoja megatavuja RAM-muistia ja useita sekunteja CPU: ta. kiireiselle palvelimelle, joka todentaa saapuvat pyynnöt, suorittimen budjetti on paljon matalampi, koska palvelimen on pystyttävä palvelemaan useita samanaikaisia ​​pyyntöjä kerralla, eikä hidastumaan indeksointiin satunnaisissa huippukuormituksissa; mutta kun scrypt käyttää vähemmän suorittimia, se käyttää myös vähemmän RAM-muistia, tämä on osa toiminnon toimintaa sisäisesti määritelty. Kun hajautuslaskennan on oltava valmis muutaman millisekunnin sisällä työstä, käytetty RAM-määrä on niin pieni, että salaus muuttuu teknisesti heikommaksi kuin bcrypt.)

Mitä NIST suosittelee

NIST on julkaissut erikoisjulkaisun SP 800-132 hash-salasanojen tallentamisesta. Pohjimmiltaan he suosittelevat PBKDF2: ta. Tämä ei tarkoita, että he pitävät bcryptia epävarmana; he eivät sano mitään bcryptistä. Se tarkoittaa vain sitä, että NIST pitää PBKDF2: ta "riittävän turvallisena" (ja se varmasti on paljon parempi kuin yksinkertainen hash!). Lisäksi NIST on hallinnollinen organisaatio, joten heidän on vain rakastettava kaikkea, mikä perustuu jo "hyväksyttyihin" algoritmeihin, kuten SHA-256. Toisaalta bcrypt tulee Blowfishista, joka ei ole koskaan saanut minkäänlaista NIST-siunausta (tai kirousta).

Vaikka suosittelen bcryptia, noudatan silti NISTiä siinä, että jos otat PBKDF2: n käyttöön ja käytät sitä oikein ( "korkealla" iterointiluvulla), on melko todennäköistä, että salasanojen tallennus ei ole enää pahin tietoturvaongelmasi.

Mikä on "suuri" iteraatioluku? Enkä oikein ymmärrä, miksi suosittelet edelleen bcryptia PBKDF2: n kautta
TL; DR: bcrypt on parempi kuin PBKDF2, koska PBKDF2: ta voidaan nopeuttaa paremmin GPU: illa. Sellaisena PBKDF2 on helpompi raakaa voimaa offline-tilassa kuluttajalaitteiden kanssa.
@ExplosionPills Nyrkkisääntöni "suurelle" iterointiluvulle on: mahdollisimman suuri aiheuttamatta liikaa käyttäjiä valittamaan viivästyksestä. Viritän yleensä bcrypt / pbkdf2: n ottamaan tuotantopalvelimelleni noin 250–500 ms (1-2 sekuntia järjestelmänvalvojan tileille), kun se on vähäisessä kuormituksessa. Tämä käytäntö näyttää seuraavan OpenBSD: n suosittelemia bcrypt-asetuksia ja muita löydettyjä asiayhteydestä riippuvia suosituksia.
Ei sanaakaan scryptistä? :)
@EliCollins: Olen täällä melko utelias - voisiko korkean iterointilukeman käyttö tuoda esiin mahdollisuuden DDOS-hyökkäyksiin palvelinta vastaan? Jos esimerkiksi lähetän satoja kirjautumisyrityksiä palvelimelle samanaikaisesti, palvelin ylikuormittuu yrittäessään hajauttaa kaikki salasanat. Onko olemassa keinoja välttää tämä mahdollinen ongelma?
@GeorgeEdison Olen myös miettinyt tätä kysymystä, enkä ole löytänyt hyvää vastausta. 1) Voit rajoittaa kirjautumissivua kuormituksen perusteella, mutta se ei skaalaa hyvin. 2) pura hajautus erilliselle palvelimelle, joten DDOS vaikuttaa vain samanaikaisiin sisäänkirjautumisiin, mutta se on vain vaihtoehto 1: n muunnos. 3) Lisää [hashcash] (http: // fi. wikipedia.org/wiki/Hashcash) -tyylinen todiste työstä kirjautumistunnuksellesi, mutta se ei auta paljoa botnetia vastaan. 4) DDOS: n on ensin löydettävä kelvollinen käyttäjätili, joten viivästytä virheellisiä käyttäjävirheitä uni () -kutsulla vastaamaan hajautusaikaa.
@GeorgeEdison välttääksesi DDOS: n, tarkista käyttäjänimi ennen salasanan tarkistamista. Jos sitten on ollut useita epäonnistuneita kirjautumisyrityksiä peräkkäin tälle käyttäjälle (esimerkiksi 10 heistä), hylkää salasana tarkistamatta sitä edes, ellei tili ole "jäähtynyt" muutaman minuutin ajan. Tällä tavalla tili voi olla DDOS-tiedosto, mutta ei koko palvelin, ja se tekee jopa hirvittävän heikoista salasanoista mahdottomia raakaa voimaa ilman offline-hyökkäystä.
@AbhiBeckert Mitä tapahtuu, jos laillinen käyttäjä jää kiinni yrittäessään kirjautua sisään, kun hänen tilinsä on botnetin hyökkäyksen kohteena? (Vastaus: DOS). Huonojen käyttäjänimien salasanatarkistuksen ohittaminen tarjoaa myös ajoitukseen perustuvan oraakelin, joka kertoo hyökkääjälle olemassa olevat tilit. Jos säilytät IP-osoitteen onnistuneille kirjautumisille (on hyviä syitä olla tekemättä), voit antaa niille IP-osoitteet etusijalle ja tarkistaa salasanan, vaikka käyttäjänimi olisi "lukittu".
NISTin siunauksella ei ole samaa painoa kuin aikaisemmin. http://www.wired.com/threatlevel/2013/09/nsa-backdoor/all/ (epäilen, että tämä pätee PBKDF2: een, mutta se on ajattelemisen aihetta.)
@TerisRiel En välitä, jos käyttäjän tili menee offline-tilaan DOS-hyökkäyksen vuoksi. Todellisessa maailmassa sitä ei todellakaan tapahdu, ja jos se tapahtuu ... no, se on parempi kuin hakkerointi.
Toki, DOS-käyttäjä, he saavat jonkin varoituksen, joka varoittaa heitä siitä, että jotain on tekeillä (jos, kuten @Abhi Beckert sanoo, sitä tapahtuu koskaan jopa tosielämässä). Vältä oraakkelihyökkäystä nukkumalla epäonnistuneet käyttäjätunnukset salasanan tarkistamiseen tarvittavan ajan.
onko scrypt vielä liian uusi käytettäväksi?
@JanusTroelsen:-komentosarja ei osoittautunut yhtä hyväksi kuin odotettiin; Lisäsin vastauksen vastaavan kappaleen.
BCrypt näyttää olevan murtunut nyt - vaikuttaako tämä vastaukseen? http://www.itproportal.com/2015/09/11/11-million-unbreakable-ashley-madison-passwords-broken/
@MatthewMartin: olet lukenut artikkelin väärin - bcrypt ei ole murtunut ollenkaan; hyökätyt salasanat hajautettiin kahdesti, kerran bcryptillä ja kerran kotitekoisella, heikossa MD5: n kutsumisessa. Tutkijat rikkoivat heikon kotitekoisen hajautuksen MD5: n perusteella (toisin sanoen he eivät "rikkoneet" sitä, he vain yrittivät paljon salasanoja, kunnes vastaavuus löydettiin, ja se oli nopeaa, koska kotitekoinen hajautus oli erittäin nopeaa ja suolatonta).
@ThomasPornin Joten pohjimmiltaan he päättivät tehdä bcryptistä "vielä turvallisemman"? Nyrkkisääntöni on "Jos tämä parannus on niin hyvä, asiantuntijat olisivat löytäneet sen kauan ennen minua."
@corsiKa: kyseessä oli pikemminkin se, että kaksi kehittäjää työskenteli samoilla käyttäjän salasanoilla, mutta eivät puhuneet keskenään; yksi tietää mitä bcrypt on, toinen ei tiedä. Tässä on kyse yleisestä säännöstä: jos hyökkääjällä on mahdollisuus valita etsittävän tiedon saamiseksi kaksi tapaa, hän valitsee hänelle helpoimman.
Kuinka ajan tasalla tämä vastaus vuonna 2016 on? Esimerkiksi kuinka Argon2 (joka voitti salasanan hajautuskilpailun) pysyy pysyvänä verrattuna PBKDF2: een, bcryptiin jne.? Koska tämä on laajasti luettu viesti, olisi hyvä nähdä säännöllisiä päivityksiä tähän vastaukseen, jotka joko vahvistavat vastauksensa tai päivittävät suosituksensa.
@ThomasPornin Minusta tuntuu, että kappale Argon2: sta olisi kirsikka tämän jo erinomaisen vastauksen päällä.
@joshreesjones Mielestäni ansaitsee erillisen kysymyksen, koska tämä kysymys ja vastaus koskevat nimenomaan bcryptia.
Oletko turing täydellinen?
Ehdotukseen on ensin tarkistettava käyttäjänimi ja sitten nopeasti epäonnistuttava, jos käyttäjätunnusta ei ole - se tarkoittaa, että hyökkääjä voi oppia, mitkä käyttäjänimet ovat olemassa ja mitkä eivät.Jotta et vuotaisi sitä, haluat, että jokainen salasanan tarkistus on yhtä pitkä.
@MikkoRantalainen Modern GPU: t (jopa vuonna 2012, kun kirjoitit kommentin) voivat helposti käsitellä bcryptia.Vaatimus on 4 KiB nopeaa muistia.Tämä tarkoittaa, että jokaisella GPU-varjostimella on oltava vähintään niin paljon muistia allokoituna globaalista muistivarastosta.GPU, jossa on esimerkiksi 500 varjostinta ja 1 GiB VRAM-muistia, voi antaa jokaiselle varjostimelle täydellisen ** 2 MiB ** muistin.Jopa se, jolla on 256 Mt VRAM-muistia (mikä on hyvin vähän), voi kohdistaa yli sata kertaa enemmän muistia kuin bcrypt vaatii 500 varjostimelle.Nyt toisaalta ASIC: t ...
@forest bcryptin ja GPU: iden tarkoitus ei ole, että bcrypt vaatii valtavasti muistia.Jos haluat käyttää paljon muistia, katso scrypt.Bcrypt-algoritmi koskee RAM-muistin satunnaista käyttöä, joka ei ollut GPU: iden vahvuus.Uudemmilla grafiikkasuorittimilla on vähemmän ongelmia, mutta PBKDF2 on silti helpompi tehtävä grafiikkasuorittimille.
@MikkoRantalainen Onko satunnainen käyttö voimakkaasti avainkohtainen?Satunnainen käyttö yhdellä 4 KiB: n muistisivulla tuntuu siltä, että GPU: lle ei olisi erityisen vaikeaa, vaikka GDDR5-muistilla olisi suurempi viive kuin DDR3: lla tai DDR4: llä.
@forest En ole varma, riippuuko pääsykuva avaimesta.Https://github.com/freedomofpress/securedrop/issues/180#issuecomment-29662610 mukaan https://www.usenix.org/system/files/conference/woot14/woot14-malvoni.pdf https: // crypto.stackexchange.com/a/401/1267 ja https://crypto.stackexchange.com/a/35352/1267 näyttää siltä, että GPU: lla on ongelmia näennäissatunnaisten pääsymallien kanssa, jotka * muokkaavat * muistia, ja sen seurauksena GPU: t eivät ole nopeampibcrypt kuin vastaavasti hinnoitellut suorittimet.
@MikkoRantalainen Voi mielenkiintoista!Joten näyttää siltä, että jokaisella ytimien ryhmällä on oma jaettu muisti (joka on erittäin nopea), samoin kuin päämuisti (joka on hidas samanaikaisessa käytössä).Ainakin vuonna 2011 jaettu muisti oli liian pieni 4 KiB: n pitämiseen.Ihmettelen, onko se muuttunut nykyaikaisissa näytönohjaimissa.
Katso myös: "Ilmapallojen hajautus: muistikova toiminto, joka tarjoaa suojan peräkkäisiltä hyökkäyksiltä" https://eprint.iacr.org/2016/027.pdf (erityisesti luku 5)
Olen noob.Joku kertoo minulle, miksi minun ei pitäisi vain ensin kirjoittaa salasanaani ja sitten suorittaa se bcryptin tai scryptin kautta.Mikään hyökkääjä ei aio tarkistaa molempia, jos suurin osa Internetistä ei tee sitä.
#2
+104
Giu
2010-09-16 12:39:02 UTC
view on stackexchange narkive permalink

bcryptillä on merkittävä etu yksinkertaisesti suolattuun SHA-256-hashiin nähden: bcrypt käyttää muokattua avaimen asennusalgoritmia, joka on ajankohtainen melko kallista. Tätä kutsutaan avaimen vahvistukseksi, ja se tekee salasanasta turvallisemman raakajoukkohyökkäyksiä vastaan, koska hyökkääjä tarvitsee nyt paljon enemmän aikaa kunkin mahdollisen avaimen testaamiseen.

Blogitekstissä nimeltä " Enough With Sateenkaaritaulukot: Mitä sinun tarvitsee tietää suojatuista salasanajärjestelmistä ", jotka suosittelen henkilökohtaisesti lukemaan, kirjoittaja ja tietoturvatutkija Thomas Ptacek suosittelee bcryptin käyttöä.

Henkilökohtaisesti , Olen viime aikoina katsonut PBKDF2 -sovellusta, joka on avaintulostusfunktio, joka käyttää näennäissatunnaisfunktiota (esim. Salauksen tiivistettä) syöttösalasanaan yhdessä suolan kanssa ja johtaa sitten avaimen toistetaan prosessi niin monta kertaa kuin on määritetty. Vaikka se on avainjohdontatoiminto, se käyttää avainvahvistuksen periaatetta ytimessään, mikä on yksi monista asioista, joihin sinun on pyrittävä, kun päätät, kuinka luoda salasanan tiiviste.

Lainaan Thomas Ptacek yllä olevasta linkitetystä viestistä:

Nopeus on juuri sitä mitä et halua salasanan tiivistystoiminnossa.

Bcryptin perusoletus on, että se on hidas, mutta se on vain oletus, voi olla olemassa heikkous, joka antaa mahdollisuuden lyhentää suoritusaikaa, tai laitteistokehitys voi ohittaa hitauden (sama kuin Scryptillä). Toisaalta PKBDF perustuu hyvin testattuun hashiin, jolle on jo olemassa melko nopea lähes optimaalinen laitteisto, mikä tarkoittaa, että aika- ja monimutkaisuusparametrit ovat hyvin tunnettuja (ja niitä voidaan hyödyntää toistamisen avulla). PKBDF-puolustajat tietävät tarkalleen, mitä hyökkääjät voivat tehdä suuruusluokassa, bcrypt-puolustajat eivät.
@EricGrange: on totta, että PKBDF-puolustajat tietävät mitä hyökkääjät voivat tehdä.Valitettavasti hyökkääjät voivat tehdä vähintään 10-20x nopeammin kuin puolustajat.Defender haluaa käyttää bcryptia, koska se * näyttää tällä hetkellä antavan paljon vähemmän reunaa hyökkääjälle.Pohjimmiltaan bcryptin fanit ajattelevat, että algoritmi näyttää riittävän hyvältä luottamaan ja se tekee pelikentästä tasaisemman puolustajalle ja hyökkääjälle.Jos luulet, että vähintään 10-20x suorituskyvyn lisääminen hyökkääjälle on kunnossa, niin PKBDF on parempi valinta, koska kompromissit ymmärretään paremmin.
@EricGrange Tämä pätee KAIKKIIN algoritmeihin.Ajan myötä ja enemmän salausta analysoitaessa voimme luottaa yhä enemmän (mutta emme koskaan täysin varmoja) siitä, että tietyllä algoritmilla ei ole erityistä heikkoutta.Ajatus siitä, että voimme varmasti tietää PBKDF2: n riskit, mutta emme bcryptia, on järjetön.
Https://www.usenix.org/system/files/conference/woot14/woot14-malvoni.pdf mukaan hyökkääjä on vain 2 kertaa nopeampi mukautetuilla laitteistoilla kuin yleistä i7-suorittinta käyttävä bcrypt defender.Näyttää paljon paremmalta kuin hyökkääjä on 10-20x nopeampi PKBDF: n kanssa kuin puolustaja.
#3
+23
Steven Sudit
2010-09-18 06:51:13 UTC
view on stackexchange narkive permalink

Luulen, että Guin ehdotus PBKDF2: sta on ansainnut, vaikka tiedän, että Rook on eri mieltä. Jos vain heillä olisi selkeä perustelu!

Siitä huolimatta ei ole mitään syytä käyttää suolattua SHA-256-hashia verrattuna HMAC-SHA256: een. HMAC: n etuna on laajennushyökkäysten estäminen.

+1 HMAC: n mainitsemisesta, jonka unohdin mainita kokonaan turvallisemmaksi vaihtoehdoksi yksinkertaisesti suolatulle SHA-256-hashille. Pituuden pidennyshyökkäykset ovat tunnettuja; Flickr-sovellusliittymä oli kerran vaarantunut, koska sillä oli tapana allekirjoittaa sovellusliittymäkutsuja käyttäen MD5 (salainen + argumenttilista) (katso "[Flickrin API-allekirjoituksen väärentämisen haavoittuvuus] (http://netifera.com/research/flickr_api_signature_forgery.pdf)" [ PDF] lisätietoja)
Kuinka HMAC on merkityksellinen salasanojen palauttamattomalle tallennukselle?
@curiousguy (Parempi myöhään kuin ei koskaan ...) Suolalla tiivistetyn salasanan tallentaminen voidaan tehdä laskemalla [HMAC] (http://fi.wikipedia.org/wiki/Hash-based_message_authentication_code) ja käyttämällä salasanaa HMAC: na. -näppäin ja suola HMAC-sanomana. Tämä on turvallisempaa kuin `` H (suola || salasana) '' naiivin laskeminen, vaikka todellinen salasanan hajautusfunktio, kuten bcrypt, on suositeltava.
@curiousguy HMAC on PRF, jota käytetään yleisimmin PBKDF2: ssa. Joten älä käytä paljasta HMAC: ää. Käytä PBKDF2 (HMAC-SHA256 tai HMAC-SHA512), bcrypt tai scrypt. Se siitä. Älä keksi tai käytä mitään muuta. Mukautetut järjestelmät ovat varmasti vääriä. Nämä kolme ovat hyvin tarkastettuja ja helppokäyttöisiä. Huomaa, että PBKDF2 on haavoittuvin laitteistokiihdytetyille sanakirjahyökkäyksille ja scrypt on vähiten haavoittuva.
#4
+21
PBKDF2
2012-07-11 21:30:35 UTC
view on stackexchange narkive permalink

NIST on Yhdysvalloissa toimiva hallitusorganisaatio ja noudattaa siten FIPS (Yhdysvallat) -standardeja, jotka eivät sisällä puhalluskaloja, mutta sisältävät SHA-256 ja SHA-512 (ja jopa SHA-1 ei-digitaalista allekirjoitusta varten) sovellukset, jopa NIST SP800-131A: ssa, joka kuvaa kuinka kauan kutakin vanhempaa algoritmia voidaan käyttää mihin tarkoitukseen).

Kaikille yrityksille, joiden on noudatettava Yhdysvaltain NIST- tai FIPS-standardeja, bcrypt ei ole kelvollinen vaihtoehto . Tarkista tietysti jokaisen maan lait ja asetukset erikseen, jos harrastat siellä liiketoimintaa.

PBKDF2 on hieno; todellinen temppu on saada Tesla (GPU-pohjaiset) -kortit rehellisiin palvelimiin, jotta iteraatiot voidaan tehdä riittävän korkealle kilpailemaan GPU-pohjaisten crackerien kanssa. PBKDF2: lle vuonna 2012 OWASP suosittelee vähintään 64 000 iteraatiota Password Storage -huijausarkistoon, joka on kaksinkertaistettu kahden vuoden välein.

Minusta tuntuu, että scryptin tai bcryptin (ohjelmiston vaihtaminen) käyttö on helpompaa kuin kalliiden (etukäteen ja energiakustannuksiltaan) laitteistojen lisääminen miljooniin palvelimiin. Ylemmällä tasolla mikä tahansa näppäinten venyttämistoiminto on vain yritys lisätä salasanaan entroopia. Jos (ja vain jos) salasana on tarpeeksi vahva aluksi (esim. 128-bittinen satunnaisluku, joka on koodattu 10 diceware-sanaksi), yksi PBKDF2-iterointi on riittävä suoja.
* Salausfunktioiden tai PBKDF2: n tarkoituksena on tallentaa salasana niin kauas, että alkuperäisen salasanan löytäminen on erittäin vaikeaa. Ne eivät tee salasanasta vahvempaa. Yhden PBKDF2-iteraation avulla on helppo arvailla voimaa arvaamaan salasana. Jos se kestää sekunnin CPU-aikaa per arvaus, raakasta pakottamisesta tulee epärealistista.
GPU ei auta verkkopalvelinta hajauttamaan yhden tai muutaman salasanan nopeasti. Se auttaa vain hajauttamaan useita (tuhansia) salasanoja samanaikaisesti.
Miksi NIST ajattelee, että PBKDF2 on kunnossa, kun bcryptia on vaikeampi torjua paikallisesti?Tarkoittaako tämä sitä, että jos sinulla on palvelu, joka salaa `` bcrypt '' -palvelua, niin Yhdysvaltain yritykset eivät saa käyttää palvelua?
NSA saattaa painostaa NIST: ää ottamaan käyttöön takaovia (esim. Https://www.wired.com/2013/09/nsa-backdoor/).Ole varovainen NIST-suositusten suhteen ja tarkista aina itsenäiset tutkijat.
#5
+17
David C. Bishop
2016-01-07 04:18:25 UTC
view on stackexchange narkive permalink

Saattaa olla syytä tarkastella Argon2: ta, joka voitti Salasanan hautakilpailun.

Tervetuloa vaihtamaan tietoturvapinoa. Koska tämä vastaus ei suoraan osoita bcryptia, se saattaa olla parempi jättää kommentiksi. Kiitos, että käytit aikaa vastata kysymykseen, ja toivon, että sinulla on täällä positiivinen ja informatiivinen kokemus!
Katsoin tätä kilpailua, ehdokkaiden [luettelo] (https://password-hashing.net/submissions.html) ei sisällä bcrypt, scrypt ja PBKDF2.
@AmirForsati - Se sisälsi johdannaisia bcryptistä (lehtikala) ja scyptistä (yescrypt).Se on mahdollista / todennäköisesti johtuu myös PBKDF2: sta, mutta en tarkastellut suurinta osaa niistä tarpeeksi tarkasti kertoa.


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