PHP_AUTH_USER legen en wissen

[Verwijderd]

Hoi Hoi,

Ik weet hoe ik via een htacces en htpswd een php_auth_user kan laten inloggen.
Nu is het probleem uitloggen:
via

PHP:

$_SERVER['PHP_AUTH_USER']='';
$PHP_AUTH_USER  = '';

leegt hij de php_auth_user wel maar als men op login klikt hoefr men niets in te voeren en logged hij zelf weer in....

hoe dit op te lossen zodat hij dat ww en die username niet meer kent.....

Is er trouwens ook de mogelijkheid dat hij zichzelf totaal afmeld als user wanneer met bijv. 10min inactief is?

ik hoor het graag van jullie

[Erkens]

Dat kan niet, behalve door opnieuw dat login scherm weer te geven of door de browser(s) af te sluiten. Zo werkt HTTP authenticatie nu eenmaal. Wil je meer dan zal je zelf een login systeem moeten implementeren.

[frickY]

De browser onthout de loginnaam en wachtwoord welke bij het inloggen is gegeven, en stuurt die bij elke request mee. Je kan die variabele dus niet legen, aangezien hij bij elke request opnieuw wordt geset.

Je kunt een 401 Unauthorised status (header()) sturen zodat de browser opnieuw de login-dialogue toont.

[Verwijderd]

werkt dat automatisch uitloggen niet OF werkt dat uitloggen via de knop niet?

[frickY]

Het werkt uberhaupt niet, de browser onthoud de inlogt gegevens zolang deze greaccepteerd worden. Met een 4001-status geef je dus aan dat ze niet meer geaccepteerd worden.

[Verwijderd]

wow, dit gaat me effe te snel en te ver...

de login knop veranderd na ingelogd te zijn naar een logout knop, wanneer ik de bovenstaande code gebruik, komt er wel weer een login knop maar vraagt hij het login scherm niet meer...

[Erkens]

Je _KAN_ zo'n login sessie niet uitloggen anders dan opnieuw een login weer te geven.
Lees de specificatie maar eens door

[RM-rf]

Verwijderd schreef op vrijdag 16 december 2005 @ 12:29:

hoe dit op te lossen zodat hij dat ww en die username niet meer kent.....

ik dacht dat de enige methode een beetje een omweg is, en bovendien volgens mij belokked door sommige firewalls en browsers vanwege misbruik door Phising-sites:

PHP:

header( "location: http://uitlognaam:[e-mail]/" );

dat refert gewoon naar een nieuwe 'inlogpoging' onder een niet bestaande inlognaam, daarmee wordt je oude AUTH_USR ook weggegooid ... maar het is zeker geen foutloze en afhankelijk van 'clienstide' zaken, dus je moet er niet te sterk op bouwen, en ermee opassen in bedrijfskritieke zaken.

[Verwijderd]

Kortom,


werkt niet..

das balen, moet er een andere login komen.. ik dacht nogwel dat een php_auth_user veilig was...

[Erkens]

Verwijderd schreef op vrijdag 16 december 2005 @ 12:42:
das balen, moet er een andere login komen.. ik dacht nogwel dat een php_auth_user veilig was...

het is verre van veilig, bij elke request op die server wordt de username en password weer opnieuw leesbaar over de lijn gegooid
Met een "home made" login systeem zal dat alleen een session ID zijn (als je slim bent)

[Verwijderd]

zover ik had begrepen, is het moeilijker te hacken ivm popup login scherm met 3 max try's...

verdorie, home made login nog nooit gemaakt met sessie, halve site weer afbreken... shit hapens...

iemand nog goede tips?

[Erkens]

Verwijderd schreef op vrijdag 16 december 2005 @ 12:45:
zover ik had begrepen, is het moeilijker te hacken ivm popup login scherm met 3 max try's...

max 3 try's?
dat ligt aan je browser want in principe is het onbeperkt, IE zorgt er alleen voor dat je na 3x de melding van de server ziet, bij Firefox kan je onbeperkt proberen tot je op Cancel drukt

iemand nog goede tips?

