[PHP] SHA Encryptie

[Verwijderd]

Beste,

Ik ben bezig met onderzoek naar een degelijke beveiliging voor mijn web-based software.
Ik weet dat BCrypt heel interessant is maar ik ben toch even benieuwd of mijn redenering (wat SHA1 betreft klopt)

Ik zal in mijn theorie een fictief gegeven gebruiken

Stel mijn wachtwoorden zijn minimum 6 tekens lang, minstens 1 hoofdletter, 1 kleine letter en 1 getal. Geen speciale tekens. Ik weet dat het op deze manier niet zo moeilijk is om een rainbow table op te stellen en zo verder...

Om dit te vermijden voeg ik een salt toe (6 tekens in de vorm van 8Z5uO1)
Stel ik heb dus een wachtwoord:
Cisco0
Er zal een hashing plaatsvinden op de term "Cisco08Z5U01"
Dit zijn dus in totaal 12 tekens.
Er zijn dus: 62^12 mogelijkheden (3.23 E 21)

Om deze mogelijkheden nog om te zetten naar een hash en dus het juiste wachtwoord te vinden is er dus een lange tijd nodig ?

Als hacker zullen we al een serieuze tegenstander nemen:
4U servers equipped with 25 AMD Radeon GPUs
( 63 billion/second for SHA1 ) volgens een artikel

Ben ik correct als ik aanneem dat het dan 3.23E21 / 63E9 = 5.12E10 seconden = 592715 dagen zal duren om al deze combinaties te creeeren ? (gemiddelde 300.000 om het te vinden)

Ben ik ook correct als ik zeg dat door het toevoegen van een Salt het gevaar op collisions ook geweken is?

Dit laatste denk ik omdat:
Als er een collision optreed zal dit een of andere 'wachtwoord' geven waar de je de salt niet kan afleiden en dus ook niets mee kan doen.

Alvast bedankt!

[Verwijderd]

Verwijderd schreef op vrijdag 22 november 2013 @ 17:15:
Beste,

Ik ben bezig met onderzoek naar een degelijke beveiliging voor mijn web-based software.
Ik weet dat BCrypt heel interessant is maar ik ben toch even benieuwd of mijn redenering (wat SHA1 betreft klopt)

Ik zal in mijn theorie een fictief gegeven gebruiken

Stel mijn wachtwoorden zijn minimum 6 tekens lang, minstens 1 hoofdletter, 1 kleine letter en 1 getal. Geen speciale tekens. Ik weet dat het op deze manier niet zo moeilijk is om een rainbow table op te stellen en zo verder...

Om dit te vermijden voeg ik een salt toe (6 tekens in de vorm van 8Z5uO1)
Stel ik heb dus een wachtwoord:
Cisco0
Er zal een hashing plaatsvinden op de term "Cisco08Z5U01"
Dit zijn dus in totaal 12 tekens.
Er zijn dus: 62^12 mogelijkheden (3.23 E 21)

Ja, ware het niet dat je salt ergens voor jouw systeem leesbaar zou moeten zijn. Ik zou dat dus niet bij de sterkte van het wachtwoord tellen. Ga ervanuit dat de salts op straat liggen met de rest van je data, en dan moet je als aanvaller 62⁶ pogingen doen.

Om deze mogelijkheden nog om te zetten naar een hash en dus het juiste wachtwoord te vinden is er dus een lange tijd nodig ?

De hash functie zal in principe zo vaak moeten worden uitgevoerd, dus hoe zwaarder het algoritme, hoe langer het duurt.

Als hacker zullen we al een serieuze tegenstander nemen:
4U servers equipped with 25 AMD Radeon GPUs
( 63 billion/second for SHA1 ) volgens een artikel

Ben ik correct als ik aanneem dat het dan 3.23E21 / 63E9 = 5.12E10 seconden = 592715 dagen zal duren om al deze combinaties te creeeren ? (gemiddelde 300.000 om het te vinden)

En als de salt bekend is dat dus een kwestie van seconden.

Ben ik ook correct als ik zeg dat door het toevoegen van een Salt het gevaar op collisions ook geweken is?

Als je salt verschilt per gebruiker, ja. Maar met fatsoenlijke wachtwoorden is de kans op collisions eigenlijk nul. Collisions heb je met wachtwoorden alleen als mensen "123456" als wachtwoord gebruiken.

