[PHP]Veilig encryptie voor een cookie

[packman]

Ik ben dus bezig met een algemeen login script, waar men kan kiezen om een cookie te saven voor het paswoord te onthouden.

Nu wil ik het paswoord en de username daar niet in plain text in zetten (idd, zelfs de username niet), die wil ik encrypteren, zodat niet iedereen gewoon in de cookies map kan gaan kijken en inloggen. Hoe doe ik dit? Met de crypt functie gaat dit blijkbaar niet en ik heb nog geen echte encryptie in php tegengekomen voor de rest.

[Verwijderd]

http://www.php.net/manual/en/ref.mcrypt.php
Mogelijkheden zat toch?

[ACM]

Wat gaat er mis met crypt dan?

Je moet als je de crypting wilt testen even
crypt($password, $salt)
voor salt het het crypted password invoeren.
Dan doe je dus iets als:

PHP:

<?
if(crypt($password_in_db, $crypted_pw_from_cookie) == $crypted_pw_from_cookie))
{
//netjes ingelogd
}
else
{
// niet netjes ingelogd
}
?>

[Verwijderd]

niet netjes ingelogd-> niet ingelogd

[packman]

Het probleem is dat ik zowel het paswoord als de usernaam MOET encrypteren.

Aan het paswoord in de database geraak ik dus niet zo gemakkelijk...

[packman]

Joska, jouw idee had ik ook al gevonden, maar de mcrypt library is niet geinstalleerd op de server waar het op moet komen

[Verwijderd]

Op vrijdag 01 juni 2001 20:35 schreef packman het volgende:
Joska, jouw idee had ik ook al gevonden, maar de mcrypt library is niet geinstalleerd op de server waar het op moet komen

md5 wel? dan sla je gewoon md5 van het password op. en die vergelijk je later met de md5() van de kolom

[packman]

MD5 is niet echt "hack proof".

Een PIII 500 kan zo'n 750.000 MD5's berekenen PER SECONDE. Zet daar dus een Athlon 1.33 op en een paswoord van 8 karakters is gekraakt in minder dan 1 dag. No tnx, ook al naar gezien. MD5 is trouwens geen encryptiemethode, maar een hash algorithme.

[packman]

waar is mijn user icon trouwens naar toe...

Disk crash zeker...

[mayhem]

Op vrijdag 01 juni 2001 20:53 schreef packman het volgende:
waar is mijn user icon trouwens naar toe...

Disk crash zeker...

dan moet je ff in je profile het plaatje selecteren en dan je profiel bijwerken

[ACM]

Op vrijdag 01 juni 2001 20:31 schreef packman het volgende:

En sessions zijn geen optie?

[Aceton]

Op vrijdag 01 juni 2001 20:26 schreef packman het volgende:
Nu wil ik het paswoord en de username daar niet in plain text in zetten (idd, zelfs de username niet), die wil ik encrypteren, zodat niet iedereen gewoon in de cookies map kan gaan kijken en inloggen. Hoe doe ik dit?

Je kan dan encrypten tot je een ons weegt als je er niet voor zorgt dat iemand niet gewoon het cookie kan copieren en dan gebruiken Die persoon weet dan weliswaar username en wachtwoord niet, maar kan het complete cookie gebruiken (dus misschien ook IP adres erbij opslaan?)

[packman]

Je kan dan encrypten tot je een ons weegt als je er niet voor zorgt dat iemand niet gewoon het cookie kan copieren en dan gebruiken Die persoon weet dan weliswaar username en wachtwoord niet, maar kan het complete cookie gebruiken (dus misschien ook IP adres erbij opslaan?)

hmmm you have a point, maar een IP adres veranderd snel he...

En sessions zijn geen optie?

Het is juist om de session op te zetten voor de verificatie te doen.

[ACM]

Op vrijdag 01 juni 2001 21:29 schreef packman het volgende:
Het is juist om de session op te zetten voor de verificatie te doen.

Euhmz?
Dan zou ik _geen_ username en password maar een simpel sessionid (of niet zo simpel) opslaan in je cookie en verder niets...

Dat is nou juist de grap van sessions...

[packman]

