Archief - PHP: sessies vraag

BloodSeaker · 19 jun 2004

op een site gebruiken we sessies als loginmethode. Die persoon heeft dat (voor een gedeelte) als volgt gecodeerd

PHP:

$_SESSION["userid"] = $row["userId"];
$_SESSION["usnaam"] = $row["username"];
$_SESSION["domainid"] = $row["domainId"];
$session = $_SESSION;
$sessdata_str = serialize($session);
$hash = md5($sessdata_str);
session_register("hash");

// login cookies
$uchash = md5($_SESSION["userid"]."*******");
Setcookie("userid", $_SESSION["userid"], Time()+3600*60*60);
Setcookie("chash", $uchash, Time()+3600*60*60);

Nu zou ik graag weten, hoe vraag je nu op of de gebruiker werkelijk ingelogd is en de sessie nie vervalst is

PS: is het normaal dat als je niet ingelogd zijt, je toch een sessiestring meekrijgt in de url :/, dus ala pagina.php?mode=doeiets&sessienaam=4feff4ffdzsf....

Da Turtle · 19 jun 2004

normaal komen sessions toch niet in de url?? da zou ook wel gemakkelijk zijn

BloodSeaker · 19 jun 2004

Da Turtle zei:
normaal komen sessions toch niet in de url?? da zou ook wel gemakkelijk zijn

Awel ja, leg het me eens uit, want daar stelde ik me ok vragen bij toen ik da zag zenne :/

edit: tis dus nie mijn code die hierboven

Dece · 19 jun 2004

die sessienaam is de session_id() die hij meegeeft lijkt me op het eerste gezicht.
nu kdacht dat dit soort van sessions(opgeslagen in temp map van de server) makkelijker te kraken waren dan als ge u username ed. in de SQL database stopt.

BloodSeaker · 19 jun 2004

Dece zei:
die sessienaam is de session_id() die hij meegeeft lijkt me op het eerste gezicht.
nu kdacht dat dit soort van sessions(opgeslagen in temp map van de server) makkelijker te kraken waren dan als ge u username ed. in de SQL database stopt.

mja username en alles zit wel in de database natuurlijk :/ en bij loggedin checken we of de gegevens binnen de sessies en zo overeenkomen met gegevens uit database

Kan er anders iemand goed uitleggen hoe een veilige login best te maken is (sessies, cookies, mysql, de hele reutemeteut)

BloodSeaker · 20 jun 2004

BloodSeaker zei:
mja username en alles zit wel in de database natuurlijk :/ en bij loggedin checken we of de gegevens binnen de sessies en zo overeenkomen met gegevens uit database

Kan er anders iemand goed uitleggen hoe een veilige login best te maken is (sessies, cookies, mysql, de hele reutemeteut)

niemand???

Sabe · 20 jun 2004

als ge zoiets in flash maakt is da toch totaal ni te kraken of the achterhalen?
of ben ik verkeerd?
correct me i am wrong, don't shoot me

(noob @ this vlak

)

icerulez · 20 jun 2004

open uw flash file eens in kladblok, met beetje geluk ziet ge u paswoord staan, maw. flash is niet veilig...

killgore · 20 jun 2004

sessies kunde niet vervalsen, aangezien de user enkel acces heeft tot de sessionid

.

