[php] login veilig ?

[Verwijderd]

Halo Tweakers,


Ik heb op dit moment een login die het wachtwoord lokaal versleuteld ( md5(ww + random_key) )

Nu hoor ik van een aantal mensen dat het niet nodig is om lokaal te versleutelen.
Dit heb ik getest met het volgende script:

PHP:

<?php
    $A = md5($_POST['P']);
    
    
    print '
        <fieldset>
            <legend>Login</legend>
            <form method="POST" action="' . $_SERVER['PHP_SELF'] . '">
                <table>
                    <tr>
                        <td>Naam</td>
                        <td><input type="text" name="N"></td>
                    </tr>
                    <tr>
                        <td>Wachtwoord</td>
                        <td><input type="password" name="P"></td>
                    </tr>
                    <tr>
                        <td>&nbsp;</td>
                        <td><input type="submit"></td>
                    </tr>
                </table>
            </form>
        </fieldset>';
?>

Het wachtwoord kan ik op deze manier gewoon achterhalen door het netwerk te scannen met een packet-scanner.


Mijn vraag is dan ook, is deze methode veilig genoeg om in te kunnen loggen zonder dat het wachtwoord onderschept wordt ?

[mr_obb]

Je geeft zelf het antwoord al: Nee.

[maurad3r]

Het wachtwoord zal met een netwerksniffer te achterhalen zijn ja, het wordt immers onbeveiligd naar de server gestuurd en wordt DAAR pas omgezet in een md5 string. Wat je zou moeten doen is gebruik maken van SSL!

edit: of misschien javascript die voor jou de md5 string tevoorschijn tovert alovrens je de gegevesn wegpost?
http://www.google.nl/sear...s=org.mozilla:nl:official

[ Voor 38% gewijzigd door maurad3r op 11-02-2006 19:04 ]

[Y0ur1]

Het meest veilige is HTTPS, en verder zou je eventueel met javascript kunnen versteulen, maar dat is niet echt veilig ofzo.

[Alex)]

Je hebt die random variabele nodig, dan pas kun je een veiligere inlogmanier maken. Blijft alleen de optie 'Wachtwoord wijzigen' over, hoe wil je dat aan gaan pakken?

[Verwijderd]

Maurad3r schreef op zaterdag 11 februari 2006 @ 19:03:
Het wachtwoord zal met een netwerksniffer te achterhalen zijn ja, het wordt immers onbeveiligd naar de server gestuurd en wordt DAAR pas omgezet in een md5 string. Wat je zou moeten doen is gebruik maken van SSL!

edit: of misschien javascript die voor jou de md5 string tevoorschijn tovert alovrens je de gegevesn wegpost?
http://www.google.nl/sear...s=org.mozilla:nl:official

Op dit moment encrypt ik de gegevens al met javascript, maar wil het eigenlijk een beetje makkelijker (als het kan ).
SSL vind de eigenaar van de website helaas te duur; anders had ik daar zeker voor gekozen.

[Verwijderd]

Alex schreef op zaterdag 11 februari 2006 @ 19:06:
Je hebt die random variabele nodig, dan pas kun je een veiligere inlogmanier maken. Blijft alleen de optie 'Wachtwoord wijzigen' over, hoe wil je dat aan gaan pakken?

Het wachtwoord wijzigen, zal inderdaad zonder encryptie moeten; over een onbeveiligde lijn

[ Voor 3% gewijzigd door Verwijderd op 11-02-2006 19:09 ]

[JHS]

Waarom zou je het wachtwoord wijzigen onveilig moeten laten verlopen? Encrypt (hash + (random) salt) het wachtwoord dan ook al, en vergelijk dáár gewoon altijd mee .

[cyberstalker]

JHS schreef op zaterdag 11 februari 2006 @ 19:20:
Waarom zou je het wachtwoord wijzigen onveilig moeten laten verlopen? Encrypt (hash + (random) salt) het wachtwoord dan ook al, en vergelijk dáár gewoon altijd mee .

En dan de gebruiker een md5 string toesturen waarmee deze niet kan inloggen?

[JHS]

cyberstalker schreef op zaterdag 11 februari 2006 @ 19:59:
[...]En dan de gebruiker een md5 string toesturen waarmee deze niet kan inloggen?

Hoe bedoel je? Ik zou niet de gebruiker een nieuw wachtwoord toesturen, alleen maar een nieuw wachtwoord laten aanmaken met een linkje vanuit mailbox.

Stel je registreert met wachtwoord / wijzigt het wachwoord blaat, dan wordt er hash(blaat, salt); verstuurt. Die sla je dan op in de database. Als iemand dan wil inloggen wordt er hetzelfde gedaan. Mocht daar geen encrypte voor handen zijn kan je dat alsnog serverside doen, als je dat toestaat.