Een session wordt toch meestal beeindigd op het moment dat de browser wordt afgesloten?

Hoe zou je dat dan doen. Ik vind hier namelijk geen info over hoe dat te doen.

Ik kan wel het user id vanuit de database wel in het cookie zetten

[ACM]

Eigen session implementatie maken, of de cookie levensduur verlengen

[Mior]

wat ik altijd doe is een salt key opgeven..

PHP:

<?
function CryptData($data) {
    $zout = "willekeurigekey";
    return crypt ($data,$zout);
}
?>

[tomato]

Op vrijdag 01 juni 2001 20:53 schreef packman het volgende:
MD5 is niet echt "hack proof".

Een PIII 500 kan zo'n 750.000 MD5's berekenen PER SECONDE. Zet daar dus een Athlon 1.33 op en een paswoord van 8 karakters is gekraakt in minder dan 1 dag. No tnx, ook al naar gezien. MD5 is trouwens geen encryptiemethode, maar een hash algorithme.

Bullshit. Zeker ook opgewonden geworden door dat hackerstooltje? Denk eerst eens goed na over het gebruik van een MD5 checksum voordat je iets blaat...

[ACM]

Op vrijdag 01 juni 2001 23:08 schreef tomato het volgende:
Bullshit. Zeker ook opgewonden geworden door dat hackerstooltje? Denk eerst eens goed na over het gebruik van een MD5 checksum voordat je iets blaat...

md5 is idd _niet_ voor encrypten van data geschreven...
Dus daar moet je het eigenlijk ook niet voor gebruiken...
De md5-crypting van linux/unix is natuurlijk een ander verhaal. (helaas weet ik niet precies hoe dat werkt )

[packman]

Bullshit. Zeker ook opgewonden geworden door dat hackerstooltje? Denk eerst eens goed na over het gebruik van een MD5 checksum voordat je iets blaat...

Hmm ik heb (ooit eens) zelf een geoptimaliseerde MD5 routine routine geschreven (in C) die dan later door iemand geoptimaliseerd is met stukjes assembler (assembler lezen gaat bij mij nog, aan het schrijven moet ik eens werken...)
Ik zal dus wel weten wat een MD5 is he...
MD5 is een checksum/hashing algorithme, en geen encryptie.

Hoe MD5 crypting in linux/unix gebeurd heb ik ook geen flauw benul van, maar als het op MD5 gebaseerd is kan dat veeeeeel te gemakkelijk brute force gekraakt worden. Veel 'tjes heb je daar niet voor nodig.

[packman]

Oh ja, zou dat kunnen dat de crypt methode in de win versie niet werkt? Ik zit namelijk in win te ontwikkelen, en heb geen zin te herstarten in linux. Dat is mijn experimenteel os, een omgebouwde slack 7.1 waarvan 3/4 hercompileerd is (X4.03, apache, kernel, php, kde, glibc, gcc,...). Nu zijn daar een paar dingetjes mis gelopen tijdens het prutsen in de kernel code en nu crasht dat regelmatig. Ik moet mijn kernel dus hercompileerd krijgen (maar hij crasht meestal halverwege), of eens beginnen debuggen (geen zin in) en ik heb per ongeluk mijn vorige overschreven

Tijd voor een reinstall denk ik

[tomato]

Op zaterdag 02 juni 2001 00:08 schreef packman het volgende:
Hmm ik heb (ooit eens) zelf een geoptimaliseerde MD5 routine routine geschreven (in C) die dan later door iemand geoptimaliseerd is met stukjes assembler (assembler lezen gaat bij mij nog, aan het schrijven moet ik eens werken...)

Ja leuk . Dat jij dat gemaakt hebt doet er niet zoveel toe, dat zulk soort tools bestaan, of iig kunnen bestaan was al bekend.

Ik zal dus wel weten wat een MD5 is he...

Heb ik dat dan tegengesproken?

MD5 is een checksum/hashing algorithme, en geen encryptie.

Dat zei je ook al in je eerste post en om maar net als jou te spreken: ik weet ook heus wel wat een MD5 is.

Hoe MD5 crypting in linux/unix gebeurd heb ik ook geen flauw benul van,