Dit laatste denk ik omdat:
Als er een collision optreed zal dit een of andere 'wachtwoord' geven waar de je de salt niet kan afleiden en dus ook niets mee kan doen.

Uiteindelijk maakt een collision je niets uit. Je hasht wachtwoorden omdat je niet wilt dat er problemen ontstaan als mensen wachtwoorden hergebruiken voor verschillende zaken. Ja, dat is een slecht idee, maar het gebeurt.

Als je zelf random wachtwoorden zou uitgeven aan gebruikers, die zij niet gaan gebruiken voor andere zaken, zou je bij wijze van spreken niet eens hoeven hashen.

[Verwijderd]

Verwijderd schreef op vrijdag 22 november 2013 @ 17:27:
[...]

Ja, ware het niet dat je salt ergens voor jouw systeem leesbaar zou moeten zijn. Ik zou dat dus niet bij de sterkte van het wachtwoord tellen. Ga ervanuit dat de salts op straat liggen met de rest van je data, en dan moet je als aanvaller 62⁶ pogingen doen.

[...]

De hash functie zal in principe zo vaak moeten worden uitgevoerd, dus hoe zwaarder het algoritme, hoe langer het duurt.

[...]

En als de salt bekend is dat dus een kwestie van seconden.

[...]

Als je salt verschilt per gebruiker, ja. Maar met fatsoenlijke wachtwoorden is de kans op collisions eigenlijk nul. Collisions heb je met wachtwoorden alleen als mensen "123456" als wachtwoord gebruiken.

[...]

Uiteindelijk maakt een collision je niets uit. Je hasht wachtwoorden omdat je niet wilt dat er problemen ontstaan als mensen wachtwoorden hergebruiken voor verschillende zaken. Ja, dat is een slecht idee, maar het gebeurt.

Als je zelf random wachtwoorden zou uitgeven aan gebruikers, die zij niet gaan gebruiken voor andere zaken, zou je bij wijze van spreken niet eens hoeven hashen.

Bedankt voor je bijdrage, maakt me al wat wijzer.
Maar wat die collisions betreffen die maken in principe toch wel uit?
Stel 'cisco' en 'eindwerk' geven eenzelfde hashcode, zonder salt zal een hacker dus met beide wachtwoorden kunnen inloggen.

[Megamind]

Kijk ook eens naar Wikipedia: PBKDF2, omdat ze daar meerdere iteraties gebruiken krijg je een langzame hashing, en wordt het voor een hacker onmogelijk om nog een rainbow table te maken met de salt van de gebruiker.

[Sleepkever]

Even uit nieuwsgierigheid, wil je dit weten omdat je het interessant vind, of wil je dit uitzoeken zodat je het goed kan doen?

Als je het interessant vind kan ik je het eerste stuk van dit artikel aanbevelen, dat gaat op een aantal dingen in om te zorgen dat je wachtwoord gewoon veilig is. Als je het goed wilt doen kan ik je aanbevelen om gewoon een bestaande oplossing te gebruiken. Zoals phpass, zolang je dat gebruikt op de manier zoals het voorgeschreven word dan weet je in ieder geval dat je hashes goed zitten.

Zoals ook al vermeld in dat artikel, alle hashes zijn kraakbaar, je kan het de aanvaller alleen maar lastig maken en niet de moeite waard laten zijn qua investering van tijd door de hash functie zwaarder te maken en niet overal dezelfde salt te gebruiken zodat alle wachtwoorden apart gechecked moeten worden en er niet met rainbow tables gewerkt kan worden.

[Verwijderd]

Het gaat me vooral omdat ik dit gebruik maar wil er verder ook genoeg aandacht aan besteden aangezien ik er genoeg onderzoek wil naar doen. En ik stond op het punt inderdaad bcrypt te gebruiken tot ik deze berekening voor mezelf eens maakte en zag dat het zo al lang zou duren .

[Verwijderd]

Verwijderd schreef op vrijdag 22 november 2013 @ 17:32:

Stel 'cisco' en 'eindwerk' geven eenzelfde hashcode, zonder salt zal een hacker dus met beide wachtwoorden kunnen inloggen.

Als iemand toegang heeft tot je hashes en salts, kun je je maar beter druk gaan maken om de data die ze direct hebben kunnen benaderen. Of ze een ander wachtwoord hebben dat "ook" werkt is dan toch iets minder belangrijk? Ik zou overigens gerust durven zeggen dat er geen collisions bekend zijn waarbij twee password strings dezelfde hash opleveren.

