Tutorials >
Javascript >
Wachtwoord Beveiliging
|
|
 Gepost op: 03 augustus 2005 - 19:21 |
|
|
|
HTML gevorderde
 |
leuk, jammer dat het meer op een script lijkt dan een tutorial
verdeel die lange code in stukjes met de nodige uitleg erbij |
|
|
|
|
| Gepost op: 03 augustus 2005 - 20:45 |
|
|
|
PHP expert
|
| have fun die code te begrijpen... ik zou wel willen maar... dit is een van de gevallen waarbij ik denk: het werkt dus ik ben tevreden. |
|
|
|
|
| Gepost op: 04 augustus 2005 - 13:03 |
|
|
|
Moderator
|
Gebruik van md5, vals gevoel van veiligheid ?
Middels dit stukje wil ik nogmaals benadrukken dat het klakkeloos toepassen van de hashfunctie md5() (in PHP, JavaScript of in wat voor taal dan ook) zaken niet veiliger hoeft te maken. In de eerste plaats is deze functie bedoeld om het wachtwoord (of andere vertrouwelijke gegevens) onleesbaar te maken maar waar het uiteindelijk waarschijnlijk om te doen is is het beveiligen van bepaalde functionaliteit van (bijvoorbeeld) websites.
Om binnen te geraken in deze beveiligde delen is het niet altijd nodig om het oorspronkelijke wachtwoord te weten - vaak (?) kun je ook gebruik maken van de wachtwoord-hash.
Een voorbeeld:
+-------------+
| |
| computer C |
| |
+-------------+
+------------+ | +------------+
| | | | |
| computer A |---------------------| computer B |
| | | |
+------------+ +------------+
+-------------+ | | | computer C | | | +-------------+ +------------+ | +------------+ | | | | | | computer A |---------------------| computer B | | | | | +------------+ +------------+
Stel dat een persoon achter computer A via een webbrowser een site bezoekt op computer B. Iemand achter computer C luistert mee met het netwerkverkeer tussen A en B.
Situatie #1: geen hashing bij het invoeren van wachtwoord op computer A
Het zal duidelijk zijn dat als de site op computer B geen hashing van gegevens voor versturen vanuit A toepast (met behulp van JavaScript), computer C meteen de beschikking over het wachtwoord zal hebben wanneer A bij B inlogt (door simpelweg het netwerkverkeer af te luisteren).
Situatie #2: wèl hashing bij het invoeren van wachtwoord op computer A
Stel dat iemand zo slim is geweest om een stukje JavaScript te installeren op de inlogpagina van de site op computer B, dat er voor zorgt dat op moment van versturen vanaf A het oorspronkelijke wachtwoord wordt gewist, en de hash hiervan wordt verstuurd naar B. Op computer B zal dan de hash die A heeft verstuurd vergeleken worden met de hash van het wachtwoord uit de database.
Het oorspronkelijke wachtwoord zal niet (? of moeilijk) te achterhalen zijn, maar computer C zal met behulp van de afgeluisterde password-hash gewoon kunnen inloggen op computer B - in plaats van het oorspronkelijke wachtwoord (situatie #1) kan de persoon achter computer C gebruik maken van de hash. Het op deze manier toepassen van hashing is dus NIET veilig.
Mogelijke oplossing ?
Je kunt veilige(re) mechanismen maken met behulp van md5-hashing aan de clientzijde. Het inlogmechanisme waar ik op dit moment gebruik van maak berust op gegevens die vrijwel meteen na versturen hun geldigheid verliezen en niet hergebruikt kunnen worden voor het op een later tijdstip inloggen. Of dit helemaal veilig is durf ik niet 100% te verzekeren, om de simpele reden dat ik geen veiligheidsexpert ben, maar het biedt iig meer (of enige) veiligheid dan bovenstaande situatieschetsen (je kunt natuurlijk ook meteen overstappen naar https  ).
Het idee is als volgt:
Bij het inlogformulier maak je naast het username- en password-veld twee hidden velden: een veld voor een timestamp, en een veld voor een password/timestamp hash. De waarde van de timestamp is afkomstig van de webserver met de (daarop geldende) huidige tijd, bijvoorbeeld in UNIX-time formaat.
Op het moment van inloggen verricht je de volgende bewerkingen:
- versleutel het wachtwoord met md5
- versleutel deze wachtwoord-hash opnieuw, in combinatie met de timestamp - dit is je password/timestamp hash
- maak het wachtwoordveld leeg
(hierna wordt het formulier pas verstuurd)
Op deze manier is de uiteindelijke hash (hash van timestamp + gehashde wachtwoord) altijd verschillend - deze kan dus niet hergebruikt worden.
Op computer B (hier stond C  ) kan met behulp van de verzonden timestamp (die voor iedereen zichtbaar is) en het wachtwoord uit de database de password/timestamp hash worden nagebouwd en worden vergeleken met de verstuurde password/timestamp hash (die ook voor iedereen zichtbaar is, maar waar je in feite weinig aan hebt). Door nu een timeout-periode in te bouwen voor de timestamp (bijvoorbeeld 30 seconden - je accepteert dus geen timestamps die ouder zijn dan 30 seconden), en niet meerdere logins te accepteren binnen deze timeout zorg je ervoor dat iemand eenmalig gebruik kan maken van die precieze logingegevens. De gegevens zijn na het optreden van de timeout onbruikbaar geworden.
Dit lijkt mij een veiliger mechanisme dan het enkel toepassen van md5. Voor een werkend voorbeeld van dit script / systeem - PM mij.
PS: Dit mechanisme staat of valt met de mogelijkheid om met behulp van een aantal password/timestamp hash - timestamp paren de oorspronkelijk password-hash te achterhalen, ik weet niet hoe eenvoudig dit is... |
|
|
|
|
| Gepost op: 08 augustus 2005 - 14:16 |
|
|
|
HTML interesse
|
FangorN, ik vond jouw tutorial iets nuttiger, aangezien ik dat javascript gebeuren al wist Zou je die van jou niet apart kunnen zetten / uitbereiden..?
MVG
Ruud |
|
|
|
|
| Gepost op: 09 december 2005 - 19:57 |
|
|
|
PHP expert
|
Op wat Fangorn zei zijn wel wat dingen aan te merken.
1: Als je alleen paginas van de laatste 30 seconden wil toestaan moet je ook 30 hashes maken. op den duur gaat dit nogal wat rekenkracht gebruiken.
2: als iemand dit geautomatiseerd doet, stuurt de aanvallen gewoon zodra hij het ontvangt hetzelfde wachtwoord naar je server, je krijgt nu gewoon 2 gebruikers ieder met een session van dezelfde gebruiker
3: de gebruikers die geen javascript (willen) gebruiken zijn de sjaak. |
|
|
| Enkel aanvullende informatie is welkom. Geen prijzende of afkeurende reacties. |
|
|
|
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
