[Løst] PHP Kryptering

[Rigo]

Hallo! Så jeg bruker et CMS som har både SHA1 og MD5 kryptering, og ønsker å bytte over til et CMS som kun bruker MD5. Er dette mulig, eller lar ikke dette seg gjøre?

 

Mitt CMS sin krypteringmetode

return sha1(md5($text));

 

Ny CMS sin krypteringsmetode

return md5($password);

 

Det som trolig forvirrer meg mest er at lengden på passordene jeg har nå ikke stemmer med MD5 eller SHA1, så er det en blanding? Har ikke mye erfaring innenfor dette, men passordene ser ihvertfall sånn her ut. Ikke får jeg dekryptert dem heller.

8cbba150c59e38898a29e15294722cda93a16117

Endret 8. juni 2012 av Rigo

[nomore]

Det første punktet på agendaen er å lære seg hva MD5 og SHA1 er, og at dette ikke er kryptering

[etse]

Man kan ikke dekryptere sha1 / md5 hashede passord. Det er ikke kryptering i det hele tatt, det er hashing-funksjoner. Noe som rent matematisk betyr en mange til 1 funksjon, så du kan ikke gå motsatt vei.

 

Eneste muligheten er å bruteforce seg frem til man finner ut av passordet er; men dette vil ta lang tid for vanskelige passord.

 

Edit: Vil forresten legge til at man alltid burde "salte" passord som blir kryptert i databasen slik at folk ikke kan bruke ferdig-genererte rainbow tables for å finne passordet.

Endret 8. juni 2012 av etse

[Ernie]

Salt hjelper jo såklart, men nå begynner man ærligtalt å nærme seg en tid hvor sha1 rett og slett er for lett algoritme. Med rett utstyr kan det gå skremmende fort unna. Jeg har sett troverdige påstander på enheter som klarer 100 mill. sha1-hash pr. sekund. Da snakker vi om en enkelt enhet. Fordel det over 10 stk. og du har 1 milliard sha1-hash pr. sekund, og det ganske billig. Kompleksiteten på et 8 tegn langt passord med store og små bokstaver (a-z) + tall er ca 200 billioner, men tar altså allikevel bare drøyt 60 timer å knekke. Med salt legger man ikke til kompleksiteten i passordet i og med at dette fort er kjent når man kjenner hash av passordet (aka. noen har f.eks. kommet seg inn i databasen).

 

Derfor vil jeg anbefale å skrote sha1 og md5 til fordel for litt mer tungvektere. Sha256 er nok et godt skritt i riktig retning (hash(...) har støtte for det). Samtidig bør man (fortsette å) bruke salt i passordet som er unikt pr. bruker og pr. hash-generering. I tillegg bør man også vurdere passord-policy og hvorvidt man bør kreve passord på minst 8 tegn som inkluderer små og store bokstaver, tall og spesialtegn. Det vil øke kompleksiteten såpass at privatpersoner ikke umiddelbart har midler til å knekke en passord-hash man genererer.

 

Redigering: Man skal ikke se bort fra at det finnes enkeltenheter som kan generere over 2 millard sha1-hash pr. sekund også. Litt googling tilsier at mange har mye interessant å bidra med på den fronten. md5 er forøvrig en faktor 2-3 ganger verre på dette området og er dermed 2-3 ganger raskere å knekke.

Endret 8. juni 2012 av Ernie

[Rigo]

Okei, så det er hashing. Det er altså ingen måte jeg kan få "porta" brukerne over? For om jeg endrer Passord funksjonen på det nye CMS'et til dette

return sha1(md5($password));

vil det ikke funke å logge inn, selv om jeg kopierer over passordet fra det gamle CMS'et.

 

Jeg må altså bare vrake alt jeg har av brukere og starte på ny? Har drøyt 2500 brukere, og har ikke mulighet til å sitte å endre hvert eneste passord.

Endret 8. juni 2012 av Rigo

[TheClown]

Hvorfor endrer du ikke det nye CMS-systemet til å gjøre krypteringen på samme måte?

 

Det er allikevel ingen garanti for at dette vil fungere. Hva med all annen informasjon som ligger i databasene? Vet du at dette kommer til å fungere i det nye CMS-systemet? Og pass på at innloggingen salter og gjør alt likt i såfall.

 

Å endre det nye tilsvarende det gamle er mye bedre enn å konverter passordene til den "nye" metoden.