Ook een random salt is te gebruiken. Je moet dan óf het wachtwoord eenmalig zonder salt versturen, dus hash(blaat);. Dan kan je elke keer dat iemand in wil loggen een salt opslaan, en de attempt tijd. Na zovel tijd is de salt dan niet meer geldig. Vanuit de clientside wordt dan hash(hash(blaat), salt); verstuurt, waarna je dat serverside vergeleken met hetzelfde, maar dan vanuit de database.

Je zou ook per user een salt kunnen instellen.

[Clock]

Maurad3r schreef op zaterdag 11 februari 2006 @ 19:03:
Het wachtwoord zal met een netwerksniffer te achterhalen zijn ja, het wordt immers onbeveiligd naar de server gestuurd en wordt DAAR pas omgezet in een md5 string. Wat je zou moeten doen is gebruik maken van SSL!

edit: of misschien javascript die voor jou de md5 string tevoorschijn tovert alovrens je de gegevesn wegpost?
http://www.google.nl/sear...s=org.mozilla:nl:official

Het wachtwoord als md5 versturen ipv als plain text haalt natuurlijk niks uit
Als een 'hackertje' het opsnift zal hij een md5 hash zien, en juist ja, de server verwacht ook een md5 hash. Dus ipv van het wachtwoord krijgt de hacker de md5 van het wachtwoord, en als hij die naar de server stuurt is hij ook binnen. Een voordeel: users gebruiken voor veel sites dezelfde pass, en die is met javascript md5 niet meer te verkrijgen (zodat hij ook op andere sites kan inloggen met dezelfde pass).

Wat je eigenlijk moet doen is op de server een unieke code genereren, die meesturen in de broncode, dan een md5 van de pass nemen, daaroverheen de md5 van de md5pass én hash samen. In dat geval kan een sniffer er helemaal niks meer mee. Dit heet ook wel CHAP, geef google eens een schop als je er betere uitleg over wil

[Pete]

Voor het inloggen opzich zou je als salt jaar-dag-minuut kunnen gebruiken. Op de server moet je dan voor een interval van 5 minuten testen welke md5 hashes daaruit komen.

Dit levert echter nog geen oplossing voor het aanmaken/wijzigen van passwords

[JHS]

phsmit schreef op zaterdag 11 februari 2006 @ 21:28:
Voor het inloggen opzich zou je als salt jaar-dag-minuut kunnen gebruiken. Op de server moet je dan voor een interval van 5 minuten testen welke md5 hashes daaruit komen.

Dat wordt behoorlijk intensief. Dan kan je beter de tijd volgens een bepaalde manier afronden naar een bepaald moment. Stel dat de user een attempt doet op 12:23, dat zou je dan af kunnen ronden naar 12:20. Als je user dan succesvol registreert / inlogt op het afgeronde tijdstip 12:20 of 12:25 (en evt. 12:30), laat je het toe. Bespaart wat load .

Dit levert echter nog geen oplossing voor het aanmaken/wijzigen van passwords

Volgens mij zijn hierboven daarvoor wil inmiddels oplossingen aangedragen ?

[X-Lars]

Enkele aardige topics over dit onderwerp:
[rml][ Alg] Website beveiliging goed opzetten *[/rml]
[rml][ JS] Hoe password MD5 encrypten voor POST wordt uitgevoerd[/rml]

[Confusion]

Clock schreef op zaterdag 11 februari 2006 @ 20:34:
Het wachtwoord als md5 versturen ipv als plain text haalt natuurlijk niks uit
Als een 'hackertje' het opsnift zal hij een md5 hash zien, en juist ja, de server verwacht ook een md5 hash. Dus ipv van het wachtwoord krijgt de hacker de md5 van het wachtwoord, en als hij die naar de server stuurt is hij ook binnen.

Als je de zaak goed configureert, kan een script niet zomaar aangeroepen worden met de MD5 hash van het wachtwoord als variabele. De enige manier om het wachtwoord bij de server te krijgen is door het wachtwoord ergens in een form in te vullen. Dat wachtwoord wordt vervolgens gehashed en de hash van een hash is geen geldig wachtwoord.

[Clock]

Confusion schreef op zaterdag 11 februari 2006 @ 23:48:
[...]

Als je de zaak goed configureert, kan een script niet zomaar aangeroepen worden met de MD5 hash van het wachtwoord als variabele. De enige manier om het wachtwoord bij de server te krijgen is door het wachtwoord ergens in een form in te vullen. Dat wachtwoord wordt vervolgens gehashed en de hash van een hash is geen geldig wachtwoord.

Juist niet dus. Als je het wachwoord ge-md5't verstuurd, moet je die ergens mee vergelijken: het ge-md5'de wachtwoord in de database. In het script wordt er dus helemaal niks meer gehasht: dat heeft de javascript al gedaan.

En het is natuurlijk simpel om even zelf een html formpje in elkaar te knutselen waarbij je de javascript md5 functionaliteit weglaat, waardoor je dus gewoon de eerder opgesnifte md5 hash naar de server kan sturen. (en er dus niks 2 keer gehasht wordt)

[ Voor 3% gewijzigd door Clock op 12-02-2006 00:02 ]

[Mephisteus]

