Door
Matthijs Vos
op 24-10-2013 18:17
gewijzigd op 25-10-2013 23:10
2.889 views
Hallo allemaal.
Ik ben bezig met een SHA512 hasen in javascript. Nu heb ik daar CryptoJS voor gevonden. Nu hash ik eerst het wachtwoord met een static salt. Deze hash ik vervolgens nog een keer met een dynamic salt. Op de volgde manier:
[code lang=js]
var hash = CryptoJS.HmacSHA512(password,staticsalt);
var editedpw = CryptoJS.HmacSHA512(hash,dynsalt);
[/code]
Echter, nu krijg ik niet de goede hash terug. Ik had als oplossing het volgende gevonden:
[code lang=js]
var editedpw = CryptoJS.HmacSHA512(""+hash+"",salt);
[/code]
maar op de een of andere manier word dan mijn php niet goed meer uitgevoerd, het lijkt wel of de $_POST dan leeg gemaakt word.
Offtopic maar waarom zou je überhaupt je wachtwoord willen hashen in javascript?
PHP kan dit ook prima en ben je niet afhankelijk van de gebruiker. http://php.net/manual/en/function.crypt.php
Ja, dat lijkt me een slecht idee.
Het hele idee van encryptie; is dat je niet toont hoe je het paswoord geëncrypteerd hebt.
Nu ga jij die hash, die salt, en het eindresultaat publiek in javascript zetten.
Het idee is op zich niet slecht, hoor: bij het wijzigen van een wachtwoord verzendt de client niet het wachtwoord maar een hash van het wachtwoord. Dat is per definitie veiliger dan een onversleuteld wachtwoord verzenden en daarvan vervolgens pas op de server een hash opslaan.
Een hash van een hash maken heeft echter geen zin. Al doe je dat tien keer met tien verschillende algoritmen: de uitkomst is nooit sterker dan het zwakste algoritme.
Vraag is verder of je niet het paard achter de wagen spant: voor dit type versleuteld dataverkeer hebben we SSL.
bij het wijzigen van een wachtwoord verzendt de client niet het wachtwoord maar een hash van het wachtwoord.
Ja maar alles gebeurt in het openbaar.
De hacker krijgt gratis een openbare javascript-functie mee.
De hacker kan alles rustig zelf uitproberen ... Zonder enig contact met de server
De hacker kan bv. een bibliotheek aanleggen van paswoord -> encrypted.
Geen extra controle van '3 keer proberen' ...
Kan iemand een volledig systeem beschrijven waarbij javascript-encryptie een goed idee is?
Kris, dat klopt deels, maar zolang het een asymmetrische hash zoals 512 bits SHA-2 (SHA512) is, kan dat op zich niet kwaad. Dat het gebruikte hashalgoritme openbaar is, wil immers nog niet zeggen dat de uitkomst daarvan (de hash) onveilig is. Baat het niet, het schaadt ook niet.
Met een door client en server via JavaScript gedeelde salt heb ik veel meer moeite. Dát voegt inderdaad niets toe, maar dat maakt het hashalgoritme nog steeds niet onbruikbaar.
Ik zal het idee even toelichten. Bij de registratie word het wachtwoord gehasht samen met een static salt en die word dan met geencrypt met een dynamische salt die bestaat uit een gedeelte dat op de server word gemaakt, en een gedeelte dat bij de client word gemaakt. Dit samen is de dynamische salt. vervolgens word dat geencrypte wachtwoord naar de server gestuurd. Daar word het gedeelte van de dynamische salt weggehaalt (decrypt) en word de hash opgeslagen in de database.
Bij een inlog poging gebeurt iets gelijks. Het wachtwoord word weer met de static salt gehasht en vervolgens word ook dit client-side met dynamische salt (bestaande uit dezelfde 2 componenten) weer gehasht. Nu dit over de lijn gestuur en word server-side het wachtwoord opgehaald uit de database en gehasht met dezelfde dynamische salt. Als deze gelijk zijn ben je inlogd.
Door het op deze manier toen doen met iemand die data snift al 3 waarden bemachtigen. Als hij die 3 waarden heeft heeft hij er nog niks aan want bij een registratie ziet hij dan alleen de gehashte waarde (en omdat er een static salt bij inzit kan hij niks met een rainbow table). Aangezien de dynamische salt bij elke inlog/registratie poging anders is is het bij dit systeem nooit mogelijk om een rainbow tabel te maken. Stel dat ze er 1 zien te maken dan is die bij de volgende poging al niet goed meer omdat de dynamische salt veranderd is.
Nog even wat betreft het feit dat de waardes publiek in de javascript staan. Het betreft een extern javascript bestand waardoor je alleen zal kunnen zien wat het doet (en het server-side gedeelte van de dynamische hash) wat het client-side gedeelte van de hash is en wat het gehashde wachtwoord precies word zie je niet, je kan alleen zien hoe het berekend word.
Ik zal het idee even toelichten. Bij de registratie word het wachtwoord gehasht samen met een static salt en die word dan met een geencrypt met een dynamische salt die bestaat uit een gedeelte dat op de server word gemaakt, en een gedeelte dat bij de client maakt. Dit samen is de dynamische salt. vervolgens word dat geencrypte wachtwoord naar de server gestuurd. Daar word het gedeelte van de dynamische salt weggehaalt en word de hash opgeslagen in de database.
Bij een inlog poging gebeurt iets gelijks. Het wachtwoord word weer met de static salt gehasht en vervolgens word ook dit client-side met dynamische salt (bestaande uit dezelfde 2 componenten) weer gehasht. Nu dit over de lijn gestuur en word server-side het wachtwoord opgehaald uit de database en gehasht met dezelfde dynamische salt. Als deze gelijk zijn ben je inlogd.
Door het op deze manier toen doen met iemand die data snift al 3 waarden bemachtigen. Als hij die 3 waarden heeft heeft hij er nog niks aan want bij een registratie ziet hij dan alleen de gehashte waarde (en omdat er een static salt bij inzit kan hij niks met een rainbow table). Aangezien de dynamische salt bij elke inlog/registratie poging anders is is het bij dit systeem nooit mogelijk om een rainbow tabel te maken. Stel dat ze er 1 zien te maken dan is die bij de volgende poging al niet goed meer omdat de dynamische salt veranderd is.
Nog even wat betreft het feit dat de waardes publiek in de javascript staan. Het betreft een extern javascript bestand waardoor je alleen zal kunnen zien wat het doet (en het server-side gedeelte van de dynamische hash) wat het client-side gedeelte van de hash is en wat het gehashde wachtwoord precies word zie je niet, je kan alleen zien hoe het berekend word.
Een heel verhaal wat ik zelf niet helemaal niet snap, maar dat geeft niet.
Wat als Javascript bij de client uit staat?
Dan werkt het inderdaad niet. De client zal dit inderdaad aan moeten hebben. Maar als je kijkt hoeveel site's tegenwoord javascript gebruiken lijkt me dit niet heel raar. En volgens mij hebben bijna alle gebruikers het wel aan staan.
Fabeltje. Deze optie is al aan het verdwijnen naar de achtergrond, een plek waar een normale gebruiker nauwelijks bijkomt.
Het is meer een idee van vroeger, toen nog niet elk browser JavaScript ondersteunde. Tegenwoordig doet alles dat en staat het ook overal aan. Want:
90% van je bezoekers zijn gewone internet gebruikers, die weten niet eens wat JavaScript is en laten de optie gewoon op default (aan) staan.
8% van je bezoekers zijn developers, deze weten wel wat JavaScript is en weten ook dat ze het uit kunnen zetten. Ze weten ook dat als ze dat doen, ze ouderwets bezig zijn en zorgen dat ze eigenlijk geen 1 website meer kunnen gebruiken. Conclusie: ze laten de optie ook gewoon aan staan.
2% van je bezoekers zijn oude mensen die gewoon alles waar de woorden 'veiligheid' en 'uit' zien staan zo snel mogelijk op uit klikken. Hiervan weet 1.75% de optie niet te vinden en de overige 0.25% zet het op uit.
Het resultaat: 99.75% kan je site gewoon normaal gebruiken.
*cijfers zijn fictief en alleen om mijn punt duidelijk te maken.