[Rigo]

Vel, det ville ikke funke når jeg prøvde å gjøre så det nye CMS'et hadde samme hash-system. Ville ikke la meg logge inn..

Endret 8. juni 2012 av Rigo

[LostOblivion]

Problemet ditt, er at passordene som ligger lagret, ble hashet med

sha1(md5($password));

når de ble lagt inn, og da må du også bruke denne når de skal logge seg inn. Om du skal skifte passord-hash, må du be alle skifte passord, men det er vanskelig siden de da først må logge seg inn.

 

Hvorfor er du interessert i dette i utgangspunktet?

Endret 8. juni 2012 av LostOblivion

[ZeRKoX]

Letteste måten er å drite i at det er forskjellig hash, og heller be brukerene om å bruke en "glemt passord" funksjon etter oppgradering av cms-et, for å få laget nytt passord.

[xibriz]

Hvis det du har prøvd ikke fungerer må du sjekke om det er gjort noe med $text i forkant i det første CMS. Kanskje det er saltet? Isåfall trenger du bare å salte på samme måte i det nye CMS.

[Bolson]

Letteste måten er å drite i at det er forskjellig hash, og heller be brukerene om å bruke en "glemt passord" funksjon etter oppgradering av cms-et, for å få laget nytt passord.

 

Helt korrekt - dette er i realiteten eneste velfungerende måten. Og jeg snakker av erfaring.

 

Ellers anbefaler jeg at man bruker salted hash (salted md5, salted sha1 osv) i det nye CMS-et (om det er mulig). Noe det bør være. Hverken sha1, md5 eller kombinasjon av disse er i realiteten godt nok (om man da ikke setter minimum passordlengde til 10 - 12 tegn).

[etse]

Salt hjelper jo såklart, men nå begynner man ærligtalt å nærme seg en tid hvor sha1 rett og slett er for lett algoritme. Med rett utstyr kan det gå skremmende fort unna. Jeg har sett troverdige påstander på enheter som klarer 100 mill. sha1-hash pr. sekund. Da snakker vi om en enkelt enhet. Fordel det over 10 stk. og du har 1 milliard sha1-hash pr. sekund, og det ganske billig. Kompleksiteten på et 8 tegn langt passord med store og små bokstaver (a-z) + tall er ca 200 billioner, men tar altså allikevel bare drøyt 60 timer å knekke. Med salt legger man ikke til kompleksiteten i passordet i og med at dette fort er kjent når man kjenner hash av passordet (aka. noen har f.eks. kommet seg inn i databasen).

 

Derfor vil jeg anbefale å skrote sha1 og md5 til fordel for litt mer tungvektere. Sha256 er nok et godt skritt i riktig retning (hash(...) har støtte for det). Samtidig bør man (fortsette å) bruke salt i passordet som er unikt pr. bruker og pr. hash-generering. I tillegg bør man også vurdere passord-policy og hvorvidt man bør kreve passord på minst 8 tegn som inkluderer små og store bokstaver, tall og spesialtegn. Det vil øke kompleksiteten såpass at privatpersoner ikke umiddelbart har midler til å knekke en passord-hash man genererer.

 

Redigering: Man skal ikke se bort fra at det finnes enkeltenheter som kan generere over 2 millard sha1-hash pr. sekund også. Litt googling tilsier at mange har mye interessant å bidra med på den fronten. md5 er forøvrig en faktor 2-3 ganger verre på dette området og er dermed 2-3 ganger raskere å knekke.

Du har rett i at det ikke øker kompleksiteten på passordet; men det gjør at

1: Du kan ikke bruke prekompilert rainbowtables

2: Siden hvert passord har ulik salt må man generere en ny table for hvert enkelt passord.

 

Det betyr at for en database med 100 brukere vil det ta like lang tid å knekke 1 bruker fra begge systemene. Men i et saltet system må du starte helt på nytt igjen for å knekke neste passord som har en annen salt; mens i et usaltet system bare kan fortsette der du slapp.

 

- Men dette er du nok helt klar over.

 

