[PHP] Loginscript, is dit veilig?

[Verwijderd]

Hallo,

ik ben bezig met een loginscriptje. Waar ik nu mee begonnen ben is een session_start(), hierdoor krijg je je SessieID, als je dan bij het login form komt, username/password invullen, als die kloppen maakt hij rij in database met ip/sessieID/gebruiker/expire, en dan ben je ingelogd,

als je dan de volgende pagina bezoekt, wordt je sessieID gecheckt, en als die klopt met je IP in database, ben je ingelogged, anders word je terug naar login form gestuurd. Dit werkt wel, voor zover ik weet,

Maar is het veilig als ik het zo gebruik, kan je iemand zn ip faken en sessieID stelen? of zit er een andere grove fout in?

- als het niet duidelijk ik zal ik wel de source posten, maar die is ook niet echt duidelijk

thnx. Aprominax

[Flapp]

Voor zover ik weet is het redelijk ingewikkeld om een sessieID te stelen aangezien een sessie, serverside is in tegenstelling tot cookies.

Wat je wel kan doen is dit ook nog combineren met een cookie als een extra beveiliging,

je moet er in ieder geval op letten dat je de sessie id nooit met een GET doorgeeft

[Verwijderd]

Maar welke data zou ik dan in de cookie moeten zetten, nog een keer het sessieID?

En cookie dan vergelijken met de sessie database en de session_id(), als die niet allemaal gelijk zijn, met ip-check erbij, dan log je uit?

[flexje]

Waarom laat je de gebruiker niet zijn username en wachtwoord eerst opgeven....
Na het opgeven kijk je of de gebruiker voorkomt in de database, zo ja, dan creeer je een sessie met de username of whatever voor de rest van de pagina's

[Verwijderd]

Dat komt toch op ongeveer hetzelfde neer, alleen dat je geen sessie hebt als je niet bent ingelogd, of zie ik dat verkeerd? noujah, zou ook eigenlijk best kunnen, maar ga nu slapen, bedankt iig

[Megamind]

Wat flexje zegt is volgens mij genoeg.

Sessies kan je toch niet zo makkelijk stelen, dus als je een sessie aanmaakt met $_SESSION["logged_in_user_id"] en daar de userid aanvast knoopt is het voldoende.

[webinn]

let op met IP's

er zijn providers waar die heel snel wijzigen (zelfs in een sessie!). Ik spreek uit ervaring, want ik heb zelf ook geprobeerd. Een klant in India vloog er om de paar minuten uit met een gewijzigd IP. Die IP-lock kan je dus best optioneel doen (zoals hier op tweakers)

[Erkens]

webinn schreef op zaterdag 13 januari 2007 @ 09:12:
er zijn providers waar die heel snel wijzigen (zelfs in een sessie!).

Ook proxy servers van grote bedrijven willen er nog wel eens voor zorgen dat het "IP" van de bezoeker om de request anders is, en dat komt vaker voor dan die providers waar jij het over hebt

[EnsconcE]

Megamind schreef op zaterdag 13 januari 2007 @ 09:00:
Wat flexje zegt is volgens mij genoeg.

Sessies kan je toch niet zo makkelijk stelen, dus als je een sessie aanmaakt met $_SESSION["logged_in_user_id"] en daar de userid aanvast knoopt is het voldoende.

Maar een username in een cookie is niet zo handig, die kan namelijk gewijzigd worden in een gewenste username . Je kan beter de sessie registreren in de cookie om aan de hand daarvan te user te controleren. Je kan evt een eigen variable random genereren, registreren als $_SESSION["logged_in_user_uid"].

[Erkens]

EnsconcE schreef op zaterdag 13 januari 2007 @ 09:31:
[...]


Maar een username in een cookie is niet zo handig, die kan namelijk gewijzigd worden in een gewenste username . Je kan beter de sessie registreren in de cookie om aan de hand daarvan te user te controleren. Je kan evt een eigen variable random genereren, registreren als $_SESSION["logged_in_user_uid"].

dat is toch wat er gebeurd?

[webinn]

Erkens schreef op zaterdag 13 januari 2007 @ 09:19:
[...]

Ook proxy servers van grote bedrijven willen er nog wel eens voor zorgen dat het "IP" van de bezoeker om de request anders is, en dat komt vaker voor dan die providers waar jij het over hebt

inderdaad, zou werken met $_SERVER[REMOTE_HOST] dan een betere oplossing zijn om extra zekerheid te krijgen?

[ Voor 0% gewijzigd door webinn op 13-01-2007 10:18 . Reden: typo ]

[Erkens]

webinn schreef op zaterdag 13 januari 2007 @ 10:17:
inderdaad, zou werken met $_SERVER[REMOTE_HOST] dan een betere oplossing zijn om extra zekerheid te krijgen?

nee

[webinn]

Erkens schreef op zaterdag 13 januari 2007 @ 10:37:
[...]

nee

nee omdat.... dat ook veranderd?