kijken hoe andere een login hebben geimplementeerd en/of delen van die code overnemen (indien dat mogelijk is)

[Equator]

Er zijn op phpfreaks wel enkele voorbeelden te vinden denk ik..

Ik heb er zelf ook 1 gemaakt met gebruik van sessions. Uiteindelijk is het niet zo moelijk, maar je zal je er even op in moeten lezen..

[Erkens]

het simpelste is door een username/password form te verwerken, die gegevens in een sessie te stoppen. uitloggen kan dan door die username/password er weer uit te halen.

[eamelink]

Een simpele workaround is gewoon een cookie 'logged out' setten met session lifetime. Als dat cookie bestaat houdt je de user gewoon op uitgelogd, tenzij hij expliciet wil inloggen .

[Equator]

Omdat ik er toch over dacht om i.p.v. losse functions met classes te gaan werken was ik al begonnen met een herschreven session systeem.

Het is nog niet af, en er zullen wel verschrikkelijke fouten in zitten, maar misschien kan je er zelf wat ideen uit halen..

Ben ook wel benieuwd naar commentaar..

PHP:

Class mySession {
    
    var $usid; //unique session id
    var $csid; //client session id
    var $cmb;  //combined session id
        
    function login($uid, $pwd){
        if ($uid <> '') and if ($pwd <> ''){
            //read passwd file & check is combination exists
            
        }
        else
        {
            return false;
        }
    }
    
    function logout(){
        $_SESSION['sid'] == 'bogus';
    }
    
    function create_session() {
        $this->usid = md5(uniqid(rand(), true));
        $this->csid = md5($_SERVER["HTTP_USER_AGENT"]);
        $this->cmb  = md5($this->usid . $this->csid);
        $_SESSION['sid'] = $this->cmb;
    }
    
    function check_valid_session(){
        if ($_GET['sid'] == $this->cmb) {
            return true;
        }
        else
        {
            return false;
        }
    }
    
}

een link naar een beveiligde pagina wordt dan

PHP:

<?
echo '<a href="http://www.blaat.com/secure.php?sid=' . $_SESSION['sid'] . '">Klik hier voor de beveiligde pagina</a>';
?>

En in de beveiligde pagina:

PHP:

<?
include classes.php;
mySession = New mySession;
if (mySession->check_valid_session() == true) {
 //Geef secure pagina weer
}
else
{
  //geef foutmelding
}
?>

[Genoil]

Ik heb hier een scriptje liggen dat wel met PHP_AUTH_USER+PW werkt en dat geloof ik wel doet wat TS vraagt.

login.php

PHP:

<?
$users = array("root" => "r00t", "user" => "u53r");

session_start();

if(!isset($_SESSION['user']) || $_SERVER['PHP_AUTH_USER'] != $_SESSION['user']) {           
    if(isset($_SERVER['PHP_AUTH_USER']) && !isset($_SESSION['force401headers'])) {
        $result = isset($users[$_SERVER['PHP_AUTH_USER']]) && $users[$_SERVER['PHP_AUTH_USER']] = $_SERVER['PHP_AUTH_PW'];
    }
    else {
        $result = false;
    }
    if(!$result || !isset($_SERVER['PHP_AUTH_USER']) || isset($_SESSION['force401headers'])) {
        header('WWW-Authenticate: Basic realm="test"');
        header('HTTP/1.0 401 Unauthorized');
    }
    else {
        $_SESSION['user'] = $_SERVER['PHP_AUTH_USER'];
    }
    unset($_SESSION['force401headers']);
}
if(isset($_SESSION['user'])) {
    echo "<h1>Welcome, ".$_SESSION['user']."</h1>";
    echo "<h3><a href=\"logout.php\">Log out</a></h3>";
}
else {
    echo "<h1>HTTP/1.0 401 Unauthorized</h1>";
    echo "<h3><a href=\"login.php\">Log in</a></h3>";
}
?>

logout.php

PHP:

session_start();
unset($_SESSION['user']);
$_SESSION['force401headers'] = true;
header("Location:login.php");

[ Voor 45% gewijzigd door Genoil op 16-12-2005 13:57 ]

[frickY]

