Fråga:
“Officiellt uttalande” på php.net: CRYPT_BLOWFISH är den starkaste hashalgoritmen. Varför?
Sliq
2013-05-26 00:14:18 UTC
view on stackexchange narkive permalink

Först: Jag ställde den här frågan på stackoverflow och ombads vänligen att lägga upp den här igen. Se den ursprungliga frågan här.

Enligt [tidiga] doc-sidor i det nya PHP 5.5-lösenordshash / krypterings-API använd den använda algoritmen CRYPT_BLOWFISH är "starkaste algoritmen som för närvarande stöds av PHP" (gör en sökning i fulltext för att hitta offerten på sidan).

Min fråga är: Kan detta bevisas med några siffror, riktmärken etc.?

Enligt PHP: s crypt () doc-sida CRYPT_BLOWFISH använder 22 kolsalt och genererar en 60-kolshash, och CRYPT_SHA512 använder ett 16-kolsalt och genererar en 118-char-hash. Båda algoritmerna har förändrade kostnadsfaktorer, så vid första anblicken ser SHA512 starkare ut (för längre).

Bara en aning: sha är utformad för att vara snabb, eftersom den är för validering av meddelandets integritet. Blowfish är utformad för att vara långsam, det är därför det är fantastiskt för lösenord.
-1 Du har redan fått några bra och tillfredsställande svar på Stackoverflow. Inget behov av tvärpost.
@Maerlyn Ja, jag vet. Du slänger "hashing" och "password hashing / salting" tillsammans. Det är samma kommentar varje gång. PHP: s kryptofunktion () fokuserar tydligt på lösenordshashing, men ger fortfarande möjlighet att välja mellan många olika algoritmer. Jag menar, det finns ingen riktig dokumentation om det, ingenting förklarar vilken algo du ska använda och varför.
@Adnan det stängdes som utanför ämnet där och det skulle vara bra att ha andra som letade efter denna säkerhetsrelaterade information för att kunna hitta den på vår webbplats.
@Adnan Svaren på SO är ganska svaga och eftersom det är stängt kan ingen skicka ett bättre.
@Maerlyn För att få detta i ett bevisbart, reproducerbart förhållande: I mina riktmärken, med de officiella exemplen från krypt () doc-sidan, vinner BLOWFISH som den långsammaste algoritmen, men bara mycket nära SHA512. 100 slingor hasning + saltning med standardkostnadsfaktorerna är 1,9sek för BLOWFISH, 1,35sek för SHA512. Tyvärr är argumentet "designad för att vara snabb / långsam" inte riktigt giltigt här. Och om vi tittar djupare på kostnadsfaktorerna (kan vi jämföra "04" bas-2-logaritm i blowfish till 5000 omgångar i sha512?), Är jag ännu mer osäker på om BLOWFISH verkligen är långsammare än SHA512.
Designad för att vara långsam på mycket parallell hårdvara, till exempel GPU: er. Ditt test är bara lika relevant som chansen att en angripare använder samma eller liknande hårdvara som du var för att tvinga lösenordshash. För det kontot skulle det ta tid i dina resultat att prova ett ** enstaka ** möjligt ingångsvärde. Klart omöjligt, så angriparen skulle på något sätt försöka parallellisera denna process. GPU: er är ett uppenbart val, men (åtminstone aktuell hårdvara) misslyckas med att bli mycket snabbare med BLOWFISH på grund av den stora interna RAM-tabellen den använder. Se [detta svar] (http://security.stackexchange.com/a/6415/20074) för mer information.
Inte säker på om mina tankar är användbara eller inte :-p, men även om BLOWFISH inte är långsammare för speciell hårdvara, använder `crypt ()`, till lika tidskostnadskostnad = 10 (1024 omgångar) av BLOWFISH, tog det 40 000 rundor med SHA-512 med PHP: s krypteringsmetod. En kostnad på 13 (8196) krävde 300 000 rundor SHA-512. Med det i åtanke tror jag att det är mer troligt att den genomsnittliga programmeraren av misstag skulle välja en högre kostnad med BLOWFISH än de skulle använda SHA512 eftersom varje ökning fördubblar tidskostnaden.
Två svar:
CodesInChaos
2013-05-26 03:20:37 UTC
view on stackexchange narkive permalink
  • vi pratar om starkast för lösenordshashing här. En bra hash för allmänt ändamål behöver inte vara ett bra lösenordshash, och vice versa.
  • Hashens längd är irrelevant när den överskrider en viss tröskel. En attack före bilden på en n-bit-hash kostar 2 n . För en 128-bitars hash är detta helt omöjligt.
  • bcrypt med en exponentiell notation för kostnad och sha512-crypt med en linjär notation är irrelevant. Att jämföra deras CPU-kostnad med standardparametrar är också meningslöst.

    I praktiken väljer du en tidsbudget, säg 10ms. Då justerar du hashens kostnadsfaktor för att matcha den budgeten. Så om en angripare använde samma hårdvara som försvararen, skulle alla anständiga lösenordshasar vara desamma.

  • En angripare använder annan hårdvara än försvararen. Försvararen använder en vanlig CPU. Angriparen använder åtminstone en GPU, eller om det är en avancerad angripare kanske en FPGA eller ASIC.

    Skillnaden mellan olika hash är hur bra de körs på olika typer av hårdvara. BCrypt behöver några kilobyte riktigt snabbt minne. Detta fungerar bra med vanliga CPU: er, men fungerar inte bra med GPU: er. Så bcrypt är mycket GPU ovänligt. Med FPGA är fördelen med bcrypt mindre, särskilt om den har integrerat RAM. Men det är fortfarande lite bättre.

  • Ett enkelt riktmärke som du kan ställa in kandidatens hashes till samma kostnad. Kör sedan en GPU-baserad lösenordssmällare, som hashcat eller john-the-ripper och kontrollera dess prestanda. Jag förväntar mig att bcrypt har en mycket lägre hashrate.
  • Det finns också ett annat intressant lösenordsschema som heter scrypt. Den använder större mängder minne och om din tidsbudget är stor är den betydligt bättre än bcrypt eller SHA512-crypt.
Enos D'Andrea
2014-12-20 16:09:51 UTC
view on stackexchange narkive permalink

Det "matematiska beviset" är att du kan välja N godtyckligt: ​​

  t (bcrypt) * (2 ^ N) >> t (sha)  

Den sista hash handlar om att undvika kollisioner, så du är säker så länge

  hash >> lösenord  

Saltet handlar om att undvika regnbågsbord , så att du är säker så länge som

  (regnbågsstorlek) * (salt) >> (angriparens lagringsutrymme)  


Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...