[ Voor 6% gewijzigd door webinn op 13-01-2007 10:43 ]

[Depress]

Waarschijnlijk wel idd.

Maar wat sla je nu op in de sessie? Het ID? Maak daar iets van als een hash van de microtime. Is het altijd anders, en mensen met proxy's die op een of andere manier aan het sessionid zijn gekomen kunnen alleen een lopende sessie gebruiken, terwijl nu gewoon een willekeurige sessie kan worden gekraakt...

[SlinkingAnt]

Misschien is het interessant om hierrrr eens naar te kijken?

[JayVee]

Het beste kun je op zoek gaan naar een goed kant en klaar login script. Er komen zo veel zaken kijken (session hijacking, session fixation, challenge response) om een login script echt veilig te krijgen, die verzin je niet allemaal zelf.

Als je het wel graag zelf wilt doen moet je even goed de literatuur induiken. Er zijn met Google zat artikels te vinden mbt. login scripts (en de boven genoemde issues).

[ Voor 3% gewijzigd door JayVee op 13-01-2007 12:07 ]

[Erkens]

JayVee schreef op zaterdag 13 januari 2007 @ 12:06:
Het beste kun je op zoek gaan naar een goed kant en klaar login script. Er komen zo veel zaken kijken (session hijacking, session fixation, challenge response) om een login script echt veilig te krijgen, die verzin je niet allemaal zelf.

en de meeste kant-en-klaar scripts bevatten die security checks meestal niet

[stekkel]

Bij ieder page request zou je de login moeten valideren. Dat betekend dat je na de login pagina je password ergens moet opslaan.
Een redelijk veilige manier is het password encrypten en de sleutel om het te decrypten in een cookie op te slaan. Het encrypted password kan dan in de session opgeslagen worden.
Bij een session hijack kan men dan nog geen schade aanrichten omdat de login niet kan valideren vanwege het ontbreken van de sleutel voor de decryptie van het password.
De decryptie sleutel moet uiteraard per sessie opnieuw unieke gegenereerd worden.

[Verwijderd]

Oke, ik zie dus al dat het veel ingewikkelder gaat worden dan ik dacht, ik ga de link van SlinkingAnt
even lezen, hopelijk helpt dat iets, en verder had ik al zelf gezocht naar login scripts, maar heb er niet eentje kunnen vinden die volgensmij goed werkt en ook veilig is, maar ik ga even zoeken. of kent iemand misschien toevallig een scripje?

[Erkens]

stekkel schreef op zaterdag 13 januari 2007 @ 13:08:
Bij ieder page request zou je de login moeten valideren. Dat betekend dat je na de login pagina je password ergens moet opslaan.
Een redelijk veilige manier is het password encrypten en de sleutel om het te decrypten in een cookie op te slaan. Het encrypted password kan dan in de session opgeslagen worden.
Bij een session hijack kan men dan nog geen schade aanrichten omdat de login niet kan valideren vanwege het ontbreken van de sleutel voor de decryptie van het password.
De decryptie sleutel moet uiteraard per sessie opnieuw unieke gegenereerd worden.

password moet je helemaal niet opslaan, deze moet gewoon in je database (oid) blijven en _niet_ in je session (en al helemaal niet in een cookie) in je session hoef je alleen maar de user id op te slaan, want je bepaald zelf wat er in je session staat dus dat is voldoende om te zien of iemand ingelogd is.

[EnsconcE]

Erkens schreef op zaterdag 13 januari 2007 @ 14:07:
[...]

password moet je helemaal niet opslaan, deze moet gewoon in je database (oid) blijven en _niet_ in je session (en al helemaal niet in een cookie) in je session hoef je alleen maar de user id op te slaan, want je bepaald zelf wat er in je session staat dus dat is voldoende om te zien of iemand ingelogd is.

Je kan beter geen voor de hand liggen informatie in je cookie stoppen. Dit is dan te wijzigen door een malafide gebruiker. Stop er gegevens in die je ook in je sessie heb staan, encrypt dat wel! Crisp legt het ook heel mooi uit.

[stekkel]

Erkens schreef op zaterdag 13 januari 2007 @ 14:07:
[...]

password moet je helemaal niet opslaan, deze moet gewoon in je database (oid) blijven en _niet_ in je session (en al helemaal niet in een cookie) in je session hoef je alleen maar de user id op te slaan, want je bepaald zelf wat er in je session staat dus dat is voldoende om te zien of iemand ingelogd is.

Ik denk dat je me verkeerd begrepen hebt. Tuurlijk sla ik het password niet op in de session.

Ik sla een encrypted vorm van het password op waar je dus alleen maar wat aan hebt als je zowel de sessie als de cookie van de gebruiker kan achterhalen.

In jouw geval waar je geen validatie meer toepast nadat je eenmaal een sessie hebt heb je volledige toegang wanneer een session hijack plaatsvind.
Bij mijn methode zal bij een session hijack gelijk de session afgebroken worden omdat er niet gevalideerd kan worden door het ontbreken van een password.

