Beveiligen gebruikersnaam / wachtwoord
Op http://nl3.php.net/manual/en/function.crypt.php eens rondgekeken.
Als ik dan onder 'Example #3 Using crypt() with different hash types' kijk, valt mij op dat in de 2e parameter (bijna) geheel terug komt in het resultaat. Als iemand dan toegang heeft tot de database, dan weet die toch ook wat de 'vertaalslag' is?
Of maak ik ergens een (denk)fout?
@Wouter: als de salt leesbaar terugkomt, wat is dan de toegevoegde waarde van een salt?
Obelix en Idefix op 24/06/2012 17:26:38:
Als iemand dan toegang heeft tot de database, dan weet die toch ook wat de 'vertaalslag' is?
Als iemand die toegang al heeft dan heeft ie toch al alle informatie toe zijn beschikking.
Als je echt wilt beveiligen moet je gewoon met SSL werken.
Ger van Steenderen op 24/06/2012 20:30:27:
Als iemand die toegang al heeft dan heeft ie toch al alle informatie toe zijn beschikking.
Dan zou het gecodeerd opslaan van gegevens in een database dus eigenlijk zinloos zijn?
Ger van Steenderen op 24/06/2012 20:30:27:
Als je echt wilt beveiligen moet je gewoon met SSL werken.
SSL is dat je werkt met https (?). Is dat voor de 'gemiddelde' verenigingssite niet wat te veel van het goede? Dat doen ze op phphulp niet eens :s
En ik zou altijd het wachtwoord coderen, de rest hoeft niet per se. Een salt lijkt inderdaad nutteloos, behalve als je het goed doet en een dynamische salt gebruikt, zoals uniqid of een hashing van de registreerdatum van de gebruiker.
Crispijn - op 24/06/2012 18:00:48:
Je weet als hacker niet waar de salt in het wachtwoord wordt toegepast.
Hoe bedoel je dat? Jouw idee is om het wachtwoord op te splitsen in twee delen en daar tussen een salt te plaatsen?
Wouter J op 24/06/2012 21:52:32:
Een salt lijkt inderdaad nutteloos, behalve als je het goed doet en een dynamische salt gebruikt, zoals uniqid of een hashing van de registreerdatum van de gebruiker.
Maar uniqid zul je ergens moeten opslaan, zodat je die later weer kunt gebruiken om te controleren. Sla je die dan in een database op?
En die lag al op straat...
Ik begrijp dat plaintext opslaan geen optie is. Dan wordt het wel heel makkelijk. Maar als in de database te zien is wat gebruikt is om het wachtwoord te beveiligen, dan is het dus alleen om de hacker het (misschien) wat moeilijker te maken(?).
Het beste is je wachtwoorden hashen met een sleutel die je zelf invoert en in je script blijft en vervolgens een random salt + pepper of 1 van die 2 static erbij te plaatsen. Dat is dan nauwelijks te hacken.
Ger van Steenderen op 24/06/2012 20:30:27:
Als iemand die toegang al heeft dan heeft ie toch al alle informatie toe zijn beschikking.
Als je echt wilt beveiligen moet je gewoon met SSL werken.
Obelix en Idefix op 24/06/2012 17:26:38:
Als iemand dan toegang heeft tot de database, dan weet die toch ook wat de 'vertaalslag' is?
Als iemand die toegang al heeft dan heeft ie toch al alle informatie toe zijn beschikking.
Als je echt wilt beveiligen moet je gewoon met SSL werken.
SSL (HTTPS) versleuteld ALLES en moet dus de complete website door een codeersysteem heen. En bij de client wordt alles vervolgens weer terug gecodeerd d.m.v. een unique key.
Zeer veilig, maar levert wel echt veel vertraging op. Synchroniserende scripts (dynamische websites) zal hierdoor niet optimaal presteren.
SSL niet aangeraden voor alleen username/password protection in je database.
Daarnaast is SSL niet bedoeld om data uit je database te beschermen, althans indirect. De bedoeling van SSL is om data tussen server en client gecodeerd te hebben, zodat data-sniffing (door bijv. hackers) niet mogelijk is omdat alle tekst versleuteld is.
Wordt voornamelijk gebruikt bij betalingen (creditcard gegevens e.d.)
Tip:
Forms dichtgooien met anti SQL-injectie script.
En voornaamste is e-mailadres en wachtwoord crypte.
Gewijzigd op 27/06/2012 00:42:25 door B Polak
Aanmelden via SSL is een mooie extra om uw gebruikers veilig te laten inloggen in alle geval. Dit geld natuurlijk ook voor alle andere data dat je over de http lijn stuurt.
Bij het veilig maken van wachtwoorden moet je er eigenlijk voor zorgen dat alles zo traag mogelijk is. De gebruiker gaat het echt niet erg vinden om even te moeten wachten als hij zeker is dat alles veilig is. Het gaat dan ook maar over 1 login.
Bij wachtwoorden opslaan in de database, moet je er ook voor zorgen dat de hash zeer traag gemaakt kan worden. Dit wilt zeggen: als je een hash traag maakt, dan wordt deze ook traag om te kraken. Daarom gebruik je bcrypt:
In bcrypt kan je instellen hoe traag het hashen van een wachtwoord is. Deze methode maakt dan gebruik van een random salt om uw wachtwoord op te slaan. Dit maakt het dus onmogelijk om rainbow attacks uit te voeren op uw database. Deze hash kan dan gebruikt worden tijdens het verifieren van uw wachtwoord. Je gebruikt deze hash dan eigenlijk opnieuw als salt voor uw wachtwoord.
Hier vind je meer info:
http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
Een voorbeeld heb ik geplaatst helemaal onderaan de topic in:
http://www.phphulp.nl/php/forum/topic/beveiligings-script-is-het-veilig/85133/
Je ziet dus dat je door het aanpassen van een parameter het coderen langer kan laten duren. Bruteforcen wordt op deze manier een hel!
Natuurlijk moet je proberen om al uw code zo waterdicht mogelijk te maken. Hier kan je in mijn ogen dan best een framework voor gebruiken. Daar zijn dikwijls dingen zoals sql injections al volledig in tegengegaan.
Gewijzigd op 27/06/2012 08:21:39 door de VeeWee
als je nou een geheime sleutel toevoegd(vanuit een beveiligde map of een map boven je rootmap) aan de gehashte stringmetsalt
zou dat misschien een goed alternatief zijn op de https
Wouter J op 24/06/2012 17:38:36:
De 2 parameter is een salt, een salt komt altijd volledig terug in een wachtwoord, op plaats 1. Dus het is heel normaal denk ik?
Een salt wordt altijd 'meegehashed' met het te coderen gegeven, anders zou je aan twee wachtwoorden al genoeg hebben om de salt eruit te filteren.
Stel mijn SALT is 'Kr0ket!'
Je slaat in de database dan het volgende wachtwoord op:
Dit levert een hash zonder 'Kr0ket!' erin, maar ook een andere hash dan de hash van alleen $_POST['wachtwoord'] zou leveren.
Ook dit systeem is uiteindelijk te kraken, maar een simpele lookup in een rainbowtable zal niet werken.
https is bedoeld voor de beveiliging van de lijn tussen de client en server (gebruiker en website). (Tegen man in the middle attack, voorkomen dat de inhoud in logs van gateways e.d. komt etc)
SSL maakt de website wel iets zwaarder, maar dat verschil is minimaal. Bij mij gaat elke website die dat kan automatisch via https, browsers zijn heel snel in het encoderen en decoderen. SSL is verplicht voor websites waar je persoonsgegevens verwerkt. Dus als je leden administratie van de vereniging ook in de website zit moet je wel ssl hebben.
Het gebruik van salt en pepper i.c.m. hash is om het wachtwoord niet plaintext op te slaan. De salt en pepper maken rainbow tabels nutteloos waardoor iemand die de gegevens gestolen heeft niet de wachtwoorden rechtstreeks op andere websites kan gebruiken. Je hebt hiermee de tijd om je gebruikers te waarschuwen zodat ze hun wachtwoorden kunnen wijzigen. (Heel veel mensen hebben maar een paar of zelfs maar 1 wachtwoord dat ze overal gebruiken)