Ik heb hier een toevoeging op. Ik heb een login systeem dat werkt door (uitgaande van een kloppend wachtwoord & zodra je je wachtwoord hebt verstuurd) een entry in de tabel maakt (eventueel IP locked). In deze entry heb je het entry id, IP, en 2 salts (zou best één salt kunnen zijn maar ik zat toen ik het gemaakt had nog wat te spelen met hash manieren e.d.).

Vervolgens wordt er een cookie aangemaakt en in de cookie staat de CRC32 van één salt (waarom, ik vond het wel geinig) de andere salt (64 characters en keuze uit alphabet/numeriek en vele special characters) en natuurlijk het entry id.
Oftewel je pass wordt alleen gecontroleerd (en verstuurd) bij het invoeren, nu moet ik daar nog een javascript op zetten om ervoor te zorgen dat hij al gehasht wordt voordat hij verstuurd wordt (of SSL).

Dus:
1. ww invoer
2. Cookie uitvoer ID, CRC van een salt en een andere salt en eventueel IP lock (database driven)

Voor het wachtwoord heb ik ook een (volgens mij wel veilig) systeem (dat werkt via SSL).
1. Je vraagt lost password mailtje aan voor een bepaald user id
2. Mailtje wordt gegenereert met userid, timestamp en salt
3. Je moet naar een url (ook SSL) en daar kan je een nieuw wachtwoord invoeren. Nu zou dit eventueel vervangen kunnen worden door een nieuw wachtwoord te genereren en dit naar voor veiligheid naar een ander adres sturen (iedereen heeft twee email adressen in de database) maar dat leek me niet handig ivm gebruiks gemak en de low profile van de site (AKA overkill ).

Ik vroeg me af of dit opzich een veilig systeem is, iemand tips/suggesties/commentaar hierop?

[Grijze Vos]

Clock schreef op zondag 12 februari 2006 @ 00:01:
[...]


Juist niet dus. Als je het wachwoord ge-md5't verstuurd, moet je die ergens mee vergelijken: het ge-md5'de wachtwoord in de database. In het script wordt er dus helemaal niks meer gehasht: dat heeft de javascript al gedaan.

En het is natuurlijk simpel om even zelf een html formpje in elkaar te knutselen waarbij je de javascript md5 functionaliteit weglaat, waardoor je dus gewoon de eerder opgesnifte md5 hash naar de server kan sturen. (en er dus niks 2 keer gehasht wordt)

Wat je doet, is de server een salt mee laten sturen naar de client. Javascript client-side doet dan het wachtwoord + die salt md5'en. Aangezien die salt elke keer verandert, heb je niks aan die ene md5-code die je gesnifft hebt.

[JHS]

Grijze Vos schreef op zondag 12 februari 2006 @ 02:53:
[...]Wat je doet, is de server een salt mee laten sturen naar de client. Javascript client-side doet dan het wachtwoord + die salt md5'en. Aangezien die salt elke keer verandert, heb je niks aan die ene md5-code die je gesnifft hebt.

Als je het verkeer van de gesiffte blokkeert en/of snel genoeg bent kan je een sessie aanmaken, lijkt me .

[Clock]

Grijze Vos schreef op zondag 12 februari 2006 @ 02:53:
[...]

Wat je doet, is de server een salt mee laten sturen naar de client. Javascript client-side doet dan het wachtwoord + die salt md5'en. Aangezien die salt elke keer verandert, heb je niks aan die ene md5-code die je gesnifft hebt.

Zeker, maar dat stond ook in mijn eerdere post Dit ging over _alleen het wachtwoord_ hashen voordat je het naar de server verstuurd.
Dat wat jij doet heet toch niet salten maar CHAP? (Challenge Handshake Authentication Protocol)

[Olaf van der Spek]

Verwijderd schreef op zaterdag 11 februari 2006 @ 19:07:
[...]


Op dit moment encrypt ik de gegevens al met javascript, maar wil het eigenlijk een beetje makkelijker (als het kan ).
SSL vind de eigenaar van de website helaas te duur; anders had ik daar zeker voor gekozen.

Wat is er precies duur aan SSL?

[Olaf van der Spek]

JHS schreef op zaterdag 11 februari 2006 @ 21:53:
[...]
Dat wordt behoorlijk intensief. Dan kan je beter de tijd volgens een bepaalde manier afronden naar een bepaald moment. Stel dat de user een attempt doet op 12:23, dat zou je dan af kunnen ronden naar 12:20. Als je user dan succesvol registreert / inlogt op het afgeronde tijdstip 12:20 of 12:25 (en evt. 12:30), laat je het toe. Bespaart wat load .

Je kunt in het form (hidden) toch gewoon aangeven welke tijd je hebt gebruikt?

[Olaf van der Spek]

JHS schreef op zondag 12 februari 2006 @ 08:49:
[...]
Als je het verkeer van de gesiffte blokkeert en/of snel genoeg bent kan je een sessie aanmaken, lijkt me .

