[php] User authenticatie veilig? "Hacker-proof"?

[Explore]

Een tijd geleden (ruim een jaar) heb ik topic ge-opend met de vraag of een bepaalde methode van user authenticatie veilig was. Inmiddels ( ) ben ik wat verder en heb ik ook wat online staan wat getest zou mogen worden.

De core van de validatie werkt als volgt:

Op elke pagina, welke alleen toegankelijk is na inlog, wordt dit stukje code gedraait:

PHP:

// Instantiate user class
if (!isset($_SESSION['user']) || !$_SESSION['user'])
    $_SESSION['user'] = new User(TBL_USERS);

// If this user does not validate, throw login form
if (!$_SESSION['user']->isValid()) {
    if (!$_SESSION['user']->validate()) {
        $_SESSION['user']->login();
        exit;
    }
}

De User-class die hier wordt aangeroepen bevat onder andere de volgende methods:

PHP:

// Public: validates a user
function validate() {

    global $db, $log;

    // Return false if userpass is not posted from the html-form
    if (!isset($_POST['userpass']) || !$_POST['userpass']) return false;

    // Get user and pass from userpass
    list($userid, $formPass) = explode(':', $_POST['userpass']);

    // Get password of requested user from DB
    if (!$db->exec("select password from ".$this->usersTable.
        " where strcmp(userid, '".addslashes($userid)."')=0")) return false;

    // DB-query should return one record
    if ($db->numRows() != 1) return false;

    // Retrieve password from resultset and encrypt like formPass
    $dbPass = md5($db->fetchField('password').$this->rndval);

    // dbPass and formPass should be the same now
    if ($dbPass != $formPass) return false;

    // All tests passed...
    $this->valid = true;
    $this->userId = addslashes($userid);
    $this->loadDetails();
    $this->updateLastLogin();
    $db->free();
    return true;

}

// Public: prepares and shows login form
function login() {

    // Prepare random number and save in this object
    $this->rndval = rand(1111, 9999);

    // Prepare login template and show
    // ...

}

Op Experts-Exchange ben ik ook al een topic begonnen hierover met de vraag hoe veilig bovenstaande code is.

Online, op mijn site, staat een login-formpje, waar - wat mij betreft - mensen mogen proberen de authenticatie te passeren, breken of buigen. Zie hier:

http://webtweakers.com/login/

De pagina op dat adres is puur en alleen een test-environment. Als iemand in staat is de authenticatie te omzeilen zien ze niet meer dan een berichtje en ik krijg een mail.

Er zijn een aantal dingen waarmee de beveiliging uit te breiden is, zoals te lezen is in een mooie FAQ over website beveiliging opgezet door drm en ACM (zie het hoofdstukje over Intruder detection).

De technieken die daar genoemd staan, lijken me een waardevolle toevoeging. Alleen staan of vallen ze met het achterhalen van het IP adres van de bezoeker:

PHP:

function getIp() {
    if (getenv('HTTP_CLIENT_IP'))
        return getenv('HTTP_CLIENT_IP');
    elseif (getenv('HTTP_X_FORWARDED_FOR'))
        return getenv('HTTP_X_FORWARDED_FOR');
    else return getenv('REMOTE_ADDR');
}

Bovenstaande functie werkt braaf, maar in 't geval dat een bezoeker achter een soort van AOL-proxy zit, dan varieert het IP adres bij elke aanroep en zullen de genoemde methodes falen.

Mijn vragen:

1. is iemand in staat om mijn beveiliging te omzeilen, en zo ja: hoe?

2. is er een methode om nog extra beveiliging toe te voegen met voorwaarde dat deze wel algemeen goed werkt (dus niet voor alleen statische adressen ofzo)...?

3. ziet iemand nog een lek of iets waar ik niet aan gedacht heb?

Wat mij betreft mag je dus proberen m'n login lek te prikken, maar gebruik aub geen drastische methodes zoals (D)DoS attacks en dergelijke! Het gaat me puur om de veiligheid van m'n code: over de server heb ik geen invloed.

Ik zal in iedergeval een link naar dit topic op die pagina plaatsen, zodat ik bewezen heb dat het om mijn eigen site gaat en niet om het systeem van iemand anders.

Lees anders ook het topic op Experts-Exchange.

PS: van de P&W crew heb ik toestemming om dit topic te plaatsen, waarvoor mijn dank.