Overigens, dit is de methode die SquirrelMail al jaren gebruikt en dat is nog nooit een security issue geweest. Er van uitgaande dat bij tientallen miljoenen gebruikers en regelmatig onafhankelijke partijene die een vergrootglas op de source code leggen ga ik er vanuit dat de gebruikte methode toch wel redelijk veilig is.

[ Voor 43% gewijzigd door stekkel op 13-01-2007 15:35 ]

[marko77]

JayVee schreef op zaterdag 13 januari 2007 @ 12:06:
Het beste kun je op zoek gaan naar een goed kant en klaar login script. Er komen zo veel zaken kijken (session hijacking, session fixation, challenge response) om een login script echt veilig te krijgen, die verzin je niet allemaal zelf.

Als je het wel graag zelf wilt doen moet je even goed de literatuur induiken. Er zijn met Google zat artikels te vinden mbt. login scripts (en de boven genoemde issues).

Dat klopt inderdaad, máár als je gaat googlen kom je heel veel scripts tegen die allemaal 'beweren' goed te zijn. Ik heb dit van de zomer zelf uitgezocht, en je moet echt even geduld hebben met uitzoeken.

Maar dan heb je ook wel een goed script, die ook door anderen is getest c.q. gedebugged.

[Erkens]

stekkel schreef op zaterdag 13 januari 2007 @ 15:28:
Ik sla een encrypted vorm van het password op waar je dus alleen maar wat aan hebt als je zowel de sessie als de cookie van de gebruiker kan achterhalen.

encrypted of niet, het heeft geen nut

In jouw geval waar je geen validatie meer toepast nadat je eenmaal een sessie hebt heb je volledige toegang wanneer een session hijack plaatsvind.
Bij mijn methode zal bij een session hijack gelijk de session afgebroken worden omdat er niet gevalideerd kan worden door het ontbreken van een password.

als ik die session hijack dan is dat wachtwoord nog steeds in die session, dus wat is het verschil?

Overigens, dit is de methode die SquirrelMail al jaren gebruikt en dat is nog nooit een security issue geweest. Er van uitgaande dat bij tientallen miljoenen gebruikers en regelmatig onafhankelijke partijene die een vergrootglas op de source code leggen ga ik er vanuit dat de gebruikte methode toch wel redelijk veilig is.

squirrelmail is een andere situatie, die heeft geen eigen backend maar IMAP of POP3 en derhalve weet Squirrelmail niet hoe je anders moet inloggen

[stekkel]

Erkens schreef op zaterdag 13 januari 2007 @ 16:42:
[...]

encrypted of niet, het heeft geen nut


[...]

als ik die session hijack dan is dat wachtwoord nog steeds in die session, dus wat is het verschil?

Het encrypted wachtwoord waar je niks aan hebt als je niet de sleutel hebt om het te decrypten. De sleutel staat in een cookie op die op de pc van de client aanwezig is.

[...]

squirrelmail is een andere situatie, die heeft geen eigen backend maar IMAP of POP3 en derhalve weet Squirrelmail niet hoe je anders moet inloggen

Dat is helemaal waar ;-) (backend is overigens IMAP, geen POP3)
Maar door iedere pageload the authenticeren creeer je dus wel een stukje extra veiligheid. Vandaar dat ik de methode aanhaalde.

[Erkens]

stekkel schreef op zaterdag 13 januari 2007 @ 17:16:
Het encrypted wachtwoord waar je niks aan hebt als je niet de sleutel hebt om het te decrypten. De sleutel staat in een cookie op die op de pc van de client aanwezig is.

Als je de session kan hijacken dan is een cookie een fluitje van een cent, want je session id staat immers ook in een cookie

Dat is helemaal waar ;-) (backend is overigens IMAP, geen POP3)
Maar door iedere pageload the authenticeren creeer je dus wel een stukje extra veiligheid. Vandaar dat ik de methode aanhaalde.

juist minder veilig, omdat het password vaker door een stuk code gehaald moet worden, en het geval met Squirrelmail moet er zelfs (kan niet anders) het password verstuurd worden

[Janoz]

Stekkel, jouw oplossing is net zo veilig of onveilig als het plaatsen van een cookie met willekeurige random string ering. Laat dat nu net hetzelfde zijn als een SessionID. De enige reden dat Squirrel mail werkt met een dergelijke techniek is omdat zij het wachtwoord elk request weer nodig hebben. Een (md5) hash is niet genoeg. Het wachtwoord unencrypted in de session opslaan had ook gekund (deze is immers alleen op de server toegankelijk en niet benaderbaar vanaf de client), alleen kan dit problemen geven op een shared server omdat de sessie bestanden in een voor iedereen bereikbare plaats staan. Dat is neit een plek waar je wachtwoorden van mensen wil opslaan.

Je hele wachtwoord encryptie techniek is een vorm van schijnbare, maar nauwlijks iets toevoegende beveiliging.

[stekkel]