Waarom moeilijk doen als het makkelijk kan?
Laat de gebruiker zelf een sessie openen en surf dan gewoon mee op zijn sessie.

[JHS]

OlafvdSpek schreef op zondag 12 februari 2006 @ 11:46:
[...] Je kunt in het form (hidden) toch gewoon aangeven welke tijd je hebt gebruikt?

Dan is het voordeel van het gebruiken van een salt weg, lijkt me .

Wat is er precies duur aan SSL?

Het certificaat

Overigens kan je best drie quotes doen in één post in plaats van drie aparte posts .

[Ramon]

Clock schreef op zondag 12 februari 2006 @ 00:01:
[...]
En het is natuurlijk simpel om even zelf een html formpje in elkaar te knutselen waarbij je de javascript md5 functionaliteit weglaat, waardoor je dus gewoon de eerder opgesnifte md5 hash naar de server kan sturen. (en er dus niks 2 keer gehasht wordt)

referer check lijkt me altijd wel handig....

[Skaah]

Je kan nu XSS toepassen op jouw pagina! Zie hier voor een uitleg. $_SERVER['PHP_SELF'] is niet veilig nl.

[Clock]

Ramon de Jesus schreef op zondag 12 februari 2006 @ 11:59:
[...]
referer check lijkt me altijd wel handig....

Jup, maar helaas doet vrijwel niemand dit. En een referer-url is enorm makkelijk te faken (denkt aan de 101 spoofers-progjes die je zo rond ziet zwerven).

[Olaf van der Spek]

JHS schreef op zondag 12 februari 2006 @ 11:55:
Dan is het voordeel van het gebruiken van een salt weg, lijkt me .

Volgens mij niet.

Het certificaat

Dat kun je self signen. Is natuurlijk niet zo goed als een 'echt' certificaat maar nog steeds stukken beter dan geen certificaat/encryptie.

Overigens kan je best drie quotes doen in één post in plaats van drie aparte posts .

Helaas ondersteunt GoT geen auto-joining van meerdere posts achter elkaar en ben ik soms te lui om het handmatig te doen.

[JHS]

OlafvdSpek schreef op zondag 12 februari 2006 @ 12:22:
[...]Volgens mij niet.

Ja, dan kan je weer een andere (random) salt aanmaken, maar de grap was nu juist dat doordat de salt hash(datum, tijd) is, je tegelijkertijd een controle met de datum kan uitvoeren.

edit:

Plus wat Clock zegt .

[...] Helaas ondersteunt GoT geen auto-joining van meerdere posts achter elkaar en ben ik soms te lui om het handmatig te doen.

Druk als je de eerste post hebt gequote maar 's op het quote icoontje .

[ Voor 4% gewijzigd door JHS op 12-02-2006 12:33 ]

[Clock]

OlafvdSpek schreef op zondag 12 februari 2006 @ 12:22:
[...]

Volgens mij niet.

Volgens mij wel. Waarom haal je al die trucs uit? Juist, om het makkelijk opsniffen van de plain-text wachtwoorden tegen te gaan. Maar als jij vervolgens alle gegevens waarmee de hash gemaakt wordt mee stuurt met het form (en het dus makkelijk snifbaar maakt), zal de persoon met kwade bedoelingen met die data toch zelf de hash kunnen maken. Alle dingen die nodig zijn voor die hash heeft ie immers.

[Olaf van der Spek]

Clock schreef op zondag 12 februari 2006 @ 12:30:
Volgens mij wel. Waarom haal je al die trucs uit? Juist, om het makkelijk opsniffen van de plain-text wachtwoorden tegen te gaan. Maar als jij vervolgens alle gegevens waarmee de hash gemaakt wordt mee stuurt met het form (en het dus makkelijk snifbaar maakt), zal de persoon met kwade bedoelingen met die data toch zelf de hash kunnen maken. Alle dingen die nodig zijn voor die hash heeft ie immers.

Het enige geheim dat de gebruiker heeft is het wachtwoord. Door een hash van het wachtwoord te sturen voorkom je sniffing van het plaintext wachtwoord. Door een challenge/response handshake te gebruiken voorkom je replay attacks.
Het is mij even niet duidelijk hoe je een salt wil gebruiken zodat de aanvaller het niet weet maar de gebruiker wel.

Maar het voorkomen van replay login attacks is volgens mij zinloos zolang je met sessies over een onbeveiligde lijn werkt.

[ Voor 7% gewijzigd door Olaf van der Spek op 12-02-2006 12:59 ]

[Confusion]

Clock schreef op zondag 12 februari 2006 @ 00:01:
In het script wordt er dus helemaal niks meer gehasht: dat heeft de javascript al gedaan.

Je hebt gelijk.

offtopic:
Vreemd dat ik af en toe dingen vergeet die ik eigenlijk al wist.

[Clock]

OlafvdSpek schreef op zondag 12 februari 2006 @ 12:42:
[...]