Ik ook niet, maar dit zul je binnen enkele seconden op het wereld wijde web kunnen vinden.

maar als het op MD5 gebaseerd is kan dat veeeeeel te gemakkelijk brute force gekraakt worden. Veel 'tjes heb je daar niet voor nodig.

Onzin, er zijn duizend encryptie methoden te bedenken gebaseerd op MD5 die jij nooit van je leven zult kraken.


Maar wat ik een post eerder zei staat dus nog steeds. Bullshit.

[RM-rf]

Op vrijdag 01 juni 2001 21:52 schreef packman het volgende:
Een session wordt toch meestal beeindigd op het moment dat de browser wordt afgesloten?

Hoe zou je dat dan doen. Ik vind hier namelijk geen info over hoe dat te doen.

Ik kan wel het user id vanuit de database wel in het cookie zetten

ik neem aan dat voor je topsecret systeem je de users ook aanraad om hun username password combinatie op een postit papiertje te schrijven en op hun monitor te plakken.

als je rant over MD5 en vervolgens je u-p-combinatie in een cookie gaat opslaan heb ik wel degelijk twijfels over je zelf-beschouwing.

stel na een correct gecheckede login (username en password matchen de gecrypede opgeslagen versie) retourneer je een sessionID; een gecrypede en gehashede string die je in je usertabel opslaat.

zolang je je cookie laat bestaan mag de user gebruik maken van je pagina's, de timeout stel je in naar believen (kwartier tot half uurtje is al scherp beveiligd) iedere refresh van een pagina ververst de timeout van je cookie eventueel koppel je een ID aan een IP (meehashen)

op basis van sessionId kun je dan user bepalen plus permissies.

als je applicatie dusdanig aantrekkelijk is dat je denkt dat mensen 1 dag een stevige doos erop laten kraken, is het idioot om mensen de mogelijkheid te bieden direct in te logen zonder eerst hun username en password in te geven, dus set je je timeout erg laag en koppel je aan IP.
afsluiten browser betekent afsluiten session en opnieuw inloggen.
daarbij biedt je een logout pagina die de timeout van de cookie op -1 stelt, al je cookiedata is dan verdwenen

zodra er geen juist sessionID is toon je de inlogpagina, misschien nog een id-tje om je inloggen via https te laten verlopen ivm nucleaire data?

(grappig heb eigenlijk geen idee hoe MD5 functioneert, is ook niet nodig om te weten hoe je er gebruik van maakt)

[tomato]

Op zaterdag 02 juni 2001 00:41 schreef RM-rf het volgende:
(grappig heb eigenlijk geen idee hoe MD5 functioneert, is ook niet nodig om te weten hoe je er gebruik van maakt)

Beschrijving

Voorbeeld in C

En nee, ik heb het niet grondig bestudeerd en ben het voorlopig ook niet van plan

[Verwijderd]

Op zaterdag 02 juni 2001 00:41 schreef RM-rf het volgende:

[..]

inderdaad, dit is de manier.

meer info over md5

ik zie trouwens niet echt in waarom je een combinatie van md5 en user id ofzo niet zou kunnen gebruiken als login voor een simpele page. Oke het is misschien te kraken, but so is everything else

En dat van die bruteforce dat valt nog wel mee hoor.

edit:
shit te laat met posten, moest ff ondertussen iemand helpen

[tomato]

Op zaterdag 02 juni 2001 01:04 schreef woeitje het volgende:
shit te laat met posten, moest ff ondertussen iemand helpen

Geldige reden

[Verwijderd]

Op zaterdag 02 juni 2001 01:09 schreef tomato het volgende:

[..]

Geldige reden

ja maar te laat blijft te laat
owja en vnc bleef hangen dus het is nog niet eens gelukt ook, is de reden dan nog geldig?

[packman]

Ik zal het eens kort samenvatten wat ik wil, want sommige mensen snappen niet wat ik juist wil bereiken.

Ik wil een veilige loginprocedure waarbij je kan zeggen dat het wachtwoord opgeslagen wordt in een cookie (zoals je hier op got en t.net kan). De data in dat cookie zou moeten geencrypteerd worden. Alles gaat over ssl.

