sha256 vs bcrypt
Hallo.
Ik wil graag duidelijkheid. Ik gebruik al een poosje sha256 hash methode + salt en dat bevalt mij prima. Ik heb van meerdere mensen gehoord dat dat veilig genoeg is. Echter hoor ik ook mensen die zeggend dat sha256 absoluut niet veilig is en dat je per se bcrypt moet gebruiken omdat anders je webapplicatie heel makkelijk te hacken is.
Ik weet het dus niet meer. Kan iemand mij dus vertellen wat echt beter is? En dan graag niet alleen je mening ook graag bewijs. En als de een beter is, is de andere dan per definitie slecht en onveilig?
Gr. Maarten
Ik wil graag duidelijkheid. Ik gebruik al een poosje sha256 hash methode + salt en dat bevalt mij prima. Ik heb van meerdere mensen gehoord dat dat veilig genoeg is. Echter hoor ik ook mensen die zeggend dat sha256 absoluut niet veilig is en dat je per se bcrypt moet gebruiken omdat anders je webapplicatie heel makkelijk te hacken is.
Ik weet het dus niet meer. Kan iemand mij dus vertellen wat echt beter is? En dan graag niet alleen je mening ook graag bewijs. En als de een beter is, is de andere dan per definitie slecht en onveilig?
Gr. Maarten
Tsja, wat is "veilig"? Als je de hash functie gebruikt om wachtwoorden te hashen, dan gaat een hacker echt niet proberen je hash te reverse-engineren, die gaat gewoon aan de voorkant snuffelen of hij het wachtwoord kan meelezen. Het wachtwoord is uiteindelijk het zwakste punt in de schakel.
Dus waar wi je jezelf tegen beveiligen?
Dus waar wi je jezelf tegen beveiligen?
100% is bijna onmogelijk. Waar ik voor wil zorgen is dat sql injecties niet meer mogelijkzijn en mocht tog iemand in de db komen hij geen wachtwoorden kan kraken
SQL injecties kun je voorkomen door overal en altijd alleen te werken met "prepared statements".
Maar het is veel waarschijnlijker dat er ergens in je code een bug zit die de hashes zichtbaar kan maken, b.v. door een var_dump() die iets meer dumpt dan je zou willen. de database zelf heeft als het goed opgezet is gewoon geen toegang van buitenaf, dus daar komt een hacker dan echt niet in buiten jouw code om.
Maar het is veel waarschijnlijker dat er ergens in je code een bug zit die de hashes zichtbaar kan maken, b.v. door een var_dump() die iets meer dumpt dan je zou willen. de database zelf heeft als het goed opgezet is gewoon geen toegang van buitenaf, dus daar komt een hacker dan echt niet in buiten jouw code om.
Ik gebruik alleen var_dump als ik iets wil testen en verder nooit dus dat zit wel goed. En ik maak gebruik van prepared statements. Al met al prima beveiliging.
Nou, ho, dat is geen beveiliging he, dat zijn twee "niet lekken". Als je ergens een exception werpt die door een of andere instelling een stack-trace dumpt, dan ben je nog veel verder van huis. Je moet wel echt maatregelen nemen om te zorgen dat php op geen enkele manier iets kan weergeven wat niet de bedoeling is. Jou zou b.v. niet de eerste zijn die een debug log in zijn document root schrijft, waar "voor het gemak" ook het password in wordt geschreven, maar is vergeten om die URL vanuit de webserver te blokkeren....
Je moet dus zorgen dat jouw systeem niets vrijgeeft, dat niemand data uit je systeem kan peuteren, en als laatste komt pas het versleutelen van de data in de database.
Je moet dus zorgen dat jouw systeem niets vrijgeeft, dat niemand data uit je systeem kan peuteren, en als laatste komt pas het versleutelen van de data in de database.
>> Waar ik voor wil zorgen is dat sql injecties niet meer mogelijk zijn
Dit heeft niets te maken met welke encryptie methode je werkt. Zoals Vincent al aangeeft moet je dit voorkomen bij het schrijven naar de database. Prepared statements is maar één van de mogelijkheden waarmee je de kans op SQL injectie probeert te beperken of uit te sluiten.
>> en mocht togch iemand in de db komen hij geen wachtwoorden kan kraken.
Goed punt. Gebruik in dit geval liever BCrypt. SHA(256) is makkelijker te kraken. Overigens is het voor jouw website of database dan al te laat. Maar je voorkomt dan misschien dat de hacker het wachtwoord van je gebruikers gaat gebruiken op andere diensten zoals hun gmail account bijvoorbeeld.
Dit heeft niets te maken met welke encryptie methode je werkt. Zoals Vincent al aangeeft moet je dit voorkomen bij het schrijven naar de database. Prepared statements is maar één van de mogelijkheden waarmee je de kans op SQL injectie probeert te beperken of uit te sluiten.
>> en mocht to
Goed punt. Gebruik in dit geval liever BCrypt. SHA(256) is makkelijker te kraken. Overigens is het voor jouw website of database dan al te laat. Maar je voorkomt dan misschien dat de hacker het wachtwoord van je gebruikers gaat gebruiken op andere diensten zoals hun gmail account bijvoorbeeld.
"SHA(256) is makkelijker te kraken."
En kort googlen leert dat dat is omdat het SHA algorythme heel snel is als je het draait op een GPU. Als in: miljoenen/miljarden pogingen per seconde snel. Zwakke wachtwoorden zijn dus zo gehackt, en ook je salt zal sterk moeten zijn.
En kort googlen leert dat dat is omdat het SHA algorythme heel snel is als je het draait op een GPU. Als in: miljoenen/miljarden pogingen per seconde snel. Zwakke wachtwoorden zijn dus zo gehackt, en ook je salt zal sterk moeten zijn.
De salt wordt bij mij gegenereerd op basis van de licentie code die de applicatie heeft. Dus die is bij elke applicatie verschillend
Bon, maar de hacker gaat de hash aanvallen met rainbow-tables, dat zijn lange lijsten van woorden en kreten die mensen vaak gebruiken. Als jouw wachtwoord is "oliebol" en je salt is "563" zodat de hash wordt gemaakt van "oliebol563" dan hoeft een hacker de rainbow tabel maar 563 keer te proberen om jouw wachtwoord te vinden. Als je de salt toepast als "o5lie6bo3l" dan werkt de rainbow table niet meer en moet hij brute-force dingen gaan proberen, wat weer langer duurt als je afdwingt dat er hoofdletters en leestekens worden gebruikt.
Ja das waar idd. De salt is nu een serial key. 4x een combinatie van letters en cijfers met een streepje ertussen. Lijkt me al weer beter dan 563
Pg Vincent op 21/10/2016 09:51:19:
Bon, maar de hacker gaat de hash aanvallen met rainbow-tables, dat zijn lange lijsten van woorden en kreten die mensen vaak gebruiken. Als jouw wachtwoord is "oliebol" en je salt is "563" zodat de hash wordt gemaakt van "oliebol563" dan hoeft een hacker de rainbow tabel maar 563 keer te proberen om jouw wachtwoord te vinden.
Iets met een klok en een klepel die de plank misslaan. ;-)
Een salt is er juist voor om te voorkomen dat er uberhaupt een rainbow table kan worden gebruikt. Bovendien hoeft een rainbow table in dit voorbeeld niet "563x geprobeerd te worden" (wat dat dan ook moge betekenen). Als het gecrypte wachtwoord bekend is (omdat iemand bijvoorbeeld toegang heeft weten te krijgen tot je database) is ook je salt bekend. Maar dat is helemaal niet erg, want omdat de indringer waarschijnlijk geen rainbow table heeft liggen die met die salt is gemaakt, zal hij een dictionary attack of misschien zelfs wel een brute force attack moeten uitvoeren. Om die reden is het dus ook geen probleem als de salt bekend is, zolang elk wachtwoord maar met een unieke salt is gehasht.
Pg Vincent op 20/10/2016 15:44:31:
SQL injecties kun je voorkomen door overal en altijd alleen te werken met "prepared statements".
Hier ben ik het niet helemaal mee eens.
De/een eerste cruciale stap in het voorkomen van SQL injectie is begrijpen hoe dit ontstaat.
Vervolgens dien je er voor te zorgen dat alle DATA delen in je SQL op de juiste manier worden ge-escaped.
Prepared statements zijn een middel hiertoe. Maar wederom dien je te snappen hoe prepared statements werken en hoe je hier veilig mee omgaat. Ik heb hier (of ergens anders) iemand serieus prepared statements zien gebruiken waarbij superglobal-variabelen werden geconcateneerd aan een querystring. Het (verkeerd) gebruik van prepared statements kan nog veel catastrofaler zijn dan andere oplossingen omdat het je een vals gevoel van veiligheid kan geven.