Het enige geheim dat de gebruiker heeft is het wachtwoord. Door een hash van het wachtwoord te sturen voorkom je sniffing van het plaintext wachtwoord. Door een challenge/response handshake te gebruiken voorkom je replay attacks.
Het is mij even niet duidelijk hoe je een salt wil gebruiken zodat de aanvaller het niet weet maar de gebruiker wel.

Maar het voorkomen van replay login attacks is volgens mij zinloos zolang je met sessies over een onbeveiligde lijn werkt.

Niet dus... Als jij een wachtwoord (met javascript) hasht is dat is feite niks anders dan het anders opschrijven zodat het niet meer leesbaar is. De server verwacht dat er een md5 hash binnenkomt, en vergelijkt die hash met de hash uit de database. Dus de hacker ziet een hash ipv een plain-text wachtwoord een md5 hash. Maar die hash kan hij gewoon naar de server sturen en dan is hij ook binnen. En hier komt het CHAP principe dus om de hoek kijken. Daarmee wordt niet de md5 van het pass verstuurd, maar die die eerst gehasht met een unieke code die _alleen_ de client en de server weet. Een sniffer kan dus helemaal niks met de gesnifte hash, omdat die unieke code bij elke login-page request anders is.

* 2e keer dat ik dit probeer uit te leggen *

[Olaf van der Spek]

Clock schreef op zondag 12 februari 2006 @ 13:23:
Niet dus... Als jij een wachtwoord (met javascript) hasht is dat is feite niks anders dan het anders

Wel dus. Ik zei niet dat het voldoende was tegen replay attacks, alleen dat je het plaintext wachtwoord er niet mee kon achterhalen.

opschrijven zodat het niet meer leesbaar is. De server verwacht dat er een md5 hash binnenkomt, en vergelijkt die hash met de hash uit de database. Dus de hacker ziet een hash ipv een plain-text wachtwoord een md5 hash. Maar die hash kan hij gewoon naar de server sturen en dan is hij ook binnen. En hier komt het CHAP principe dus om de hoek kijken. Daarmee wordt niet de md5 van het pass verstuurd, maar die die eerst gehasht met een unieke code die _alleen_ de client en de server weet. Een sniffer kan dus helemaal niks met de gesnifte hash, omdat die unieke code bij elke login-page request anders is.

* 2e keer dat ik dit probeer uit te leggen *

Ik ken het CHAP principe.
Maar ik vind ook dat het geen nut heeft als je daarna sessies (via cookies) gebruikt over een onbeveiligde lijn.

In [rml][ php] User authenticatie veilig? "Hacker-proof"?[/rml] is deze discussies trouwens ook gevoerd.

[ Voor 41% gewijzigd door Olaf van der Spek op 12-02-2006 13:38 ]

[Verwijderd]

Clock schreef op zondag 12 februari 2006 @ 13:23:

Niet dus... Als jij een wachtwoord (met javascript) hasht is dat is feite niks anders dan het anders opschrijven zodat het niet meer leesbaar is. De server verwacht dat er een md5 hash binnenkomt, en vergelijkt die hash met de hash uit de database. Dus de hacker ziet een hash ipv een plain-text wachtwoord een md5 hash. Maar die hash kan hij gewoon naar de server sturen en dan is hij ook binnen. En hier komt het CHAP principe dus om de hoek kijken. Daarmee wordt niet de md5 van het pass verstuurd, maar die die eerst gehasht met een unieke code die _alleen_ de client en de server weet. Een sniffer kan dus helemaal niks met de gesnifte hash, omdat die unieke code bij elke login-page request anders is.

* 2e keer dat ik dit probeer uit te leggen *

Jaahaaaa, maar het originele wachtwoord is tenminste niet te achterhalen. En dat kan wel zo prettig zijn als iemand hetzelfde wachtwoord voor verschillende doeleinden gebruikt. En dat is eigenlijk ook het enige waar die hele md5 voor is bedoeld onder deze omstandigheden. De rest is extra beveiliging, maar het wachtwoord was in elk geval dan al veilig gesteld.

[ Voor 110% gewijzigd door Verwijderd op 12-02-2006 13:37 ]

[Clock]

OlafvdSpek schreef op zondag 12 februari 2006 @ 13:34:
[...]

Ik ken het CHAP principe.
Maar ik vind ook dat het geen nut heeft als je daarna sessies (via cookies) gebruikt over een onbeveiligde lijn.

Sessies koppel je aan een IP, die je bij het inloggen in een sessievar gooit. Bij elke page request controleer je of het IP degene die de page aanvraagd gelijk is aan het IP van degene die is ingelogd. Zo nee? nogmaals laten inloggen. Heel simpel te doen, en zo voorkom je dus de door jou genoemde session hijacking.

[Clock]

Verwijderd schreef op zondag 12 februari 2006 @ 13:36:
[...]
Jaahaaaa, maar het originele wachtwoord is tenminste niet te achterhalen. En dat kan wel zo prettig zijn als iemand hetzelfde wachtwoord voor verschillende doeleinden gebruikt. En dat is eigenlijk ook het enige waar die hele md5 voor is bedoeld onder deze omstandigheden. De rest is extra beveiliging, maar het wachtwoord was in elk geval dan al veilig gesteld.