Janoz schreef op zaterdag 13 januari 2007 @ 18:00:
Stekkel, jouw oplossing is net zo veilig of onveilig als het plaatsen van een cookie met willekeurige random string ering. Laat dat nu net hetzelfde zijn als een SessionID. De enige reden dat Squirrel mail werkt met een dergelijke techniek is omdat zij het wachtwoord elk request weer nodig hebben. Een (md5) hash is niet genoeg. Het wachtwoord unencrypted in de session opslaan had ook gekund (deze is immers alleen op de server toegankelijk en niet benaderbaar vanaf de client), alleen kan dit problemen geven op een shared server omdat de sessie bestanden in een voor iedereen bereikbare plaats staan. Dat is neit een plek waar je wachtwoorden van mensen wil opslaan.

Je hele wachtwoord encryptie techniek is een vorm van schijnbare, maar nauwlijks iets toevoegende beveiliging.

Bij nader inzien denk ik dat jullie gelijk hebben .

Het is inderdaad waar dat wanneer een session_id via een cookie bemachtigd word dat net zo goed kan met die encryptie sleutel.

Maar goed, omdat in de praktijk dit soort cookie steel gedrag via XSS gebeurd is het in ieder geval aan te raden om je cookies met het HttpOnly attribuut te vergezellen. (via JS kan je dan niet meer bij de cookies)
Ik weet dat dit alleen maar werkt voor IE6 i.c.m. XP SP2 maar IE is het meest kwetsbaar voor XSS dus het helpt in ieder geval een beetje.

[Verwijderd]

"Voor zover ik weet is het redelijk ingewikkeld om een sessieID te stelen aangezien een sessie, serverside is in tegenstelling tot cookies." >> En hoe weet PHP dan welke Sessie jij hebt? Goed zo: d.m.v. een cookie...

Het systeem van je is naar mijn mening zeer veilig.
Ga echter niets meer in je session op lopen slaan dan een ID van de ingelogde persoon o.i.d. Ik zou zelf deze databasestructuur voorstellen:

CREATE TABLE sessions (
session_id int(11) UNSIGNED AUTO_INCREMENT,
session_userid int(11) UNSIGNED NOT NULL,
session_sessionhash varchar(32),
session_ip varchar(15),
session_expire int(15) UNSIGNED NOT NULL,
PRIMARY KEY (session_id)
)

Zoiets, weet niet of SQL 100% klopt, kan evt. session_sessionhash nog unique maken. Die session_id moet je dan in je session opslaan o.i.d.

[Erkens]

Verwijderd schreef op zaterdag 13 januari 2007 @ 19:03:
"Voor zover ik weet is het redelijk ingewikkeld om een sessieID te stelen aangezien een sessie, serverside is in tegenstelling tot cookies." >> En hoe weet PHP dan welke Sessie jij hebt? Goed zo: d.m.v. een cookie...

Het systeem van je is naar mijn mening zeer veilig.
Ga echter niets meer in je session op lopen slaan dan een ID van de ingelogde persoon o.i.d. Ik zou zelf deze databasestructuur voorstellen:

CREATE TABLE sessions (
session_id int(11) UNSIGNED AUTO_INCREMENT,
session_userid int(11) UNSIGNED NOT NULL,
session_sessionhash varchar(32),
session_ip varchar(15),
session_expire int(15) UNSIGNED NOT NULL,
PRIMARY KEY (session_id)
)

Zoiets, weet niet of SQL 100% klopt, kan evt. session_sessionhash nog unique maken. Die session_id moet je dan in je session opslaan o.i.d.

waarom die sessionhash niet als primary key gebruiken?

[Verwijderd]

Is ook een goed idee...
Had alles even on-the-fly (snel-snel) gedaan, dus eerlijk gezegd kwam ik daar (toen ik al weg was) ook achter.
In dat geval hoef je namelijk ook helemaal niets in de session te zetten.

[ Voor 21% gewijzigd door Verwijderd op 13-01-2007 23:17 ]

[Erkens]

Verwijderd schreef op zaterdag 13 januari 2007 @ 23:17:
In dat geval hoef je namelijk ook helemaal niets in de session te zetten.

waardoor je net zo goed alleen een cookie kan zetten, waarmee je applicatie "sneller" is doordat PHP niet de session file hoeft te locken aangezien die er niet is waar je overigens alleen "last" van hebt met 2 synchrone request van dezelfde client, bijvoorbeeld met "AJAX" toepassingen, of plaatjes die je aanbied via een PHP file ivm rechten etc

[Verwijderd]

als je het echt veilig wilt doen gebruike dan ook een HMAC hash met een random key.

ik probeer altijd het gebruik van cookies te vermijden. 1 cookie met alleen de session_id en meer niet de rest gaat of in de session of in de database. ook gebruik ik altijd een inactivity van bijvoorbeeld 5 minuten oftewel als de sessie 5 minuten niet meer wordt gebruikt is deze ongeldig en wordt er een nieuwe sessie begonnen.