[ Voor 6% gewijzigd door Explore op 09-08-2003 16:03 ]

[TheDuke]

Het enige wat me opviel als ik er zo ff vlot over heen keek was dat je het wachtwoord unencrypted in de database opslaat... Is er enige reden om dat te doen? Wil jij de wacthwoorden van de gebruikers zien of zo?

Als iemand je database binnen komt ben je extreem gevoelig op deze manier natuurlijk...
Ik zou gewoon de md5 hashes van de passwords in je database zetten...

[Opi]

TheDuke schreef op 09 augustus 2003 @ 19:34:
Het enige wat me opviel als ik er zo ff vlot over heen keek was dat je het wachtwoord unencrypted in de database opslaat... Is er enige reden om dat te doen? Wil jij de wacthwoorden van de gebruikers zien of zo?

Als iemand je database binnen komt ben je extreem gevoelig op deze manier natuurlijk...
Ik zou gewoon de md5 hashes van de passwords in je database zetten...

Dit lijkt me ook een stuk sneller te controleren, aangezien ik ervan uit ga dat je de passwords ook op een dergelijke manier verstuurt.

[Verwijderd]

offtopic:
Gisteren was dit topic er ook al, was toen ineens weg, waar was die gebleven?

Over die md5 hashes, die worden clientside gegenereerd, zie de HTML van het loginscherm. Op deze manier hoef je niet je wachtwoord plaintext over het lijntje te versturen.

[CyberSnooP]

Verwijderd schreef op 09 augustus 2003 @ 20:00:
Over die md5 hashes, die worden clientside gegenereerd, zie de HTML van het loginscherm. Op deze manier hoef je niet je wachtwoord plaintext over het lijntje te versturen.

Dat is wel een heel vage vorm van beveiliging. In plaats van plain-text wachtwoord smijt je nu plain-text de md5 over het onbeveiligde internetlijntje.
Echter als die wordt afgevangen (en die kans lijkt me even groot dan bij een plain-text wachtwoord) is het even krachtig als het wachtwoord. Namelijk: Exact die md5-hash (in combinatie met een loginnaam) doet de server de gebruiker identificeren als datgeen waar ie zich voor uitgeeft.

Een wat betere beveiliging van de client-server verbinding (buiten SSL oid) zou zijn:
• Genereer een random code server-side (ik noem hem even pass-tranfser-code).
• Sla de pass-tranfser-code server-side tijdelijk op (in een session bijvoorbeeld)
• Stuur de pass-tranfser-code mee met het login-form
Client-side verschijnt dan het login-form en zodra dat verstuurd wordt:
• Concateneer de pass-tranfser-code met het ingevulde wachtwoord.
• md5 dit geheel
Server-side is nu een string aangekomen die alleen geldig als deze pass-tranfser-code is gekozen.
• Vergelijk de binnengekomen string met de md5 van het lokaal bekende wachtwoord (uit de database) geconcateneerd met de pass-tranfser-code uit de session.

Het blijft een beetje behelpen, maar het is volgens mij een betere optie dan het uitsluitend one-way-hashen van de verstuurde gegevens. Je maakt een replay-attack onmogelijk.

[Explore]

offtopic:
Gisteren was dit topic er ook voor ongeveer 1 minuut en werd toen getrashed door een moderator - ik heb inmiddels braaf toestemming gevraagd

curry684: met daarbij als kanttekening van de desbetreffende moderator dat het toen een pure hack-request was zonder de bijbehorende code, en op die manier is en blijft het trashware

De passwords staan als md5 hash in de database. Het password wat ingetypt wordt in de browser wordt dus ook ge-md5'd, daar wordt de random code aangeplakt en dan wordt het geheel nog een keer ge-md5'd, zodat de random code niet over het net wordt gestuurd in plain vorm.

Hetzelfde zie je dus terug op regel 20 van de validate-method die ik hierboven gepost heb. Lijkt omslachtig, maar is 't niet.

De key hier is dus dat er een afspraak tussen de server en de client is in de vorm van een random waarde. Deze moet matchen, in combinatie met het password en userId om toegang te krijgen. Het geheel wordt encrypted zodat packet-sniffers niet kunnen achterhalen wat men intypt of wat de random-code is.

[ Voor 13% gewijzigd door curry684 op 09-08-2003 22:38 ]

[Explore]

Juist, wat CyberSnoop uitlegt is dus precies wat ik gedaan heb...