Had ik op de eerste pagina ook genoemd

Clock schreef op zaterdag 11 februari 2006 @ 20:34:
[...]
Een voordeel: users gebruiken voor veel sites dezelfde pass, en die is met javascript md5 niet meer te verkrijgen (zodat hij ook op andere sites kan inloggen met dezelfde pass).

[Olaf van der Spek]

Clock schreef op zondag 12 februari 2006 @ 13:39:
Sessies koppel je aan een IP, die je bij het inloggen in een sessievar gooit.

Dat is niet veilig als de aanvaller hetzelfde IP adres heeft.
En het werkt ook niet als een bezoeker meerdere IP adressen heeft.
Ook gaat het fout als de aanvaller zijn replay response eerder bij de server krijgt dan het originele response.

[Clock]

Om ff voor mezelf en voor anderen (wie dat interesseert dan) alles 'op een rijtje te zetten'. Waaraan moet een semi veilig (lees: zonder SSL) loginsysteem aan voldoen:

• CHAP (Challenge-Handshake Authentication Protocol). Bij het aanroepen van de login-page start je een sessie, en in een sessievar gooi je een unieke code (iets van 20 tekens lang). Die code geef je mee aan je javascript door het gewoon simpel te echo'en binnen de source. Zogauw het formulier door de user gesubmit wordt laat je de javascript de md5 (of de SHA1) van het password berekenen. Vervolgens laat je javascript de md5 berekenen van je pasberekende md5-pass én de unieke code die je in de source ge-echo''t had. Die hash verstuur je naar de server samen met de loginnaam (zorg er wel voor dat je het oorspronkelijke pasword field even leeg maakt, anders heeft het natuurlijk allemaal geen zin). Op de server kan je die hash zelf ook maken, met het md5 (of SHA1) password uit de database + de unieke code uit de sessie. Komen die 2 hashes overeen, dan klopt het wachtwoord en ben je ingelogd.
• Elk IP-adres mag 3 keer proberen in te loggen. Na 3 keer een foute combinatie te hebben gegeven mag je een kwartier (oid) niet meer proberen)
• Bij een cookie login (automatisch inloggen aand de hand van een eerde gesette cookie) maak je 1 cookie waarin het user_id staat, en 1 cookie met een unieke code. Die code zet je ook in de database, samen met de tijd. Dan kan je kijken of de code in de database overeenkomt met die in de cookie, zo ja => ingelogd. Zie wel in dat dit een potentieel security risico is! (ivm met het stelen van cookies en een IP spoofer)
• Kijk heel erg uit voor SQL Injection (zeer basic, maar toch zijn er veel mensen die de user iput rechtstreeks in de quey gooien)
• Als je hebt gesteld dat een loginnaam / wachtoord tussen de X en de Y tekens moet hebben, controleer daar dan ook op! (Als je CHAP gebruikt moet het wachtwoord dus 32 (md5 hash) of anders 40 (SHA1 hash) tekens lang zijn. Zo niet? onmiddelijk stoppen). Dit controleer je niet met javascript (heeft geen zin: makkelijk te omzeilen), maar echt server-side. Je gegevens goed valideren dus.
• Koppel de sessie die je maakt aan het IP van degene die inlogd, zo voorkom je session hijacking. Dus bij het inloggen gooi het het IP van degene die zojuist succesvol is ingelogd is een sessievar, en bij elke page request kijk je of het IP van dege die de page aanvraagd overeenkomt met het IP in je sessievar.

Volgens mij zijn dat de belangrijkste punten. _Natuurlijk_ is het veel beter gewoon SSL te gebruiken, maar mocht je daar niet de beschikking over hebben betekent dat natuurlijk niet dat je maar moet accepteren dat het toch niet veilig wordt: dit is een redelijk alternatief. Als iemand aanvullingen of opmerkingen heeft hoor ik het graag.

NB: ik zie dat de discussie idd al gevoerd is, maar meer is altijd beter toch?

[ Voor 4% gewijzigd door Clock op 12-02-2006 14:12 ]

[Clock]

OlafvdSpek schreef op zondag 12 februari 2006 @ 13:43:
[...]

Dat is niet veilig als de aanvaller hetzelfde IP adres heeft.
En het werkt ook niet als een bezoeker meerdere IP adressen heeft.
Ook gaat het fout als de aanvaller zijn replay response eerder bij de server krijgt dan het originele response.

Dan gaat het idd fout, maar dat zijn allemaal uitzonderingen. Bedrijven hebben allemaal hetzelfde uitgaande IP ja, maar het is wellicht makkelijk om dan gewoon over de schouder van de desbetreffende collega mee te kijken dan met sniffers in de weer te gaan op een bedrijfsnetwerk.

