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?
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.
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.
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.
>> 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.
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.
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.