[ Voor 5% gewijzigd door Explore op 09-08-2003 21:39 ]

[curry684]

CyberSnoop: dat heet het 'challenge-response' systeem van authenticatie, en de correcte naam voor pass-transfer-code is dan ook 'challenge'

Tis overigens redelijk waterdicht inderdaad indien goed toegepast (MSN gebruikt het ook).

[Explore]

En denk je dat het 'challenge-response' systeem in dit geval goed is toegepast, curry?

[curry684]

* curry684 heeft de ballen verstand van PHP, HTML, Javascript etc. dus onthoudt zich van inhoudelijk commentaar

[Bosmonster]

curry684 schreef op 10 August 2003 @ 15:46:
* curry684 heeft de ballen verstand van PHP, HTML, Javascript etc. dus onthoudt zich van inhoudelijk commentaar

Tss.. en dat is lightmod P&W

curry684: erg he

[ Voor 13% gewijzigd door curry684 op 10-08-2003 15:56 ]

[Explore]

offtopic:
Hmmm... ik zeg niks.
Mooi he, die P800, Curry?

Maaruh, hier ook geen suggesties meer?
Ik kan niet anders concluderen dat m'n handeltje safe is, dan...

[justmental]

Ik heb er vluchtig naar gekeken en denk dat het een sluitende implementatie is.
Dat gedoe met die cgi variablelen tbv. ip adressen moet je wel mee oppassen, de variant die je hier post is vatbaar voor allerlei manipulatie.
Wil je hier op een safe manier wat mee doen zul je iig. altijd remote_addr op moeten slaan/uit moeten lezen, dit is namelijk de enige variabele die te vertrouwen is.

[bigtree]

Wel grappig, ik heb twee jaar geleden exact dezelfde methode geïmplementeerd. Heb je code en beschrijving nagelopen en kan niet anders concluderen dat het goed in elkaar zit.

Wees wel beducht op de volgende situatie; een client zit op een LAN achter een NAT-router met een hub (geen switch), oftewel iedereen op het netwerk zou het IP-verkeer van zijn collega's kunnen sniffen. In deze situatie is een sessie met jouw systeem wel degelijk over te nemen, aangezien iedereen op het LAN voor de buitenwereld hetzelfde IP-adres heeft. Hier kun je niets tegen doen, aangezien je geen sluitende manier hebt om een client-pc te identificeren.

De enige oplossing zou zijn https. (Waar die challenge-respons natuurlijk al standaard zit ingebakken. )

[Explore]

Als het even kan zou ik dit geheel wel onder SSL laten draaien, ja.
Ik denk dat de enige manier om het spoofen van IP's tegen te gaan is het gebruiken van een Cookie. Op Experts-Exchange deed iemand een goede suggestie hierover.
Maar 't is een mooi systeem, dat challange-response mechanism - ik wist niet eens dat het zo heet.

[curry684]

Explore schreef op 13 August 2003 @ 22:14:
Maar 't is een mooi systeem, dat challange-response mechanism - ik wist niet eens dat het zo heet.

Industry-standard voor remote login security omdat er nooit een password over de lijn hoeft en het password nergens letterlijk opgeslagen hoeft te worden