Joehoe, is mijn bericht onzichtbaar?
Doe nou maar eens ipv de PHP_AUITH_USER legen een header("Status: 401 Unauthorised"); geven.

[Erkens]

CyberJ schreef op vrijdag 16 december 2005 @ 13:23:
Ben ook wel benieuwd naar commentaar..

PHP:

    function create_session() {
        $this->usid = md5(uniqid(rand(), true));
        $this->csid = md5($_SERVER["HTTP_USER_AGENT"]);
        $this->cmb  = md5($this->usid . $this->csid);
        $_SESSION['sid'] = $this->cmb;
    }
}

waarom 2x md5'en
en waarom niet de session id's gebruiken die PHP standaard genereerd?

[Equator]

Erkens schreef op vrijdag 16 december 2005 @ 19:29:
[...]

waarom 2x md5'en
en waarom niet de session id's gebruiken die PHP standaard genereerd?

2x MD5 omdat ik dan slechts een 32bit sid krijg wat in mijn secure pagina's aan de url's wordt geplakt. Ik wilde die dus niet 64 caracters lang hebben.

En om heel eerlijk te zijn snapte ik niet hoe de session id's van PHP zelf werken dus vond ik het leuker om zelf iets te maken.. Iets wat ik wel begreep

[T-MOB]

CyberJ schreef op zaterdag 17 december 2005 @ 17:25:
[...]
2x MD5 omdat ik dan slechts een 32bit sid krijg wat in mijn secure pagina's aan de url's wordt geplakt. Ik wilde die dus niet 64 caracters lang hebben.

Ik denk dat Erkens bedoelde waarom 3x md5. Je kunt ook gewoon een keer md5 halen over een concat van een unique id en de referrer. De resulterende string is overigens 32 bytes, terwijl de hash zelf 128bits is.

En om heel eerlijk te zijn snapte ik niet hoe de session id's van PHP zelf werken dus vond ik het leuker om zelf iets te maken.. Iets wat ik wel begreep

PHP's sessionid's maken standaard gebruik van md5 (128bits, 32bytes hex) of sha1 (160bits, 40bytes hex). Welke gebruikt moet worden kun je instellen in je php.ini.

Verder krijg ik het idee dat je systeem gewoon draait op PHP's eigen sessiesysteem. Het enige wat het doet is een quasi-random waarde in die sessie opslaan en op elke pagina kijken of diezelfde waarde ook in get request wordt meegestuurd. Lijkt me niet echt zinvol daar je aan de hand van de data in de sessie al wist dat de user ingelogd was...

[Equator]

T-MOB schreef op zaterdag 17 december 2005 @ 18:00:
[...]

Ik denk dat Erkens bedoelde waarom 3x md5. Je kunt ook gewoon een keer md5 halen over een concat van een unique id en de referrer. De resulterende string is overigens 32 bytes, terwijl de hash zelf 128bits is.

True.. Is inderdaad 3 keer. De eerste keer genereert overigens al een unieke 32bytes string.. ik wilde er echter nog eens tukje client specifieks bij zetten.
En inderdaad is een md5 string 32 bytes, en de hash 128bit.. * Equator maakt typfoutje

[...]

PHP's sessionid's maken standaard gebruik van md5 (128bits, 32bytes hex) of sha1 (160bits, 40bytes hex). Welke gebruikt moet worden kun je instellen in je php.ini.

Verder krijg ik het idee dat je systeem gewoon draait op PHP's eigen sessiesysteem. Het enige wat het doet is een quasi-random waarde in die sessie opslaan en op elke pagina kijken of diezelfde waarde ook in get request wordt meegestuurd. Lijkt me niet echt zinvol daar je aan de hand van de data in de sessie al wist dat de user ingelogd was...

Oke: Dus als ik bij een correcte login een sessie creeer (create_session() ) en daarin een variabele opgeef ( $_SESSION['ingelogged'] = true ) dan is het voldoende om bij een secure pagina te achterhalen of $_SESSION['ingelogged'] true is of niet.

Of is het bestaan van een session al voldoende om te weten dat de sessie correct aanwezig is.

* Equator kijkt nog eens naar php.net/sessions