Overigens gelden jouw aannames alleen bij willekeurige strings. De eerste aanval die men doet is een dictionary attack, en dan zijn alle S1mp3le wachtwoorden het eerst aan de beurt.

[Sleepkever]

Vergeet ook niet dat het omgekeerde ook waar is, dus als de aanvaller al een wachtwoord weet (zeg van zijn eigen account oid) dan is de salt die gebruikt is in de hash daarvan achterhalen natuurlijk ook zo gebeurd. Zelfs als je je salt zou baseren op iets van userid oid dan is dat ook zo terug te vinden als je database gekopieerd is.

Salts zijn belangrijk, maar beveiligen je in de praktijk alleen maar tegen rainbow tables wanneer ze juist gebruikt worden (aparte salt per gebruiker). Meer niet.

[DJMaze]

Megamind schreef op vrijdag 22 november 2013 @ 17:32:
Kijk ook eens naar Wikipedia: PBKDF2, omdat ze daar meerdere iteraties gebruiken krijg je een langzame hashing, en wordt het voor een hacker onmogelijk om nog een rainbow table te maken met de salt van de gebruiker.

Ik heb PHP code geschreven voor gebruik van PBKDF2 en Scrypt.
Omdat Bcrypt nu standaard in PHP zit is deze sneller dan bovengenoemde.
Scrypt in PHP code doet er gerust 10 seconden over op mijn Intel i5, en op het internet is immers de snelheid ook een belangrijk onderdeel.

Ik heb voor Scrypt de CPU cycles moeten terug schroeven van 16384 naar 1024, en dan blijkt deze onveiliger dan Bcrypt.

PBKDF2 can worden versneld d.m.v. de GPU, maar op de server zit natuurlijk geen Gamer GPU.

[Megamind]

Dat is wel hele lage performance dan, de Microsoft implementatie in .NET doet er bij mijn 10k iteraties maximaal 2 seconden over (i7 laptop).

[deadinspace]

Om te beginnen eerst dit: SHA1 is geen encryptie, het is een (cryptografische) hashfunctie. Dat is echt iets heel anders

Verwijderd schreef op vrijdag 22 november 2013 @ 17:15:
[...] Om dit te vermijden voeg ik een salt toe (6 tekens in de vorm van 8Z5uO1) [...] Er zijn dus: 62^12 mogelijkheden (3.23 E 21)

Het is al gezegd, maar het is de moeite dit toch nog even te benadrukken:

Salts dienen één doel: precomputed brute-force ("rainbow tables") onaantrekkelijk maken. Dat is het enige wat salts doen, en dat doen ze effectief.

Het aanvalsmodel is vrijwel altijd dat de aanvaller de salt kent (hij is doorgaans onderdeel van de uiteindelijke hash). Je mag die dus absoluut niet meerekenen bij de wachtwoordsterkte, want dat de aanname is dat dat deel van de input bekend is bij de aanvaller.

Verder zou ik willen afraden om SHA-1 te gebruiken voor wachtwoordhashes. SHA-1 is afgeleid van MD5, en er zijn vergelijkbare (theoretische) zwakheden in gevonden. Dat zijn nu nog geen praktische problemen voor SHA-1, maar dat kunnen het op termijn wel worden. Als je dan voor een hash uit de SHA-familie gaat, neem er dan eentje uit de SHA-2 subfamilie. Maar eigenlijk hoor je natuurlijk een hashfunctie te gebruiken die voor wachtwoordopslag ontworpen is, zoals PBKDF2, bcrypt of scrypt

Verwijderd schreef op vrijdag 22 november 2013 @ 17:27:
Als je salt verschilt per gebruiker, ja. Maar met fatsoenlijke wachtwoorden is de kans op collisions eigenlijk nul. Collisions heb je met wachtwoorden alleen als mensen "123456" als wachtwoord gebruiken.

Als meerdere mensen hetzelfde wachtwoord gebruiken dan is het natuurlijk geen collision meer

Een collision is per definitie de situatie dat twee verschillende inputs naar dezelfde waarde hashen.