sessieid wordt in cookie gestoken of in url, enige controle die je kan doen is ip-check. (iets alla if($_SESSION['id'] == $_SERVER["REMOTE_ADDR"]) (en nie beginne krefte over proxies en zo, dit is een klein en simpel vb.)
Gebruik geen session_register, das voorbijgestreefd

.

Lashknife · 22 jun 2004

op wat is een session id eigenlijk gebaseerd? tijd?

indien niet tijd, dan kan het toch toevallig voorkomen dat een andere user diezelfde sessie krijgt omdat die al lang afgesloten is elders (beetje debiel voorbeeld, maar dan zou die sessie te pakken zijn eh)

killgore · 22 jun 2004

Lashknife zei:
op wat is een session id eigenlijk gebaseerd? tijd?

indien niet tijd, dan kan het toch toevallig voorkomen dat een andere user diezelfde sessie krijgt omdat die al lang afgesloten is elders (beetje debiel voorbeeld, maar dan zou die sessie te pakken zijn eh)

sessies vervallen, wat kan worden ingesteld in de php.ini, na 15 min. en zend-makers zullen nu niet zo dom zijn om te zorgen dat 2 personenen binnen het uur of zo hetzelfde sessionid krijgen, ze zullen prolly eerst al checken of die sessionid al bestaatn

.

Dece · 22 jun 2004

kdacht dat die session id een volledig random gegenereerd wordt
iets zoals dit wss, enkel wat complexer

PHP:

<?php 
$str = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
//aantal tekens in string
$lengte = strlen($str);
//aantal lussen
$aantal = 10;
for ($x=1; $aantal >= $x; $x++) {
	//genereren van een random getal
	$getal = (int) rand(0, $lengte);
	//getal komt overeen met een positie in de $str
	$letter = substr($str, $getal, 1);
	echo $letter;
}
?>

Hierdoor is het volgens mij bena onmogelijk om 2 keer dezelfde session_id te hebben

Lashknife · 22 jun 2004

killgore zei:
sessies vervallen, wat kan worden ingesteld in de php.ini, na 15 min. en zend-makers zullen nu niet zo dom zijn om te zorgen dat 2 personenen binnen het uur of zo hetzelfde sessionid krijgen, ze zullen prolly eerst al checken of die sessionid al bestaatn .

dermee -> "beetje debiel voorbeeld"

zou idd wel al te belachelijk zijn

sneax · 22 jun 2004

ik steek gewoon user id in één cookie en in een ander cookie steekek md5 hash van zoiets:

password|::|xxx.xxx.xxx.xxx (huidig ip)

of het veilig is geen idee, maar de theorie die erachter zit is deze:
- als iemand gewoon die md5 hash pikt en vanop zijn computer 'laat versturen' als cookie dan ziet mijn script dat dit van andere pc komt (andere hash want ander ip)

- een eigen hash maken om voorbij de ip check te geraken lukt ook ni want ge weet het password ni

of het veilig is dunno ma tis imo toch veilig genoeg

killgore · 22 jun 2004

sneax zei:
ik steek gewoon user id in één cookie en in een ander cookie steekek md5 hash van zoiets:

password|::|xxx.xxx.xxx.xxx (huidig ip)

of het veilig is geen idee, maar de theorie die erachter zit is deze:
- als iemand gewoon die md5 hash pikt en vanop zijn computer 'laat versturen' als cookie dan ziet mijn script dat dit van andere pc komt (andere hash want ander ip)

- een eigen hash maken om voorbij de ip check te geraken lukt ook ni want ge weet het password ni

of het veilig is dunno ma tis imo toch veilig genoeg

dunno, ma ge kunt da evengoed met sessies doen die controle en is dus nog veiliger

. (ma we zijn weer aant miereneuken

)

sneax · 22 jun 2004

killgore zei:
dunno, ma ge kunt da evengoed met sessies doen die controle en is dus nog veiliger . (ma we zijn weer aant miereneuken )

Da zal wss wel, ik heb mij eigenlijk nog nooit me sessions beziggehouden, maar zolang mij 'systeem' het volhoud blijf ik daar maar bij

servi · 23 jun 2004

een enige 100%-veilige manier die ik ken, is waar je een public and private key gebruikt en waar uiteraard het paswoord of de sessie dat wordt doorgestuurd elke keer veranderd bij het opvragen van een nieuwe pagina.

sys4096 · 23 jun 2004

Een sessie Id wordt altijd door de server aangemaakt. Er is geen vaste regel hoe die tot stand komt. Afhankelijk van de webserver is de sessie id al iets meer random dan de andere. Als je bv een paar keer inlogt en je merkt dat er een patroon inzit, valt het eventueel te voorspellen wat de volgende sessie id gaat zijn. Men spreekt dan van Session Hijacking .

sneax · 23 jun 2004

sneax zei:
ik steek gewoon user id in één cookie en in een ander cookie steekek md5 hash van zoiets:

password|::|xxx.xxx.xxx.xxx (huidig ip)

of het veilig is geen idee, maar de theorie die erachter zit is deze:
- als iemand gewoon die md5 hash pikt en vanop zijn computer 'laat versturen' als cookie dan ziet mijn script dat dit van andere pc komt (andere hash want ander ip)

- een eigen hash maken om voorbij de ip check te geraken lukt ook ni want ge weet het password ni

of het veilig is dunno ma tis imo toch veilig genoeg

hoe zou ge dit kunnen hacken? da vraag ik mij af, das toch al redelijk veilig?

servi · 23 jun 2004

heel simpel te omzeilen door het feit dat de hacker niet zijn echt ip-adres gaat doorgeven.

Archief - PHP: sessies vraag

BloodSeaker

Legacy Member

Da Turtle

Legacy Member

BloodSeaker

Legacy Member

Dece

Legacy Member

BloodSeaker

Legacy Member

BloodSeaker

Legacy Member

Sabe

Legacy Member

icerulez

Legacy Member

killgore

Legacy Member

Lashknife

Legacy Member

killgore

Legacy Member

Dece

Legacy Member

Lashknife

Legacy Member

sneax

Legacy Member

killgore

Legacy Member

sneax

Legacy Member

servi

Legacy Member

sys4096

Legacy Member

sneax

Legacy Member

servi

Legacy Member