en als je het echt secure wilt maken gebruik je een HMAC javascript dat het wachtwoord met een random key hashed en de hash verstuurt inplaats van het wachtwoord. hier een klein schema:

1. server begint, kijkt of er een active session_id is meegestuurd. zoniet begin een sessie
2. server genereert een random key van bijvoorbeeld 128 tekens, en stuurt deze met het login form mee.
3. gebruiker vult zijn username en wachtwoord in en klikt op 'login'
4. javascript hashed het wachtwoord met de randomkey die in het form was meeverstuurt.
5. browser stuurt de hash en username naar de server.
6. server vergelijkt de hash met de eigen hash en alleen als de hash klopt volgt er een login.

dit is een bewezen en veilig challenge response systeem waardoor ook afluisteren zinloos wordt. omdat de key bij elke login poging verandert verandert dus ook de hash en kan een hash dus alleen gebruikt worden als de key klopt, welke server side is gegenereerd.

hier de links:
http://en.wikipedia.org/wiki/Hmac
http://pajhome.org.uk/crypt/md5

en bijna verplichte leeskost:
http://nl3.php.net/manual/en/ref.session.php
http://nl3.php.net/manual/en/features.cookies.php

[Erkens]

Verwijderd schreef op zaterdag 13 januari 2007 @ 23:47:
ik probeer altijd het gebruik van cookies te vermijden. 1 cookie met alleen de session_id en meer niet de rest gaat of in de session of in de database. ook gebruik ik altijd een inactivity van bijvoorbeeld 5 minuten oftewel als de sessie 5 minuten niet meer wordt gebruikt is deze ongeldig en wordt er een nieuwe sessie begonnen.

Met andere woorden als iemand bezig is met bijvoorbeeld het typen van een reactie dan moet deze (als hij er langer dan 5 min over doet) opnieuw inloggen? Lijkt me juist minder secure omdat dan _nogmaals_ het wachtwoord over de lijn moet

[Verwijderd]

daarom gebruik je ook HMAC hashing zodat dus niet het wachtwoord over de lijn gaat maar juist de hash van het wachtwoord. sterker nog, de enige keer dat het wachtwoord over de lijn gaat is bij het inschrijven. elke keer daarna is het de hash en niet het wachtwoord dat verstuurd wordt. zeer veilig.

door de key met elke login te veranderen veranderd dus ook de hash en kan een hash dus nooit 2 keer worden gebruikt. daarom is het afvangen van een wachtwoord ook niet zinvol omdat de server dus het wachtwoord hashed met de random key en de browser dat ook doet en dan dus de hashes worden vergeleken en niet het wachtwoord.

in elke nieuwe login poging is de key anders, dus als je nogmaals de zelfde hash zou sturen zou deze niet kloppen met wat de server heeft gehashed en de login wordt dan dus geweigerd.

dit is eigenlijk de meest veilige manier, afgezien van de verbinding zelf encrypten via een SSH tunnel ofzo. HMAC hashing is een RFC standaard en de javascripts die ik in mijn eerste post linkte zijn cross-browser en cross-platform compatible.

[ Voor 11% gewijzigd door Verwijderd op 14-01-2007 01:13 ]

[Erkens]

ik bedoelde eerder dat het minder veilig is omdat de gebruiker nogmaals moet inloggen wat gewoon extreem vervelend is en daardoor minder secure.

[ Voor 10% gewijzigd door Erkens op 14-01-2007 11:15 ]

[Verwijderd]

tja dan moet je ook gewoon de juiste balans vinden wanneer een sessie als inactief wordt gezien. dus afhankelijk van de applicatie kun je de regels heel streng zetten als in 1 minute of juist heel soepel als in 1 uur of meer. zelf vind ik 5 minuten een goede balans maar voor een forum als GOT zou 30 minute mischien beter zijn bijvoorbeeld.

feit blijft dat HMAC hashing een kleine moeite is en veel veiligheid biedt, eigenlijk hoef je allen een 'onsubmit' toetevoegen aan je login form en klaar. ook omdat het een RFC standaard zit je niet met de vraag hoeveilig is dit script of hoe veilig is dat script omdat dus de implementatie vast ligt in de standaard is de ook de werking ervan verzekerd.

beveiliging is altijd maatwerk, je zoekt altijd de juiste balans tussen veiligheid en gebruiksgemak en dat is voor elke website weer anders. kwestie van weten en wegen

[Erkens]

Verwijderd schreef op maandag 15 januari 2007 @ 16:44:
feit blijft dat HMAC hashing een kleine moeite is en veel veiligheid biedt, eigenlijk hoef je allen een 'onsubmit' toetevoegen aan je login form en klaar. ook omdat het een RFC standaard zit je niet met de vraag hoeveilig is dit script of hoe veilig is dat script omdat dus de implementatie vast ligt in de standaard is de ook de werking ervan verzekerd.

Gevaarlijke uitspraak dat je niet zit met de vraag hoe veilig het is

Overigens zal je altijd nog een fallback naar de "oude" manier moeten hebben voor non-js browsers