Verwijderd schreef op vrijdag 22 november 2013 @ 17:32:
Maar wat die collisions betreffen die maken in principe toch wel uit?
Stel 'cisco' en 'eindwerk' geven eenzelfde hashcode, zonder salt zal een hacker dus met beide wachtwoorden kunnen inloggen.

Maar 'cisco' en 'eindwerk' hashen niet naar dezelfde waarde. En de kans dat voor twee willekeurige inputs zo is is echt enorm klein. SHA-1 is 160 bits, en een goede cryptografische hash mapt zijn inputs bijna willekeurig (maar herhaalbaar) naar outputs. De kans dat twee willekeurige strings naar dezelfde waarde hashen is daarmee 2^-160. 1 op 1461501637330902918203684832716283019655932542976.

En nee, een salt toevoegen helpt daar ook niet voor. De kans dat 'cisco' en 'eindwerk' naar dezelfde waarde hashen bestaat. Maar de kans dat 'cisco' + salt1 en 'eindwerk' + salt2 naar dezelfde waarde hashen bestaat net zo goed.

[HollowGamer]

PHP 5.5 heeft crypt functie onboard. Deze kiest automatisch dan wel handmatig de beste oplossen. Zeker eens interessant om naar te kijken.

[Barryvdh]

Crypt is er al langer, password_hash bedoel je? En dit is de 5.3+ implementatie voor diezelfde functies: https://github.com/ircmaxell/password_compat

[Verwijderd]

Ik heb BCrypt eens uitgeprobeerd en uiteindelijk hier maar voor gegaan, het aanpassen is immers niet echt een probleem!
Bedankt allen voor de input!

[HMS]

deadinspace schreef op vrijdag 22 november 2013 @ 20:08:
Om te beginnen eerst dit: SHA1 is geen encryptie, het is een (cryptografische) hashfunctie. Dat is echt iets heel anders

<knip>

Maar 'cisco' en 'eindwerk' hashen niet naar dezelfde waarde. En de kans dat voor twee willekeurige inputs zo is is echt enorm klein. SHA-1 is 160 bits, en een goede cryptografische hash mapt zijn inputs bijna willekeurig (maar herhaalbaar) naar outputs. De kans dat twee willekeurige strings naar dezelfde waarde hashen is daarmee 2^-160. 1 op 1461501637330902918203684832716283019655932542976.

Goed verhaal . 1 kleine correctie: die collision kans is bij een hash functie met n bits niet 1 op 2ⁿ maar 1 op 2^n/2. Oftewel de helft van de bit strength. Zie ook Wikipedia: Birthday problem.

[deadinspace]

HMS schreef op maandag 25 november 2013 @ 14:00:
Goed verhaal . 1 kleine correctie: die collision kans is bij een hash functie met n bits niet 1 op 2ⁿ maar 1 op 2^n/2. Oftewel de helft van de bit strength. Zie ook Wikipedia: Birthday problem.

Nee, wat ik schreef is correct; de kans dat twee willekeurige inputs tot een collision leiden is 2^-n

De birthday paradox gaat over het risico op collisions bij meer dan twee inputs. Het gedeelte waar jij aan referereert is het verwachte aantal inputs waarbij een collision optreedt. Dat wil zeggen, bij 2^n/2 inputs heb je waarschijnlijk één of meer collisions.

Nou heb je op zich wel een goed punt; bij een worst-case analyse van hashes is dat meestal de kans waar je mee moet rekenen, want je hebt natuurlijk niet maar 2 accounts. Maar dan bereken je daarmee wel het aantal gebruikers waarbij (naar verwachting) één collision optreedt tussen de wachtwoorden van twee van je gebruikers. En je hebt geen idee welke twee. Dus als dat al gebeurt, dan is de impact daarvan nog steeds heel klein.

Als je echter kijkt naar login-pogingen, met de vraag "als ik bij dit loginformulier een willekeurig wachtwoord invul, hoe groot is de kans dat dat wachtwoord goedgerekend wordt ook al klopt het wachtwoord niet?", dan is het antwoord - per poging - wel degelijk 2^-n

(en mijn punt in mijn vorige post was natuurlijk vooral dat salting die kansen niet verkleint)

[HMS]

Nouja, ik zou het niet de worst case noemen. Het is de best-case, als er geen aanval is op de hashfunctie die in minder dan 2^n/2 een collision kan vinden dan is het goed.

Maar deze discussie toont wel weer aan dat security niet iets simpels is .