I de fleste tilfeller er MD5 med salt mer enn bra nok, - spesielt om folk har passord av fornuftig lengde. (Ref XKCD #936)

[Ernie]

Du har rett i at det ikke øker kompleksiteten på passordet; men det gjør at

1: Du kan ikke bruke prekompilert rainbowtables

2: Siden hvert passord har ulik salt må man generere en ny table for hvert enkelt passord.

 

Det betyr at for en database med 100 brukere vil det ta like lang tid å knekke 1 bruker fra begge systemene. Men i et saltet system må du starte helt på nytt igjen for å knekke neste passord som har en annen salt; mens i et usaltet system bare kan fortsette der du slapp.

 

- Men dette er du nok helt klar over.

 

I de fleste tilfeller er MD5 med salt mer enn bra nok, - spesielt om folk har passord av fornuftig lengde. (Ref XKCD #936)

La meg bare si det rett ut sånn at det er mulig å skjønne hvor kritisk det er å bli kvitt MD5 og SHA1:

Ja, man må starte på nytt når man bruker salt, men det skal allikevel ikke mye til for å knekke enkeltpassord når man kan generere milliarder av MD5 og SHA1-hash-er hvert sekund med FPGAer og GPUer (begge kan kombineres sammen med CPUer med flere kjerner for å oppnå maksimal ytelse). Spesielt sistnevnte er et meget raskt bruteforce-verktøy som gjør at rainbow-table begynner å miste litt mening i forhold til MD5 og SHA1.

 

Med andre ord: De fleste av oss kan knekke betraktelig kjappere enn den tegneserien tilsier. De tallene er mildt sagt ekstremt utdatert, og har vært det rimelig lenge. 1000 gjettninger pr. sek. representerer i dag en heller dårlig CPU, men CPUer benytter man ganske enkelt ikke til dette formålet. De som faktisk ønsker å finne ut hva en hash kan representere bruker en FPGA eller en GPU. Sistnevnte har jeg sett påstander om 5,6 milliarder MD5-hash pr. sekund. Hvis det medfører riktighet (ingenting tilsier at det ikke gjør det) vil 2⁴⁴ kunne løses på under en time. Merk at 5,6 milliarder allerede er et 3 år gammelt tall. Skalerer dette med klokkefrekvensen kan man med dagens maskinvare kanskje ligge et sted rundt 7 milliarder (rettelse: funnet video med nyere maskinvare hvor det påståes at man har oppnådd 45 milliarder pr. sekund).

 

Så ja, salt øker sikkerheten marginalt siden man ikke kan bruke rainbow-tables, men rainbow-tables er nesten unødvendig når man snakker om MD5. Konklusjonen er derfor unektelig at MD5 og SHA1 bør fjernes fra aktiv kode så fort som rå er og ersattes med langt, langt tyngre algoritmer.

Endret 13. juni 2012 av Ernie

[FraXinuS]

Jeg tror den beste måten å få oppdatert passordene i databasen din på er å lage en innloggings-script som støtter både den gamle og nye metoden. Når noen logger inn sjekker du hvilken metode som er brukt for å lagre passordet. Hvis passordet er lagret med den gamle metoden, så sjekker du passordet med den gamle metoden, hvis det er riktig så lagrer du passordet med den nye metoden.

 

For å få oppdatert alle brukerene, invalidere du bare alle innloggins-sessions så alle brukerene blir logget ut. Etter hvert som brukerene logger inn vil passordene bli oppdatert til å bruke den nye metoden.

Endret 13. juni 2012 av FraXinuS

[TheClown]

Med mindre man utvikler nettsider for NASA og skal gjemme Area 51 tror jeg dere bare kan glemme at noen tar superdatamaskinen til NTNU for å knekke passordene dine.

 

Lag en hash med et salg pluss bursdagen til kjæresten din mellom det 2 og 4 tegnet. Volla, du har noe som er relativt trygt.

 

Selvsagt KAN det knekkes, men nå har folk knekt Pentagon flere ganger, så kom ikke hit å si at det er enkelt å implementere en løsning som er 100% sikker.

 

Jeg kan også lekse ut om at det er mulig å generere 1020392093092093 passord i sekundet gjennom GPUen på superdatamaskinen til faren min, men jeg bidrar ingenting i denne tråden. Vi vet at riskene er der, slutt med meningsløs informasjon, vi har HØRT DET FØR. Takk for meg.

[TheClown]

Så ja, salt øker sikkerheten marginalt siden man ikke kan bruke rainbow-tables, men rainbow-tables er nesten unødvendig når man snakker om MD5. Konklusjonen er derfor unektelig at MD5 og SHA1 bør fjernes fra aktiv kode så fort som rå er og ersattes med langt, langt tyngre algoritmer.

 

Jeg skal utvikle en liten nettside som sikkert får 50 besøkende medlemmer, maks. Kan du forklare meg hvordan jeg kan legge inn disse lange, tunge algoritmene. Hvordan ser de ut? Jeg ser at du snakker om dem, men hvor er de?

 

Om du gidder kan du paste det på pastebin.com, så kan jeg legge det rett inn i koden min.

 

(NATUREN BLIR HERPA, VI MÅ SLUTTE Å FORURENSE, VI MÅ HA BILER SOM GÅR PÅ HYDROGEN. HYDROGEN HYDROGEN HYDROGEN. MEN SKAL JEG SKRIVE NOE OM HVORDAN MAN GJØR DETTE, ELLER HVORDAN MAN KOMMER DIT. NEI. MEN VI MÅ HA BILER SOM GÅR PÅ HYDROGEN. PUNKTUM).

[xibriz]

xibriz sikkerhetstips #14: Bruk ROT13 når du hasher så skjønner noobene som knekker hashen din ingenting.

[Ernie]

Så ja, salt øker sikkerheten marginalt siden man ikke kan bruke rainbow-tables, men rainbow-tables er nesten unødvendig når man snakker om MD5. Konklusjonen er derfor unektelig at MD5 og SHA1 bør fjernes fra aktiv kode så fort som rå er og ersattes med langt, langt tyngre algoritmer.

 

Jeg skal utvikle en liten nettside som sikkert får 50 besøkende medlemmer, maks. Kan du forklare meg hvordan jeg kan legge inn disse lange, tunge algoritmene. Hvordan ser de ut? Jeg ser at du snakker om dem, men hvor er de?

 

Om du gidder kan du paste det på pastebin.com, så kan jeg legge det rett inn i koden min.

Pr. nå driver jeg research på området. To ting ser ut til å være ganske klart:

1.

Dette er ikke noe folk er spesielt klar over, ergo vanskelig å finne noen klar anbefaling av andre

 

2.

Det gjøres grunnleggende endringer i algoritmen for generering av MD5-hash for å oppnå disse hastighetene. Noe så enkelt som å sikre at passord + salt er lengre enn 15-16 tegn kan faktisk velte endel av de raske implementasjonene. Passord + salt = minst 57 tegn vil velte en betydelig del av implementasjonene. Derimot er det såpass enkelt å etterkomme slike endringer at jeg ikke vil anbefale det som noen løsning.

 

Det jeg i førsterekke ville sett på som en erstatning til MD5/SHA-1 er bcrypt. Denne skal visstnok være adaptiv i forhold til regnestyrken på maskinen. Litt skeptisk til hvordan det skal fungere i praksis, men det kan se ut som at det er input man selv velger (ergo vil hash-ene over tid trenge en oppdatering med ny «cost»). Hvorvidt dette faktisk er implementert i PHP i dag kan jeg ikke si for sikkert. Det sies at PHP5.3 har støtte for det, men jeg ser ikke ut til å finne noe eksempel på det (mulig det er kammfulert som CRYPT_BLOWFISH). Andre alternativer som nevnes er SHA-2, dvs. SHA-256 og SHA-512, og SHA-3 (som er under utvikling). I forhold til SHA-2 føler jeg meg dog ikke spesielt betrygget når jeg ser logikken bak det, så jeg ville i førsterekke sett på bcrypt med en tyngst mulig «cost» man kan forsvare i produksjonsmiljø.

 

 

Et alternativ jeg dog kan garantere er supertreigt og utenkelig å knekke med det første er faktisk kryptering. Algoritmer som RSA hvor man har public/private-keyset er angivelig så treige at man heller ikke bruker de i kryptering av selve overføringen i SSL/TLS, men bare til handshake. Derfor kan det være en mulighet å generere opp et nøkkelsett og kryptere passordene med public key. Private key skriver man aldri noen gang inn i koden, men oppbevarer på et tryggest mulig sted, eller rett og slett glemmer den.

[TheClown]

Joda, du har mange gode poeng og jeg er såklart enig i det du sier, men kan du grave frem en snippet i PHP som viser hvordan man kan produsere disse hashene slik at jeg enkelt kan putte det inn på siden min?

 

Hvordan har du gjort det i dine prosjekter?