[Verwijderd]

Erkens schreef op maandag 15 januari 2007 @ 18:22:
[...]

Gevaarlijke uitspraak dat je niet zit met de vraag hoe veilig het is

Overigens zal je altijd nog een fallback naar de "oude" manier moeten hebben voor non-js browsers

ja, kwaliteit verschillen tussen de implementatie zijn er altijd, maar ik doelde meer op de architecture van de veiligheid. er zijn zat scripts te vinden die beweren veilig te zijn maar gewoon slecht doordacht en daardoor dus onveilig zijn. niet omdat er een bug in de implementatie zit maar omdat de manier waarop ze een website beveiligen gewoon compleet fout hebben. plus het feit dat je altijd te maken hebt met 2 implentaties van de HMAC hash algorithmes, namelijk de client-side(javascript) en de server-side(php, asp, etc). dus een bug moet dan in beide implemtaties onveilig zijn anders werkt het gewoon niet en heb je dus geen login.

HMAC is gewoon goed doordacht en een bewezen veilige architecture. het wordt volgensmij zelfs gebruikt bij SSH voor de initieele hand-shake.

kan zo even geen browser bedenken die helemaal geen javascript ondersteunt, ja, lynx, maar da's een text-based browser, daar ga ik niet dagelijks mee zitten browsen, jij wel.

zo ondersteunt vrijwel elke browser javascript en ja, er zijn verschillen in de implementatie van javascript maar daarom poste ik ook een link naar een script dat juist geen implementaite specefieke functies gebruikte en dus cross-browser en cross-platform is. hashing is eigenlijk ook alleen maar een wiskundige berekening op een stuk text en HMAC hashing is een manier om een random key in een hash te verwerken. voorzover ik weet kun je op 99,9999 procent van de browsers wel hashing implemtatie schrijven in javascript.

javascript problemen zitten vaak in het DOM-model en de aanwezigheid of namen van functies welke voor HMAC hashing geen enkele rol spelen.

[Erkens]

Verwijderd schreef op maandag 15 januari 2007 @ 21:00:
kan zo even geen browser bedenken die helemaal geen javascript ondersteunt, ja, lynx, maar da's een text-based browser, daar ga ik niet dagelijks mee zitten browsen, jij wel.

jij bent duidelijk iemand die niet ontwikkeld voor toegankelijkheid

[LinuX-TUX]

Misschien andere invalshoek (of je hebt hem al LANG gedekt maar bent het vergeten te vermelden, of ik ben blind)

Als er nou iemand wireless erop inlogt? En ik zit net met mijn leuke ethereal te spelen (of kismet, whatever, EEN packetsniffer) en zie al die info voorbij komen, dan heb ik al zo'n beetje ALLE informatie die ik nodig zou moeten hebben om erop in te haken.

Sterker nog, hoef die sessie niet eens te hijacken om zelf normaal nog een keer in te loggen

Dus ... HTTPS gebruiken indien mogelijk? (SSL, maar iets met een beetje encryptie)

[Verwijderd]

LinuX-TUX schreef op maandag 15 januari 2007 @ 21:17:
Misschien andere invalshoek (of je hebt hem al LANG gedekt maar bent het vergeten te vermelden, of ik ben blind)

Als er nou iemand wireless erop inlogt? En ik zit net met mijn leuke ethereal te spelen (of kismet, whatever, EEN packetsniffer) en zie al die info voorbij komen, dan heb ik al zo'n beetje ALLE informatie die ik nodig zou moeten hebben om erop in te haken.

Sterker nog, hoef die sessie niet eens te hijacken om zelf normaal nog een keer in te loggen

Dus ... HTTPS gebruiken indien mogelijk? (SSL, maar iets met een beetje encryptie)

ja enige informaite die jij dan hebt met je packetsniffer krijgt zijn een key voor deze inlog sessie en hash welke het resultaat is van wachtwoord+key, dus omdat de key veranderd met elke inlog sessie verander ook de hash, gebruik je de hash nogmaals dan klopt deze dus niet omdat de key anders is. verders moet je natuurlijk de sessie locken aan de eigenschappen van de gebruiker. anyway het wachtwoord waarmee jij zelf een sessie zou kunnen beginnen komt dus nooit voorbij, enkel de hash.

interessante methode zou kunnen zijn om bijvoorbeeld met elke request de eena laaste request mee te sturen. dus als een gebruiker een http request instuurt voor /gallerie12 en daarvoor /gallerie10 heeft bezocht dan kan de server zien of er iemand meelift op de sessie omdat als jij dan met je laptop daarzo voor de deur op de wifi van de gebruiker een request stuurt voor bijvoorbeeld /gallerie13 met als daarvoor bezochte pagina /gallerie12, en daarna stuurt de gebruiker een request voor /gallerie14 met als daarvoorbezochte pagina ook /gallerie12 wat dan eigenlijk /gallerie13 zou moeten zijn dan ben je meteen gesnapt en zou de server de sessie kunnen/moeten verbreken.