[eamelink]

Als je een session maakt, dan kan je in die sessie willekeurige variabelen opslaan. PHP stuurt vervolgens naar de gebruiker een cookie met het sessionID, of als de gebruiker geen cookies accepteert, kan php het sessionID transparant achter links hangen of in hidden formelementen stoppen.

Wanneer de gebruiker een volgende pagina opent, wordt het cookie of het sessionid via de querystring weer meegestuurd; weet php dat het die-en-die persoon weer is, en worden de variabelen gerestored, waarna ze weer in je script beschikbaar zijn.

In principe zijn php sessies redelijk veilig, en je kan in de php.ini meen ik nog wel wat dingen instellen om de veiligheid op te schroeven. Ook kan je zelf de veiligheid verhogen door bijvoorbeeld een ip-check in je script in te bouwen. Zet gewoon het ip in de sessie, en vergelijk dat met het ip dat de request doet. Dan heb je de mogelijkheden van het stelen van een sessionid al grotendeels beperkt.

Overigens vind ik het vreemd dat er niet standaard veel meer beveiligingsmogelijkheden zijn ingebouwd in php's sessiesysteem. Een per-user ip-check instelling zou bevoorbeeld best handig zijn .

[Erkens]

eamelink schreef op zaterdag 17 december 2005 @ 21:11:
Overigens vind ik het vreemd dat er niet standaard veel meer beveiligingsmogelijkheden zijn ingebouwd in php's sessiesysteem. Een per-user ip-check instelling zou bevoorbeeld best handig zijn .

Zo'n setting zou je niet system-wide willen hebben. Zeker niet omdat het niet gegarandeerd is dat een IP gedurende een sessie hetzelfde blijft. Bijvoorbeeld met bedrijven die een proxyserver hebben die de ene keer van die internetlijn gebruik maken en de andere keer van een andere lijn. (ja ik heb dergelijke constructies gezien)

Wat ik vaak zelf doe naast een IP check (ja ik spreek mezelf min of meer tegen ) is ook de user-agent string opslaan in de sessie, hierdoor moet je ook _die_ juist meegeven (niet 100% safe, maar dat krijg je toch nooit).

[frickY]

Ik maak altijd een 'signature' variabele, welke de md5 is van het IP en de user-agent. Dit om session-hijacking te voorkomen.

[Equator]

frickY schreef op zaterdag 17 december 2005 @ 22:50:
Ik maak altijd een 'signature' variabele, welke de md5 is van het IP en de user-agent. Dit om session-hijacking te voorkomen.

Maar controleer je die dan in elke beveiligde pagina?

Een functie om de sessie te controleren zou dan alleen maar hoeven te controleren of md5 hash van de agent string en het remote ip adres klopt met dat wat er inde session variable staat.
En als de session niet bestaat weet je dat die gebruiker niet is ingelogged.

Maar nu maken we het nog wat moeilijker.. Stel je wilt met rollen gaan werken.
Bijvoorbeeld:
1 ) Admin, mag werkelijk alles.
2 ) Operator, mag alleen wat bepaalde instellingen wijzigen.
3 ) Guest, mag alleen kijken

Zou je een dergelijke role ook mee kunnen geven in een session variable waar je op controleert bij het openen van een pagina. Of is dat te omzeilen..

[Erkens]

frickY schreef op zaterdag 17 december 2005 @ 22:50:
Ik maak altijd een 'signature' variabele, welke de md5 is van het IP en de user-agent. Dit om session-hijacking te voorkomen.

Waarom die moeite om dat te "md5-en", redelijk nutteloos als je het mij vraag

CyberJ schreef op zaterdag 17 december 2005 @ 23:14:
Zou je een dergelijke role ook mee kunnen geven in een session variable waar je op controleert bij het openen van een pagina. Of is dat te omzeilen..

je zou die role in de sessie kunnen zetten (nadat er ingelogt is natuurlijk) echter zelf doe ik dat niet om de simpele reden dat het bij mij meestal mogelijk is om realtime rechten te veranderen

[ Voor 44% gewijzigd door Erkens op 17-12-2005 23:33 ]