Users die verschillende IP's hebben, hoe stel je je dat voor? Dat om de 10 minuten de user ineens een ander IP krijgt? Lijkt me heel stug. Het gaat alleen om de sessie, het betekent niet dat de user alleen maar mag inloggen vanaf dat IP, maar die sessie is gekoppeld aan het IP.

De aanvaller heeft op zijn allerhoogst 3 seconden om de waarden van het gesnifte formulier (de hash en de gebruikersnaam) naar de server te sturen. En dan moet ie ook tegelijkertijd de sessie overnemen, want in de sessie staat de unieke code waarmee de hash wordt vergeleken: redelijk onmogelijk.

Natuurlijk zijn er uitzonderingen te bedenken, maar als je gebruik maakt van het bovenstaande login-systeem ben je al een _heel_ stuk veiliger bezig dan een gewoon login scriptje. En nee, het haalt het niet bij SSL, maar nogmaals: niet iedereen heeft daar beschikking over.

[Olaf van der Spek]

Clock schreef op zondag 12 februari 2006 @ 13:55:
Dan gaat het idd fout, maar dat zijn allemaal uitzonderingen. Bedrijven hebben allemaal hetzelfde uitgaande IP ja, maar het is wellicht makkelijk om dan gewoon over de schouder van de desbetreffende collega mee te kijken dan met sniffers in de weer te gaan op een bedrijfsnetwerk.

Soms wel, soms niet. En in het niet geval kan het een redelijk issue zijn.

Users die verschillende IP's hebben, hoe stel je je dat voor? Dat om de 10 minuten de user ineens een ander IP krijgt? Lijkt me heel stug. Het gaat alleen om de sessie, het betekent niet dat de user alleen maar mag inloggen vanaf dat IP, maar die sessie is gekoppeld aan het IP.

Bijvoorbeeld dat een gebruiker (of bedrijf of ISP) achter een proxy of NAT zit met X uitgaande lijnen.
Het is geen lek, maar de gebruiker moet dan wel X keer inloggen wat niet zo handig is.

De aanvaller heeft op zijn allerhoogst 3 seconden om de waarden van het gesnifte formulier (de hash en de gebruikersnaam) naar de server te sturen. En dan moet ie ook tegelijkertijd de sessie overnemen, want in de sessie staat de unieke code waarmee de hash wordt vergeleken: redelijk onmogelijk.

3 s is lang genoeg voor een script hoor.

Natuurlijk zijn er uitzonderingen te bedenken, maar als je gebruik maakt van het bovenstaande login-systeem ben je al een _heel_ stuk veiliger bezig dan een gewoon login scriptje. En nee, het haalt het niet bij SSL, maar nogmaals: niet iedereen heeft daar beschikking over.

De IP adres lock is wel redelijk cruciaal.

[Clock]

OlafvdSpek schreef op zondag 12 februari 2006 @ 13:58:
[...]
Soms wel, soms niet. En in het niet geval kan het een redelijk issue zijn.

Mocht je info zo gevoelig zijn en verwacht je dat zoiets een issue kan worden heb je waarschijnlijk ook wel zoveel geld/tijd/personeel tot je beschikking om SSL te gebruiken

[...]
Bijvoorbeeld dat een gebruiker (of bedrijf of ISP) achter een proxy of NAT zit met X uitgaande lijnen.
Het is geen lek, maar de gebruiker moet dan wel X keer inloggen wat niet zo handig is.
[...]

Tsja, komt niet echt vaak voor wel? En dan zal de user maar vaker moeten inloggen, of anders knutsel je er een automatisch cookie login stukje bij (alhoewel je daar natuurlijk wel een extra securityrisk mee maakt => niet te vermijden bij automatisch inloggen)

3 s is lang genoeg voor een script hoor.

Een script dat de formwaarden van een user snift, een sessie die gekoppeld is aan een IP overneemt, en de waarden naar de server post in de tijd die er tussen zit dat de user op submit drukt en de data bij de server aankomt? Sorry, maar ik denk niet dat dat haalbaar is. Meestal duurt zoiets 0.3 seconden, en als het langer duurt doordat de server traag is (oid) heb jij óók met die vertraging te maken.

[...]
De IP adres lock is wel redelijk cruciaal.

Ja? Maar die zit er dus ook in? Ik zie het punt niet echt

[Olaf van der Spek]

Clock schreef op zondag 12 februari 2006 @ 14:10:
Tsja, komt niet echt vaak voor wel? En dan zal de user maar vaker moeten inloggen, of anders knutsel je er een automatisch cookie login stukje bij (alhoewel je daar natuurlijk wel een extra securityrisk mee maakt => niet te vermijden bij automatisch inloggen)

In Nederland bij consumenten niet, maar ik ken de situatie bij bedrijven en in alle andere landen niet.

[Verwijderd]

OlafvdSpek schreef op zondag 12 februari 2006 @ 11:44:
[...]

Wat is er precies duur aan SSL?

Waarom SSL duur is weet ik niet precies, ik weet wel dat het bij hun provider € 75,00 kost per jaar.
Op dit moment zijn de kosten voor de website ver onder deze € 75,00