@Erkens
als je met toegangkelijkheid doelt op mensen met een lichamelijk gebrek, is dit ook geen probleem omdat dit javascript pas zijn werk doet, wanneer er dus op de 'submit' knop wordt gedrukt en dat heeft dus weinig met de invoer of het gebruik van de website te maken, sterker nog, als je niet in de source-code van de website kijkt weet je niet eens dat je wachtwoord vesleuteld wordt verstuurt, verder ben ik het met je eens dat javascript zich niet mag bemoeien met de invoer van velden en dat websites zich gewoon 100% aan de standaarden moeten houden, dat zou het leven van de wat minder bedeelde medemens een heel stuk makkelijker maken, want dan kan hulp-software daar ook vanuit gaan.

lynx zou ik nou juist niet toegankelijk willen noemen, en dan spreek ik uit ervaring, want ik heb zelf 2 vrienden die hun eigen armen al niet meer kunnen optillen en met een lasertje aan het hoofd en een groot bord naast de monitor de computer bedienen. dan zijn auto-completion en een muis-pointer echt een zege.

[Verwijderd]

"Als er nou iemand wireless erop inlogt?"
Die mensen hebben waarschijnlijk ook nog nooit WPA(-TKIP) gehoord denk ik (of zelfs van het simpele WEP). Ik neem namelijk niet aan dat jij je broer loopt te hacken.

En daarnaast: als jij alle data ziet af te vangen met dat ethereal (is toch OpenSource?) dan heeft SSL ook geen zin meer, want als je alles hebt kun je daarmee de key ook automatisch bepalen en decoderen....

[matthijsln]

Verwijderd schreef op dinsdag 16 januari 2007 @ 06:38:
En daarnaast: als jij alle data ziet af te vangen met dat ethereal (is toch OpenSource?) dan heeft SSL ook geen zin meer, want als je alles hebt kun je daarmee de key ook automatisch bepalen en decoderen....

En hoe wou dit je dit doen? Jij hebt de key exchange algoritmes van SSL gekraakt lees ik?

[Scarfish]

Verwijderd schreef op dinsdag 16 januari 2007 @ 06:38:
En daarnaast: als jij alle data ziet af te vangen met dat ethereal (is toch OpenSource?) dan heeft SSL ook geen zin meer, want als je alles hebt kun je daarmee de key ook automatisch bepalen en decoderen....

Verklaar je nader. Zo ver ik weet werkt SSL met PKI encryption. Wat jij beweert is dus dat je aan de hand van gesnifte pakketten de private keys kan achterhalen?

Misschien heb ik het fout hoor maar verwar je de zwakte in WEP (waarmee dit dus wel mogelijk is) met SSL.

Of bedoel je de Man-in-the-Middle attack?

[ Voor 3% gewijzigd door Scarfish op 16-01-2007 12:01 ]

[xces]

er is een functie die een sessieid kan "hergenereren". Deze heet volgens mij session_regenerate_id(). Dit zou ik doen na een succesvolle inlog/uitlog.

[LinuX-TUX]

Verwijderd schreef op maandag 15 januari 2007 @ 21:50:
[...]


ja enige informaite die jij dan hebt met je packetsniffer krijgt zijn een key voor deze inlog sessie en hash welke het resultaat is van wachtwoord+key, dus omdat de key veranderd met elke inlog sessie verander ook de hash, gebruik je de hash nogmaals dan klopt deze dus niet omdat de key anders is. verders moet je natuurlijk de sessie locken aan de eigenschappen van de gebruiker. anyway het wachtwoord waarmee jij zelf een sessie zou kunnen beginnen komt dus nooit voorbij, enkel de hash.

interessante methode zou kunnen zijn om bijvoorbeeld met elke request de eena laaste request mee te sturen. dus als een gebruiker een http request instuurt voor /gallerie12 en daarvoor /gallerie10 heeft bezocht dan kan de server zien of er iemand meelift op de sessie omdat als jij dan met je laptop daarzo voor de deur op de wifi van de gebruiker een request stuurt voor bijvoorbeeld /gallerie13 met als daarvoor bezochte pagina /gallerie12, en daarna stuurt de gebruiker een request voor /gallerie14 met als daarvoorbezochte pagina ook /gallerie12 wat dan eigenlijk /gallerie13 zou moeten zijn dan ben je meteen gesnapt en zou de server de sessie kunnen/moeten verbreken.
....

Sorry hoor, maar ... ik mis wat, waarom heb ik die sessie dingen enzo nodig? Ik zie toch gewoon een plain text username en plain text wachtwoord voorbij flitsen? Ik mis hier geloof ik iets (ach ja, devven doe ik al 2 jaar niet meer, maar ik wil toch wel echt weten wat ik nu technisch heb gemist)

Waar word dan die hash gecreeerd als ik op "login" klik?