De reden is de volgende: het probleem is dus dat mijn publiek "security aware" is (en dus niet zijn passwoord op een postitje op zijn scherm plakt zoals is gesuggereerd). Het zijn (normaalgezien) specialisten in zo'n zaken, en ik wil gewoon niet dat 1 het in zijn bol haalt om ff het siteje plat te leggen, dat is namelijk een uitdaging voor die mannen.

Dat opslaan van het paswoord moest erin volgens het ontwerp, en men wil daar geen mm van afwijken. De enige mogelijkheid is dus met cookie, waarin ik liefst ook de username in geencrypteerd in zie zodat iemand die een cookie te pakken krijgt het paswoord mischien wel kan achterhalen, maar niet kan inloggen omdat hij de juiste user naam niet heeft (die worden ook random gegenereerd btw).

Mijn idee was bij elke start van een sessie het cookie terug te setten, maar met een nieuwe random key , die in de database gestockeerd wordt in het user record. Random wordt er toch nog naar het paswoord gevraagd, en op sommige delen van de site (de gevoeligste, waar hij schade kan aanrichten) moet het paswoord toch terug ingegeven worden, zodat als iemand een cookie te pakken krijgt en daarna verkeerd inlogt dat account kan disablen en heraanmaken en de eigenaar waarschuwen.

[tomato]

Op zaterdag 02 juni 2001 01:44 schreef packman het volgende:
Ik zal het eens kort samenvatten wat ik wil, want sommige mensen snappen niet wat ik juist wil bereiken.

Het ging mij er om dat je MD5 onterecht afschreef. Een zeer goede encryptie functie is ook niet veilig. Een authenticatie methode waarin hij gebruikt wordt kan wel veilig zijn (hoeft niet). Zelfde geldt voor MD5. MD5 is op zichzelf ook niet veilig, maar kan wel gebruikt worden in een veilig systeem (ook in een onveilig systeem).
Mijn punt is dus dat je van een enctyptie of hash algoritme niet kunt zeggen of het veilig is, wel van de omgeving waarin het gebruikt wordt. Begin dus niet gelijk te roepen dat MD5 te kraken is met een Pentium 6 ofzo, want dat is niet relevant. Het is een eigenschap van MD5 hashing dat er naar een xxxxx aantal invoeren teruggerekend kan worden, maar dat wil niet zeggen dat dat onveilig is. Verkeerd gebruik ervan kan het onveilig maken! Net zoals een systeem waarin crypt() wordt gebruikt onveilig kan zijn.

Ik wil een veilige loginprocedure waarbij je kan zeggen dat het wachtwoord opgeslagen wordt in een cookie (zoals je hier op got en t.net kan). De data in dat cookie zou moeten geencrypteerd worden. Alles gaat over ssl.

Het password enctypted in een cookie zetten accepteer je plotseling weer wel? Vreemd hoor, dat zou ik iig nooit doen.

De reden is de volgende: het probleem is dus dat mijn publiek "security aware" is (en dus niet zijn passwoord op een postitje op zijn scherm plakt zoals is gesuggereerd). Het zijn (normaalgezien) specialisten in zo'n zaken, en ik wil gewoon niet dat 1 het in zijn bol haalt om ff het siteje plat te leggen, dat is namelijk een uitdaging voor die mannen.

Haha, een security aware publiek die zijn password graag in een cookie terug ziet, LOL
Volgens mij wil alleen 'niet-security-aware' publiek dat door gemakzucht.

Dat opslaan van het paswoord moest erin volgens het ontwerp, en men wil daar geen mm van afwijken.

Het ontwerp is dus door anderen gemaakt en jij moet het implementeren? Lijkt me dus zeer logisch dat jij een dikke vinger in de pap moet hebben mbt het ontwerp. Als jij zegt dat je het strikt volgens het ontwerp niet veilig kunt maken laten ze je heus niet gewoon verder coden.

De enige mogelijkheid is dus met cookie, waarin ik liefst ook de username in geencrypteerd in zie zodat iemand die een cookie te pakken krijgt het paswoord mischien wel kan achterhalen, maar niet kan inloggen omdat hij de juiste user naam niet heeft (die worden ook random gegenereerd btw).