_{Ik mag dan geen PHP kennen, ik ken m'n programmeerconcepten wel (lelijke Bosmonsterfiguur )}

[Roa]

Ik heb een vraagje hé, want ik snap het niet helemaal namelijk. Er word een random code gegenereerd, die word opgeslagen op de server, en meegezonden naar het formulier. Dan word er een hash gemaakt van password + randomcode die ook nog eens md5 is. Op je server creër je ook de hash password + randomcode, maar dan het password uit de database.

Allemaal leuk en aardig, maar als je die random code genereerd, moet die toch net zo goed over die lijn verzonden worden, en kan die dus net zo goed opgevangen worden door iemand.
En hoe moet je het password en die code samenvoegen + coderen, ik doe dat in php, maar dan word het dus eerst verzonden...

[Annie]

Roa schreef op 14 August 2003 @ 00:12:
Allemaal leuk en aardig, maar als je die random code genereerd, moet die toch net zo goed over die lijn verzonden worden, en kan die dus net zo goed opgevangen worden door iemand.

Alleen kan die persoon daar dan vrij weinig mee (tenzij ook nog eens de sessie wordt overgenomen).

Roa schreef op 14 August 2003 @ 00:12:
En hoe moet je het password en die code samenvoegen + coderen, ik doe dat in php, maar dan word het dus eerst verzonden...

In javascript is het ook mogelijk om een md5 hash te maken (zoek even op internet of kijk in de code van de TS).

[curry684]

Het hele concept Challenge-Response nog eens uitgebreid belicht dan maar: user heeft password Piet en username Karel:
• Client zegt tegen server: hoi Karel wil inloggen.
• Server zegt tegen client: da's mooi, je challenge is 14-08-2003-00:51:14:249
• Client trekt MD5 van bijv. "C:14-08-2003-00:51:14:249 U:Piet" en stuurt die over
• Server trekt serverside diezelfde hash (hij heeft challenge en PW tenslotte).
• Indien gelijk admitted.

Het grote punt: pw gaat nooit reversable over de lijn, en *wat* er over de lijn gaat kan rustig afgetapt worden want er komt als het goed is nooit 2 keer dezelfde challenge langs (vandaar dat ik hier een timestamp gebruikte, maar een GUID of zo is ook goed). Iedere volgende keer gaan er dus andere hashes over de lijn, dus wie er ook iets aftapt het zal je nooit toestaan in te loggen.

Enige zwakke punten:
• Ooit zal een PW bij de server moeten komen, en als je die aftapt ben je de sjaak.
• Het PW staat letterlijk in de DB dus DB-hacks zijn gevaarlijk.

Echter, ook deze gevaren zijn af te vangen, let op registratieprocedure:
• User meldt zich bij server om Karel te reggen, met een hash van username + password erbij ("U:Karel P:Piet" bijv.)
• Server slaat die hash op als password en heeft dus PW nooit gezien (!!!)
• Bij inloggen trekt client diezelfde hash om het password te reconstrueren en continueert als hierboven.

Na deze securitytoevoeging houd je een probleem over: ook die hash kan afgetapt worden en dan vervolgens gebruikt worden om in te loggen. Helaas is dit naar mijn weten niet af te vangen buiten de gangbare methodes van passwords serverside genereren en via mail/post op te sturen, en zelfs dan is hacken mogelijk. Je moet dan wel in de gaten houden dat het enorm onwaarschijnlijk is dat iemand die link kan leggen.

Bij password veranderen kun je wel combinatiehashes trekken op basis van vorige password waardoor er geen lekbare data over de lijn gaat.

[Roa]

Zeer interessant allemaal, ik ben momenteel bezig met een inlog systeem, en ik heb hier wel wat aan

Alleen zit ik een beetje met een vraag/dillema:

Ik had al eens eerder een inlog systeem, deze werkte met cookies. Als je inlogde werden er 2 cookies gezet en die werden overal waar nodig vergeleken met de informatie in de database, en bepaalde zo of je ingelogd was of niet.

Voor mijn nieuwe systeem ben ik echter compleet afgestapt van dat idee, en ben ik met sessions gaan werken. Ik verzamel wat informatie van de user, gooi die in de database met een session_id (een hash van 10 random tekens + de user_id en dat dan md5). Die session_id word in een session gestopt. Zo kan ik op iedere pagina gemakkelijk bij de informatie komen. Ook vergelijk ik standaard het ip adres op het session_ip adres. Als ze niet overeenkomen dan wis ik de session, gooi ik een error in de database, en stuur ik mijzelf een mailtje over een mogelijke hacking attempt (gekaapte sessie??).

Maar nu las ik ergens iets over proxy's? Die veranderen toch niet zomaar van adres? Het is namelijk niet erg als meerdere users hetzelfde adres hebben, er word immers alleen gekeken of het huidige adres overeenkomt met het adres tijdens inloggen, niet of het een uniek adres is...

[Explore]

Altijd fijn dat ik van dienst kan zijn.

In m'n eerste post hier staat een link naar Experts-Exchange waarin het proxy verhaal staat uitgelegd (of kijk anders in de PHP area naar een soortgelijk topic wat ik daar gestart ben). Overigens wordt me daar aangeraden het Challange-Response Authentication Machanism (CRAM) te combineren met cookies tbv. session hacking. Dit dus ivm. het feit dat je IP's niet kan vertrouwen. Als het desbetreffende cookie niet meer bestaat wipe je de session en wordt de persoon gelijk uitgelogd.

Of dat allemaal even goed werkt, weet ik niet zo zeker, maar 't is inmiddels in iedergeval erg moeilijk om het zaakje te hacken. M'n implementatie van CRAM staat inmiddels al een tijdje online en er is nog niemand in geslaagd om het te kraken.

Dus op zich ben ik zo ook wel content. Wellicht implementeer ik de anti session-hack er nog overheen. Dat is zo'n beetje het enige aspect wat niet te checken valt in zo'n test-environment.

[Olaf van der Spek]

curry684 schreef op 14 augustus 2003 @ 01:04:
Enige zwakke punten:
• Ooit zal een PW bij de server moeten komen, en als je die aftapt ben je de sjaak.
• Het PW staat letterlijk in de DB dus DB-hacks zijn gevaarlijk.

Echter, ook deze gevaren zijn af te vangen, let op registratieprocedure:
• User meldt zich bij server om Karel te reggen, met een hash van username + password erbij ("U:Karel P:Piet" bijv.)
• Server slaat die hash op als password en heeft dus PW nooit gezien (!!!)
• Bij inloggen trekt client diezelfde hash om het password te reconstrueren en continueert als hierboven.

Lost dat ook een DB-hack op?
Als een user de hash uit de DB steelt kan hij daar toch gewoon cd challenge-response mee uitvoeren?

[Explore]

OlafvdSpek schreef op 14 August 2003 @ 19:58:
Als een user de hash uit de DB steelt kan hij daar toch gewoon cd challenge-response mee uitvoeren?

Nee, want hij heeft de challange code nog niet...

[Olaf van der Spek]

Explore schreef op 14 August 2003 @ 20:18:
Nee, want hij heeft de challange code nog niet...

Die stuurt de server toch op voordat jij de response opstuurt?

[Roa]

Explore schreef op 14 August 2003 @ 19:39:
Altijd fijn dat ik van dienst kan zijn.

In m'n eerste post hier staat een link naar Experts-Exchange waarin het proxy verhaal staat uitgelegd (of kijk anders in de PHP area naar een soortgelijk topic wat ik daar gestart ben). Overigens wordt me daar aangeraden het Challange-Response Authentication Machanism (CRAM) te combineren met cookies tbv. session hacking. Dit dus ivm. het feit dat je IP's niet kan vertrouwen. Als het desbetreffende cookie niet meer bestaat wipe je de session en wordt de persoon gelijk uitgelogd.

Of dat allemaal even goed werkt, weet ik niet zo zeker, maar 't is inmiddels in iedergeval erg moeilijk om het zaakje te hacken. M'n implementatie van CRAM staat inmiddels al een tijdje online en er is nog niemand in geslaagd om het te kraken.

Dus op zich ben ik zo ook wel content. Wellicht implementeer ik de anti session-hack er nog overheen. Dat is zo'n beetje het enige aspect wat niet te checken valt in zo'n test-environment.

Ik ben juist van cookies op sessions overgestapt zodat ik geen cookies meer hoefde te zetten. Voor het CSM was ik WEL van plan om nog een extra laag van beveiliging aan te brengen dmv cookies en wellicht een timeout waarde (na * aantal minuten session automatisch vernietigen, alhoewel ik nog niet zeker weet hoe ik dit moet gaan automatiseren...), maar voor de normale site vind ik de ip check wel goed genoeg eigenlijk, waarom zou je allemaal moeite doen om een ip te spoofen om de session van een normale user (geen rechten) te kunnen stelen

OlafvdSpek schreef op 14 August 2003 @ 19:58:
[...]

Lost dat ook een DB-hack op?
Als een user de hash uit de DB steelt kan hij daar toch gewoon cd challenge-response mee uitvoeren?

Fout. Als jij bij registratie als password een hash van de username + het password opslaat en dan md5 codeerd, heeft niemand wat aan die hash als die opgevangen of uit de database gehaald zou worden. Je weet immers nog steeds het password niet dat je zou moeten intikken, nu kan je zelf form maken warin je gewoon die hash zet, maar dan mis je dus die chalenge code, dan zou je die ook weer ergens vandaan moeten halen. Lijkt me toch een redelijk waterdicht systeem eigenlijk...

[curry684]

Lost dat ook een DB-hack op?
Als een user de hash uit de DB steelt kan hij daar toch gewoon cd challenge-response mee uitvoeren?

Het maakt het stukken onwaarschijnlijker, maar het kan niet 100% waterdicht. Secure transfer houdt in dat er common data bekend is bij partijen A en B waardoor C de data niet kan lezen. Bij een DB-hack is alle data van A en B bekend bij C, en kan hij dus met wat moeite hacken. Je kunt iig het password niet reversen om er op andere sites mee in te breken.

[Sluuut]

Een beetje erg offtopic maar waar staat TBL voor ?

beetje?!?

[ Voor 24% gewijzigd door curry684 op 15-08-2003 10:24 ]

[Olaf van der Spek]

curry684 schreef op 15 augustus 2003 @ 10:11:
Het maakt het stukken onwaarschijnlijker, maar het kan niet 100% waterdicht. Secure transfer houdt in dat er common data bekend is bij partijen A en B waardoor C de data niet kan lezen. Bij een DB-hack is alle data van A en B bekend bij C, en kan hij dus met wat moeite hacken. Je kunt iig het password niet reversen om er op andere sites mee in te breken.

Bij simpele authenticatie kun je de password hash dubbel hashen. Als je dan de md5 van het password naar de server stuurt doet de server nog een keer md5 en vergelijkt het resultaat daarvan met de DB entry. Als je de DB entry hebt kun je echter niet inloggen.
Kan zoiets ook niet bij de challenge-response methode?

[Explore]

Roa schreef op 15 August 2003 @ 00:15:
Ik ben juist van cookies op sessions overgestapt zodat ik geen cookies meer hoefde te zetten. Voor het CSM was ik WEL van plan om nog een extra laag van beveiliging aan te brengen dmv cookies en wellicht een timeout waarde (na * aantal minuten session automatisch vernietigen, alhoewel ik nog niet zeker weet hoe ik dit moet gaan automatiseren...), maar voor de normale site vind ik de ip check wel goed genoeg eigenlijk, waarom zou je allemaal moeite doen om een ip te spoofen om de session van een normale user (geen rechten) te kunnen stelen

Ja, dat las ik, maar het probleem met IP-nummers is dus dat ze niet te vertrouwen zijn, ook niet bij normale user logins. Dus een cookie zetten bij een succesvolle login kan je dan gebruiken om hetzelfde effect te krijgen. Ik heb het nog niet gemaakt en getest, maar ik zie dat wel zitten.

Bij simpele authenticatie kun je de password hash dubbel hashen. Als je dan de md5 van het password naar de server stuurt doet de server nog een keer md5 en vergelijkt het resultaat daarvan met de DB entry. Als je de DB entry hebt kun je echter niet inloggen.
Kan zoiets ook niet bij de challenge-response methode?

Dat doe ik nu toch? Zie code bovenaan en de client-side code op de pagina waar ik naar verwijs.

[ Voor 19% gewijzigd door Explore op 15-08-2003 13:47 ]

[Olaf van der Spek]

Explore schreef op 15 August 2003 @ 13:46:
Ja, dat las ik, maar het probleem met IP-nummers is dus dat ze niet te vertrouwen zijn, ook niet bij normale user logins. Dus een cookie zetten bij een succesvolle login kan je dan gebruiken om hetzelfde effect te krijgen. Ik heb het nog niet gemaakt en getest, maar ik zie dat wel zitten.

Maar de session identifier zit toch ook in een cookie? Wat voor veiligheid geeft een extra cookie dan?

Dat doe ik nu toch? Zie code bovenaan en de client-side code op de pagina waar ik naar verwijs.

Ik zie het. Maar dan is de DB-hack toch geen probleem meer?

[Roa]

[quote]Explore schreef op 15 August 2003 @ 13:46:
[...]

Ja, dat las ik, maar het probleem met IP-nummers is dus dat ze niet te vertrouwen zijn, ook niet bij normale user logins. Dus een cookie zetten bij een succesvolle login kan je dan gebruiken om hetzelfde effect te krijgen. Ik heb het nog niet gemaakt en getest, maar ik zie dat wel zitten.
[quote]

Tja...Hoezo zijn IP-adressen niet te vertrouwen? Dat vraag ik me nu toch eigenlijk wel af....

Maar de session identifier zit toch ook in een cookie? Wat voor veiligheid geeft een extra cookie dan?

Als de session gekaapt word door persoon C, mist persoon C die extra cookie, en heb je door dat het iemand anders.

[Olaf van der Spek]

AOL gebruikt geloof ik multi-homed proxy servers. Request 1 van user komt dan vanaf een ander IPA dan request twee van dezelfde user.

En als die session identified gekaapt wordt, zit dat cookie er toch ook bij?

[Roa]

OlafvdSpek schreef op 15 August 2003 @ 23:11:
AOL gebruikt geloof ik multi-homed proxy servers. Request 1 van user komt dan vanaf een ander IPA dan request twee van dezelfde user.

En als die session identified gekaapt wordt, zit dat cookie er toch ook bij?

Nee, want je zet ZELF een EXTRA cookie. Die cookie staat voor een buitenstaander geheel los van je hele login systeempje. Dus bijvoorbeeld:

- Je start een sessie A
- Aan die sessie zit een session_cookie (A) vast, sessions worden nu eenmaal in cookies gesaved
- Je zet een Cookie B, met bijvoorbeeld een hash van de session_id, username, whatever jij wil.
- De sessie word gekaapt, incluis cookie A
- Jij checked op sessie en op cookie B, hé! COOKIE B IS ER NIET!!

Snappie

[Suepahfly]

Ik heb even snel over de code heen gekeken en opzich ziet het er wel veilig uit en als je het hele zikkie over een ssl verbinding gooit heb je inpricie een veilig systeem.

Maar het is tegenwoordig ook niet al te moeilijk meer om een server te kraken daar zijn al veel verschillende exploits voor, zelfs voor linux zijn er tegenwoordig proggies te krijgen waar de gemiddelde scriptkid al me uit de voeten kan (SucKIT bv.).

En als je echt weilig wilt zijn moet een naar je OS kijken, HP-UX komt het best uit de test (slecht 2% van alle geraporteerde beveiliginslekken t.o.v 83%MS, 29% Linux heb ik ergens gelezen)

Maar je moet je zelf afvragen hoe groot de kans is dat iemand j systeem wil hacken/cracken.
Zo lang je geen overheidsinstelling o.i.d bent zal die kans niet bijzonder groot zijn.

En verder alles wat je maakt valt te kraken, dus 100% veilig kan nooit

[Olaf van der Spek]

Roa schreef op 15 August 2003 @ 23:25:
[...]


Nee, want je zet ZELF een EXTRA cookie. Die cookie staat voor een buitenstaander geheel los van je hele login systeempje. Dus bijvoorbeeld:

- Je start een sessie A
- Aan die sessie zit een session_cookie (A) vast, sessions worden nu eenmaal in cookies gesaved
- Je zet een Cookie B, met bijvoorbeeld een hash van de session_id, username, whatever jij wil.
- De sessie word gekaapt, incluis cookie A
- Jij checked op sessie en op cookie B, hé! COOKIE B IS ER NIET!!

Snappie

Hoe snel denk je dat de aanvaller door heeft dat cookie B ook meespeelt?

[Roa]

OlafvdSpek schreef op 16 August 2003 @ 00:29:
[...]

Hoe snel denk je dat de aanvaller door heeft dat cookie B ook meespeelt?

Ja, das waar, maar ja, als iemand binnen wil komen lukt het uiteindelijk toch wel. Het is in ieder geval weer een btje moeilijker, als je een waarde in je cookie zet die moeilijk te faken is ofzo....Tja, zo kan je door blijven gaan....

[Verwijderd]

Je kunt bij elke opgevraagde pagina een nieuwe (pseudo-random) code in die cookie B zetten, zodat, zolang de 'echte' user aan het surfen is, iedere keer als hij een nieuwe pagina opvraagt de hacker er weer af ligt

[...]
Voor het CSM was ik WEL van plan om nog een extra laag van beveiliging aan te brengen dmv cookies en wellicht een timeout waarde (na * aantal minuten session automatisch vernietigen, alhoewel ik nog niet zeker weet hoe ik dit moet gaan automatiseren...)
[...]

Je kunt bij de standaard-include die bij elke pagina aangeroepen wordt, voordat de pagina wordt samengesteld of users gecontroleerd worden, alle sessions verwijderen waar geldt
aanmaakdatum <= nu - sessielengte

Zolang er geen pagina opgevraagd wordt maakt het namelijk niet uit of de sessiegegevens 'achter lopen'.

[ Voor 3% gewijzigd door Verwijderd op 16-08-2003 22:31 ]

[Verwijderd]

mysql_escape_string is beter dan addslashes in mysql queries.

modbreak: psst check voortaan even of je niet toevallig een topic van 5 maanden oud omhoogschupt met een al of niet nuttige toevoeging, meestal is het tegen die tijd minder relevant

[ Voor 65% gewijzigd door curry684 op 26-01-2004 13:40 ]

[Verwijderd]

Ok ik vind dit wel een interessant onderwerp, omdat ik huidig nu altijd gebruik maak van een hash opgeslagen in een cookie. Maar nu hoor ik wel dat er een paar anderen over willen stappen op sessies. Maar dan sla je wel telkens de hash op in een sessie en je check-cookie zoals werd gezegd, maar dan krijg je dus wel weer het euvel van dat je iedere keer opnieuw moet inloggen waar mensen vaak een hekel aan hebben.

[PrisonerOfPain]

Verwijderd schreef op 26 januari 2004 @ 14:34:
Ok ik vind dit wel een interessant onderwerp, omdat ik huidig nu altijd gebruik maak van een hash opgeslagen in een cookie.

Toch geen hash van het password he? dan kun je het er net zo goed plaintext in zetten

[Verwijderd]

nee die md5 ik

[CyberSnooP]

Verwijderd schreef op 26 januari 2004 @ 14:42:
nee die md5 ik

De vraag is wat je als authenticatie gebruikt. Plaats je een constant element (zoals een wachtwoord of een of andere obscure variant ervan zoals een md5-hash) in een cookie en controleer je daar mee de authenticiteit van je bezoeker dan ben je slecht bezig.

Waarom? Omdat iemand nu zich kan voordoen door simpelweg die cookie over te nemen / na te maken.

Wat beter is is een cookie-element (variabele) die na het inloggen een waarde krijgt toegewezen die je gedurende de sessie als geldig beschouwt. Dit namaken heeft geen zin omdat de sessie verloopt na een poosje.

[SWINX]

Verwijderd schreef op 26 januari 2004 @ 13:36:
modbreak: psst check voortaan even of je niet toevallig een topic van 5 maanden oud omhoogschupt met een al of niet nuttige toevoeging, meestal is het tegen die tijd minder relevant

je zou er ook een slot op kunnen zetten natuurlijk

[creative8500]

Verwijderd schreef op 26 januari 2004 @ 14:34:
Ok ik vind dit wel een interessant onderwerp, omdat ik huidig nu altijd gebruik maak van een hash opgeslagen in een cookie. Maar nu hoor ik wel dat er een paar anderen over willen stappen op sessies. Maar dan sla je wel telkens de hash op in een sessie en je check-cookie zoals werd gezegd, maar dan krijg je dus wel weer het euvel van dat je iedere keer opnieuw moet inloggen waar mensen vaak een hekel aan hebben.

Een punt van aandacht is natuurlijk: er zijn mensen _{zoals ik} die cookies uit hebben staan. Ik vind dat een login-script daarbij ook moet werken. Dat ik niet ingelogd blijf is mijn keus. (Als ik dat toch zou willen zet ik de site wel in mijn allow-lijst.)

[Olaf van der Spek]

creative8500 schreef op 27 januari 2004 @ 08:38:
Een punt van aandacht is natuurlijk: er zijn mensen _{zoals ik} die cookies uit hebben staan. Ik vind dat een login-script daarbij ook moet werken. Dat ik niet ingelogd blijf is mijn keus. (Als ik dat toch zou willen zet ik de site wel in mijn allow-lijst.)

Hoe moet de site dan weten dat jij ingelogd bent?
Of wilde je op elke pagina opnieuw je password intypen?

[PrisonerOfPain]

OlafvdSpek schreef op 27 januari 2004 @ 10:12:
[...]

Hoe moet de site dan weten dat jij ingelogd bent?
Of wilde je op elke pagina opnieuw je password intypen?

Daar hebben ze sessie voor uitgevonden die setten een cookie, maar als dat niet kan plakken ze het 'sessid' achter de url om zo te zien om welke gebruiker het gaat

[curry684]

SWINX schreef op 27 januari 2004 @ 00:48:
[...]
je zou er ook een slot op kunnen zetten natuurlijk

En daarmee de hele interessante discussie die hier nu weer oplaait afstoppen plus de search corrumperen door de interessante info uit dit topic tot 'gesloten' te markeren

Modereren is meer dan sloten zetten

[Verwijderd]

tipje:

misschien nog een idee om brute force attacks tegen te gaan door een user account 5 minuten te locken als hij meer dan x keer een verkeerd password heeft ontvangen.