[Verwijderd]

Wat is beter?

De 'challengecode' als hidden field ge-md5-ed bij de client planten en die meeposten. En dan het passworden sha1-en en versturen. edit: "totaal nutteloos"

Of:
De challengecode niet ge-md5-ed naar de client sturen, en dan samen met het password md5-en / sha1-en, en dan vergelijken op de server. En de challenge code niet apart mee sturen.

Of een combinatie van de hierboven beschreven dingen.

Voordeel van een losse challengecode meesturen lijkt me dat je deze ook kan checken als er nog geen pass is, bv bij een nieuwe user, en nog een voordeel lijkt me dat je de pass gelijk kan checken in mysql. (Waar ik nu een topic over heb lopen)

[ Voor 8% gewijzigd door Verwijderd op 13-02-2006 14:19 ]

[Olaf van der Spek]

Verwijderd schreef op maandag 13 februari 2006 @ 13:29:
Wat is beter?

De 'challengecode' als hidden field ge-md5-ed bij de client planten en die meeposten. En dan het passworden sha1-en en versturen.

Dat is totaal nutteloos.

[Verwijderd]

OlafvdSpek schreef op maandag 13 februari 2006 @ 13:41:
[...]

Dat is totaal nutteloos.

Omdat de 'hacker' dan ook die kan intercepten en kan versturen? of wat? Misschien had ik er wat langer over na moeten denkn

[ Voor 48% gewijzigd door Verwijderd op 13-02-2006 14:40 ]

[Olaf van der Spek]

Verwijderd schreef op maandag 13 februari 2006 @ 14:09:
Omdat de 'hacker' dan ook die kan intercepten en kan versturen? of wat? Misschien had ik er wat langer over na moeten denkn

Ja. Als je een beveiligingsconcept bedenkt moet je eerst bedenken welk scenario precies voorkomen moet worden.

[Verwijderd]

Ik vind dit een zeer interessant topic moet ik zeggen. Vooral het chap principe was nieuw voor mij.

Mijn login ziet er nu zo uit:

Login pagina wordt geopend:

PHP:

$uniqid = md5(uniqid(rand(), true));
                $_SESSION['uniqid'] = $uniqid;

$uniqdid wordt meegegeven als een hidden field aan de page.

Login wordt gesubmit:

code:

if (thisform[i].id == "password"){
            if (thisform["encrypt"].value == 1){
             post1[thisform[i].id] = calcSHA1((thisform['uniqid'].value+calcSHA1(thisform[i].value)));
             alert( post1[thisform[i].id]);
            }
        }

Code komt aan op server (via ajax):

PHP:

$selected = $data->do_query(sprintf("SELECT IF( SHA1(Concat(%s,password)) =%s , type , 'no' ) as result, user_id FROM userdata  WHERE email = %s",
            quote_smart($_SESSION['uniqid']),
            quote_smart($password),
            quote_smart($email)));

(over de query is uitgebreid gepraat in andere topic)

Als hieruit blijkt dat het pw goed is:

PHP:

$_SESSION['user_ip'] = md5($_SERVER['REMOTE_ADDR']);

en dan dus bij de betreffende pagina's de ip checken. Ik ben al de hele tijd bezig met andere (uitgebreidere) session funcites te implementeren, maar dat lukt niet goed omdat ik Ajax gebruik.

Ben ik een beetje op weg naar een veilige login?

[Verwijderd]

Verwijderd schreef op maandag 13 februari 2006 @ 17:08:
Ben ik een beetje op weg naar een veilige login?

Voor zover ik het kan volgen, ziet het er goed uit
Alleen die query snap ik niet helemaal, maar dat zal wel goed zijn als daar een topic over is geweest

[Verwijderd]

OlafvdSpek schreef op zondag 12 februari 2006 @ 11:44:
Wat is er precies duur aan SSL?

Je betaalt voor het naampje van VeriSign of andere cert organisatie. Maar er zijn ook voldoende organisaties die gratis certs uitdelen, bijvoorbeeld CAcert. Het enige nadeel is dat je gebruiker even hun rootcert moet installeren, maar zoveel moeite is dat niet.

Op mijn werk gebruik ik dit, voor 90 man personeel. Het is geen enkel probleem dmv een simpele instructie (link naar rootcert) op de website, voordat je overschakeld naar de SSL variant.

[ Voor 6% gewijzigd door Verwijderd op 13-02-2006 22:48 ]

[Grijze Vos]

Clock schreef op zondag 12 februari 2006 @ 11:25:
[...]


Zeker, maar dat stond ook in mijn eerdere post Dit ging over _alleen het wachtwoord_ hashen voordat je het naar de server verstuurd.
Dat wat jij doet heet toch niet salten maar CHAP? (Challenge Handshake Authentication Protocol)

Je genereert een unieke string (of je noemt het ID, of wat ook), dat zou je een salt kunnen noemen. Het protocol heet inderdaad CHAP, maar daar kwam ik bij mijn vorige post toevallig niet op.