Verwijderd schreef op dinsdag 16 januari 2007 @ 06:38:
"Als er nou iemand wireless erop inlogt?"
Die mensen hebben waarschijnlijk ook nog nooit WPA(-TKIP) gehoord denk ik (of zelfs van het simpele WEP). Ik neem namelijk niet aan dat jij je broer loopt te hacken.

En daarnaast: als jij alle data ziet af te vangen met dat ethereal (is toch OpenSource?) dan heeft SSL ook geen zin meer, want als je alles hebt kun je daarmee de key ook automatisch bepalen en decoderen....

Jajajaja, maar even voor het gemak (en dan nog "miereneukmodes", genoeg hotspots waar ze niet eens encryptie gebruiken. Bij mij op school BV, moet je een sessie gaan starten voor je verder gerouteerd word)

[Verwijderd]

LinuX-TUX schreef op dinsdag 16 januari 2007 @ 16:38:
[...]

Sorry hoor, maar ... ik mis wat, waarom heb ik die sessie dingen enzo nodig? Ik zie toch gewoon een plain text username en plain text wachtwoord voorbij flitsen? Ik mis hier geloof ik iets (ach ja, devven doe ik al 2 jaar niet meer, maar ik wil toch wel echt weten wat ik nu technisch heb gemist)

Waar word dan die hash gecreeerd als ik op "login" klik?

[...]
Jajajaja, maar even voor het gemak (en dan nog "miereneukmodes", genoeg hotspots waar ze niet eens encryptie gebruiken. Bij mij op school BV, moet je een sessie gaan starten voor je verder gerouteerd word)

ik leg het nog een keer uit :

server >> ontvangt een HTTP request van de gebruiker
server >> genereert een sessie_id en een willekeurige KEY. dit is gewoon stukje willekeurige text.
server >> server creert de HTML pagina met daarin de KEY als waarde van het login formulier.
server >> stuurt dan de HTML pagina als platte text naar de browser van de gebruiker.

oke, dus de HTML pagina met daarin de KEY en een aantal javascript functies worden dus als platte text naar de gebruiker gestuurd. volg je het nog

gebruiker >> de gebruiker vult zijn 'username' en wachtwoord in op het HTML formulier.
gebruiker >> de velden op het HTML formulier bevatten nu dus het wachtwoord en de 'username'.
gebruiker >> klikt op 'login', dit is gewoon een HTML button waarmee dus het formulier wordt verzonden.
gebruiker >> op de '<form' tag van het HTML formulier zit de 'onsubmit' tag toegevoegd welke dus wordt uitgevoerd zodra het formulier wordt verzonden.
gebruiker >> een javascript functie pakt dan de waarde van het wachtwoord en de KEY uit het html formulier en creert een HMAC hash, en stopt die weer als waarde terug in het veld waar het wachtwoord eerst stond.
gebruiker >> het formulier wordt dan verzonden met in het wachtwoord veld dus het door javascript gehashde wachtwoord.

dus voor het formulier wordt verstuurd word door javascript het wachtwoord gehashed en weer opnieuw ingevuld. deze wordt dan dus weer naar de server gestuurt zoals elke ander ingevuld formulier.

server >> ontvangt het HTML formulier, en kijkt in de sessie, welke server-sided is opgeslage. de client heeft allen de sessie_id als cookie meegekregen en kan dus alleen zeggen welke sessie van hem is, maar niet wat er in die sessie staat. dat blijft server-sided.
server >> de server creert dan zijn eigen HMAC hash van het wachtwoord wat op de server is opgeslage, met de key uit de sessie.
server >> als die eigen HMAC hash klopt met dat wat de gebruiker heeft opgestuurd wordt een login verleend. zoniet dan beging het hele spelletje weer van vooraf aan met een nieuwe key weer opnieuw.

dus het enige wat tussen de gebruiker en de server wordt verstuurd:
1) HTTP request
2) login pagina met daarin de key als waarde van het HTML formulier
3) het formulier met daarin het door javascript ge-hashde wachtwoord.
4) de 'welkom' pagina als de login klopt en de 'sorry probeer het nogmaals' als het niet klopt.

en omdat de key telkens ook aan de server kant veranderd, kun je een ge-hashed wachtwoord niet meer opnieuw gebruiken .

wat je veels te veel nog ziet gebeuren is dat het wachtwoord als plaintext naar de server wordt gestuurd zodat het daar dan kan worden gehashed wat uiteraard het stelen van wachtwoorden of het misbruiken van logins natuurlijk wel erg makkelijk maakt .

ook moet je niet vergeten dat als ik een stukje spyware op jouw computer al je in en uitgaand verkeer laat loggen dat dat ook een man-in-de-middle attack is, al hoewel het dan ook wel loont om meteen een keylogger te implementeeren . toch doet veel spyware spul dit niet omdat ip-packetjes op poort 80 loggen gewoon een stuk makkelijker is.

ik hoop dat ik het principe van HMAC hashing nu duidelijk genoeg heb uitgelekt, daarnaast is er ook nog veel over te vinden op internet en met google. leesvoer dus.