Dat snap ik niet helemaal. Je slaat een wachtwoord encrypted op in een cookie, maar om er nou voor te zorgen dat ze niet achter de bijbehordende username kan komen sla je die er ook maar bij op? Zal wel aan mij liggen...

Mijn idee was bij elke start van een sessie het cookie terug te setten, maar met een nieuwe random key , die in de database gestockeerd wordt in het user record.

Ah, je gebruikt er ook nog sessions naast. Waarom dan het opslaan van dat wachtwoord nog? Werk dan gewoon alleen met sessions, wel of niet die door PHP ingebouwd.

Random wordt er toch nog naar het paswoord gevraagd

Dan is toch heel het nut van dat cookie verdwenen? Het moest er zo nodig in omdat die experts het password niet op een postitje hadden staan en het dus liever nooit meer in hoefden te voeren. Wat je nu ineens zegt vind ik dus wel vreemd.

, en op sommige delen van de site (de gevoeligste, waar hij schade kan aanrichten) moet het paswoord toch terug ingegeven worden

Idem

, zodat als iemand een cookie te pakken krijgt en daarna verkeerd inlogt dat account kan disablen en heraanmaken en de eigenaar waarschuwen.

Hmm jah, dat soort dingen zijn van later zorg en zijn geen onderdeel van je authenticatie back bone.


Over heel je verhaal: het is te ingewikkeld om veilig te kunnen zijn. De kracht van een veilig authenticatie systeem ligt vaak in de eenvoud van de methode. Bedenk een methode die zo eenvoudig is dat iedereen hem snapt. Bij deze methode stel je randvoorwaarden en regels op een terwijl je je daar aan houdt kun je het systeem eventueel wat uitbreiden. Een security systeem heeft dus een eenvoudige, stevige back bone nodig en dat mis ik in jouw verhaal. Dingen als random om passwords vragen enzo is misschien leuk om later toe te voegen maar het is heel fout als je systeem daar ook maar een beetje van af hangt en hoort dus niet in de definitie van je authenticatie methode thuis.
Een ingewikkeld systeem is ook veel gevoeliger voor bugs btw.

Just my 2 cents

(helemaal geen offence btw, al klonk het misschien soms zo, maar ik wilde gewoon mijn standpunt duidelijk maken want ik denk dat je daar iets aan kunt hebben )

[Verwijderd]

wat is er mis met .htaccess ?

[Life-is-party]

Op zaterdag 02 juni 2001 01:04 schreef woeitje het volgende:

[..]

inderdaad, dit is de manier.

meer info over md5

ik zie trouwens niet echt in waarom je een combinatie van md5 en user id ofzo niet zou kunnen gebruiken als login voor een simpele page. Oke het is misschien te kraken, but so is everything else

En dat van die bruteforce dat valt nog wel mee hoor.

edit:
shit te laat met posten, moest ff ondertussen iemand helpen

Ik heb 2 cookies geset voor mijn systeem.
1'tje met user ID
en eentje met een
MD5hash van => Username-Password-Secretword
En die vergelijk ik dan als iemand zich meld met een cookie.

Oké dit zal misschien te kraken zijn. ZoWAT. dan kan diegene reacties plaatsen onder iemand anders naam.... dat is het enige.

[Grum]

^{[fluistermode]sessions :?[/fluistermode]}

[Johannes]

Op dinsdag 23 oktober 2001 10:27 schreef dombie-dom het volgende:

[..]

Ik heb 2 cookies geset voor mijn systeem.
1'tje met user ID
en eentje met een
MD5hash van => Username-Password-Secretword
En die vergelijk ik dan als iemand zich meld met een cookie.

Oké dit zal misschien te kraken zijn. ZoWAT. dan kan diegene reacties plaatsen onder iemand anders naam.... dat is het enige.

Ehm, moet je de userid dan niet ook meenemen in de md5 hash? Nu kan je zo ff de userid veranderen in het cookie. Ik weet natuurlijk niet of die ergens gebruikt wordt, maar toch.