CryptoJS
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 (js)
1
2
2
var hash = CryptoJS.HmacSHA512(password,staticsalt);
var editedpw = CryptoJS.HmacSHA512(hash,dynsalt);
var editedpw = CryptoJS.HmacSHA512(hash,dynsalt);
Echter, nu krijg ik niet de goede hash terug. Ik had als oplossing het volgende gevonden:
Code (js)
1
var editedpw = CryptoJS.HmacSHA512(""+hash+"",salt);
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.
Weet iemand hoe dit op te lossen is?
Graag volgende keer alle codes tussen code-tags zetten ipv quote-tags[/modedit]
Gewijzigd op 25/10/2013 23:10:11 door Nick Dijkstra
PHP kan dit ook prima en ben je niet afhankelijk van de gebruiker.
http://php.net/manual/en/function.crypt.php
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.
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.
Ward van der Put op 25/10/2013 11:53:26:
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?
Gewijzigd op 25/10/2013 12:44:26 door Kris Peeters
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.
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.
Gewijzigd op 25/10/2013 14:49:46 door Matthijs Vos
Matthijs Vos op 25/10/2013 14:28:47:
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.
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?
Michael - op 25/10/2013 14:38:18:
Wat als Javascript bij de client uit staat?
Wat een saaie internetbeleving zal die client hebben?
Geen Google Maps, geen deftige slideshow, geen auto complete, ...
Stel je voor dat die client toch echt wil inloggen, zou die de javascript-aan-knop misschien toch aanzetten?
Matthijs Vos op 25/10/2013 14:28:47:
Ik zal het idee even toelichten. ...
Ja, dat klinkt wel zinnig
Gewijzigd op 25/10/2013 14:54:56 door Kris Peeters
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.
Michael - op 25/10/2013 14:38:18:
Wat als Javascript bij de client uit staat?
Het grappigste van alles is nog dat het er in dat geval helemaal niet toe doet. De >99% clients die JavaScript ondersteunen, verzendt de wachtwoordhash, de rest het wachtwoord zelf. Je kunt dus 100% van de gevallen afdekken.
Je maakt een aparte afhandeling op de server voor niet ge-encrypte wachtwoorden die daar naartoe worden verzonden omdat javascript uit stond.
Op de pagina van het formulier zet je als action attribuut het adres van deze pagina.
Bij het laden van de pagina laat je het adres in het action attribuut van je form veranderen naar de locatie waar je op de server het wachtwoord wilt ontvangen, als het wel gewoon is ge-encrypt door javascript. Als er geen javascript wordt ondersteund zal dus niet de form action worden veranderd, en zal deze het standaard adres hebben dat je in de broncode in het action attribuut hebt gezet. En dan wordt dus het plain wachtwoord daar naartoe gestuurd en kun je het apart afhandelen.
Als er wel gewoon javascript is ondersteund, wordt dus de action van het formulier veranderd (door js) naar het adres waar het wel gecodeerde wachtwoord naartoe moet worden gestuurd.
Er kan dus in beide gevallen worden ingelogd, js of niet.
Het gaat er alleen om waar je het wachtwoord naartoe stuurt omdat je de goede afhandeling moet doen op de server.
Het is dan wel zo dat als js uit is, dat het wachtwoord alsnog plain wordt verstuurd over internet, maar er kan tenminste worden ingelogd.
Ik kan helaas geen oplossing verzinnen voor als iemand HTML uit heeft staan.. :P
Gewijzigd op 26/10/2013 11:33:45 door jan terhuijzen
Jan terhuijzen op 26/10/2013 11:32:16:
Misschien een oplossing als iemand geen javascript aan heeft staan:
Je maakt een aparte afhandeling op de server voor niet ge-encrypte wachtwoorden die daar naartoe worden verzonden omdat javascript uit stond.
Je maakt een aparte afhandeling op de server voor niet ge-encrypte wachtwoorden die daar naartoe worden verzonden omdat javascript uit stond.
Je kunt een hash vaak herkennen aan de vaste lengte en de gebruikte karakters. Bij SHA512 is dat bijvoorbeeld een hexadecimale waarde (0 t/m f) van 128 karakters:
Dan gaat het wachtwoord dus alsnog plain over de lijn, dat wou ik juist voorkomen. Maak denk ik een systeem die decteert of het uitstaat en dan de gebruiker verzoekt het in te schakelen. Maar wat ik bedoelde met oplossing was eigenlijk de oplossing van het probleem dat ik in de 1e post had staan.
Matthijs Vos op 26/10/2013 15:14:54:
Maar wat ik bedoelde met oplossing was eigenlijk de oplossing van het probleem dat ik in de 1e post had staan.
Als de $_POST leeg is in PHP, laat dan eens iets meer code van het formulier zien?
Code (html)
1
2
3
4
5
2
3
4
5
<form id="form" method="POST" class="loginform">
Leerlingnummer:<input name="id" id="llnmr" class="llnmr" />
Wachtwoord:<input name="password" type="password" id="wachtwoord" class="wachtwoord" />
<input type="submit" id="submit" name="send" class="submit" value="Login"/>
</form>
Leerlingnummer:<input name="id" id="llnmr" class="llnmr" />
Wachtwoord:<input name="password" type="password" id="wachtwoord" class="wachtwoord" />
<input type="submit" id="submit" name="send" class="submit" value="Login"/>
</form>
En dit de javascript (verkort):
Code (js)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
( "#submit" ).click(function() {//als er op submit wordt gedrukt
var password = form.password.value; // password ophalen
var salt = "een waarde"
var hash = CryptoJS.HmacSHA512(password,random);
var editedpw = CryptoJS.HmacSHA512(""+hash+"",salt);
form.password.value = editedpw;
});
var password = form.password.value; // password ophalen
var salt = "een waarde"
var hash = CryptoJS.HmacSHA512(password,random);
var editedpw = CryptoJS.HmacSHA512(""+hash+"",salt);
form.password.value = editedpw;
});
Hoe de salt gemaakt word laat ik even achterwegen, maar dat werkt goed.
Zie mijn vorige edit. Graag alle codes tussen de code-tags zetten ipv de quote-tags.[/modedit]
Gewijzigd op 26/10/2013 23:19:54 door Nick Dijkstra