[PHP] PHP-based auth --> $PHP_AUTH_PW plain text

[hamsteg]

Voor een bepaalde website gebruiken wij PHP-based authentication. Toen ik nog wat aan het uitzoeken was, zag ik in de $_SERVER variabelen ineens mijn password in plain text ($PHP_AUTH_PW). Is dit niet een potentiële security risk? Waarom wordt deze niet ge-encrypt door PHP? (vanuitgaande dat alles over een veilige lijn gaat)

Huidige implementatie bevat de volgende check:

PHP:

...
$enc_pw = crypt( $PHP_AUTH_PW, $salt ); 
if ( $password == "$enc_pw" )
{
...

door een ge-encrypte tussenvariabele met het password uit de .htaccess file wordt vergeleken. Volgens mij is het veiliger om:

PHP:

...
$PHP_AUTH_PW = crypt( $PHP_AUTH_PW, $salt );
$PHP_AUTH_ENC="crypt";
if ( $password == "$PHP_AUTH_PW" )
...

Is dit geen security leak? Kan echt niemand ooit bij deze variabele komen?

[DexterDee]

In principe kan niemand de $_SERVER variabele uitlezen, omdat deze variabele alleen bestaat in de scope van je webrequest. In uitzonderlijke gevallen is deze wel te onderscheppen, omdat de browser bij basic authentication het wachtwoord in cleartext steeds weer meegeeft. Als iemand dus arbitraire PHP code zou kunnen injecteren en uitvoeren, dan kan iets als print_r( $_SERVER ); het wachtwoord ontrafelen.

Een groter probleem bij basic authentication is een man-in-the-middle attack, omdat bij elk request de combinatie van username + password doorgegeven wordt. Deze is dus onderweg te onderscheppen omdat het in cleartext over de lijn gestuurd wordt bij elke webrequest in dezelfde realm.

Een oplossing voor beide problemen zou digest authentication kunnen zijn, een meer secure variant van basic authentication waarbij het password encrypted wordt door een random salt die de server genereert. Er zijn PHP classes die dit helemaal voor je afhandelen. Google is your friend

[hamsteg]

Ben al een paar uur aan het google'n en kom er steeds meer achter dat de $PHP_AUTH_ variabelen een regelrechte ramp zijn bij PHP-based authentication. Ten eerste is alles plain text, ten tweede kun je de browser ( die bij pagina access de $PHP_AUTH_ opnieuw aanbieden ) niet de $PHP_AUTH_ laten invallideren (gebrek in de standaard). Door het opnieuw activeren van de authentication kun je alles wel laten invallideren maar dan krijg je ook weer die pop-up voor je.

Digest authentication is ook nog geen wahalla ... support en implementatie (IE versus rest) maken het ook niet leuk.

Uiteindelijk zal ik zelf wel weer een pagina in elkaar zetten met password protection over https...misschien een java-applet/script om de data even te encrypten bij niet https en daardoor browser compatible is.

Toch jammer dat er niet een standaard methode is ....

[Gomez12]

hamsteggot schreef op woensdag 14 juni 2006 @ 23:41:
Ben al een paar uur aan het google'n en kom er steeds meer achter dat de $PHP_AUTH_ variabelen een regelrechte ramp zijn bij PHP-based authentication. Ten eerste is alles plain text,

Dit plain text gedeelte is puur en alleen maar omdat php het als plain text aangeboden krijgt van de webserver, dit zegt niets over hoe het over de lijn is gegaan hoor ( vb SSL stuurt het encrypted over de lijn tussen client en webserver, maar tussen webserver en php is het weer plain text ) , anders kan je altijd nog SSL gebruiken, javascript bij de client het laten encoderen/ hashen met een salt die afkomstig is van je php.

ten tweede kun je de browser ( die bij pagina access de $PHP_AUTH_ opnieuw aanbieden ) niet de $PHP_AUTH_ laten invallideren (gebrek in de standaard). Door het opnieuw activeren van de authentication kun je alles wel laten invallideren maar dan krijg je ook weer die pop-up voor je.

Mijn oude methode was gewoon redirect de gebruiker naar http://dummyuser:[e-mail] en zorg er in php voor dat dummyuser gewoon een uitgelogde gebruiker is en geen popup krijgt. Maar ik meen me te herinneren dat hier ooit eens een update voor IE voor is geweest wat dit weer tegenhield ( username en password meesturen in de url ) maar misschien dat je er nog iets aan hebt.

Digest authentication is ook nog geen wahalla ... support en implementatie (IE versus rest) maken het ook niet leuk.

Uiteindelijk zal ik zelf wel weer een pagina in elkaar zetten met password protection over https...misschien een java-applet/script om de data even te encrypten bij niet https en daardoor browser compatible is.

Toch jammer dat er niet een standaard methode is ....

Digest authentication is een redelijke ramp inderdaad.
Javascript heeft als groot nadeel dat als het niet goed geimplementeerd is ( challenge-response ) het zo te reverse engineeren is waardoor je het net zo goed plain text kan versturen.
Https biedt geen beveiliging voor $[server] in php zie eerder
Java heeft niet iedereen geinstalleerd staan.

Standaard methode is er wel : basic authentication, alleen heeft deze wat nadelen met uitloggen etc.

Voor je zelf iets gaat verzinnen zou ik trouwens eerst eens goed kijken of er niet een standaard script is op pear / hotscripts / weet ik veel waar want tegenwoordig hebben toch heel veel websites authenticatie methoden en is het toch wel redelijk standaard. En om dit soort dingen echt waterdicht te krijgen vereist toch wel een redelijk stuk kennis, en bij 1 gat heb je al niets aan je hele rest-beveiliging.

Vraagje : Waarom moet het systeem zo waterdicht zijn? Want plain text wachtwoorden over de lijn zijn alleen te onderscheppen met man in the middle attacks ( voorzie ik alleen grote problemen mee met bank-programmas, voor de rest vind ik man in the middle attacks te veel moeite tegen te weinig opbrengst )
En het probleem wat jij nu stelt is alleen tussen webserver en php. Over het client-webserver traject zeg je niks.

Mijn werkwijze zou zijn : 5 min zoeken op pear / hotscripts naar een authenticatie script. Even code doorlezen of de code wel defensief genoeg geschreven is. Dan nog even zoeken of er niet een algemene exploit bekend is voor deze authenticatie methode. Daarna even checken met ethereal/cookies of er niet iets plain text over de lijn heengaat.
Dan heb ik binnen ongeveer een uur een script wat alleen nog maar geimplementeerd hoeft te worden.
Terwijl als ik het zelf moest schrijven ik eerst op zoek moest gaan naar alle implementaties voor alle browsers, daarna zoeken naar wat de handigste manier is, daarna code schrijven, daarna ethereal / cookies controleren en daarna hopen dat ik alle uitzonderingen te pakken heb.
Toch al snel een uur of 4 tegenover 1.

[hamsteg]

Gomez12 schreef op donderdag 15 juni 2006 @ 01:35:
Digest authentication is een redelijke ramp inderdaad.
Javascript heeft als groot nadeel dat als het niet goed geimplementeerd is ( challenge-response ) het zo te reverse engineeren is waardoor je het net zo goed plain text kan versturen.
Https biedt geen beveiliging voor $[server] in php zie eerder
Java heeft niet iedereen geinstalleerd staan.

Standaard methode is er wel : basic authentication, alleen heeft deze wat nadelen met uitloggen etc.

Voor je zelf iets gaat verzinnen zou ... aan je hele rest-beveiliging.

Vraagje : Waarom moet het systeem zo waterdicht zijn?
Mijn werkwijze zou zijn : 5 min zoeken op pear / hotscripts naar een authenticatie script.
Terwijl als ik het zelf moest schrijven ik eerst op zoek moest gaan naar alle implementaties voor alle browsers, daarna zoeken naar wat de handigste manier is, daarna code schrijven, daarna ethereal / cookies controleren en daarna hopen dat ik alle uitzonderingen te pakken heb.

Binnen ons bedrijf met een kudde aan techneuten was het het idee om PHP open te zetten (intern). Veel data staat in dBases en PHP biedt een aantal mogelijkheden die we niet meer kunnen onthouden.

Door toevallig testen in dit gebied zag ik daar mijn password in plain text voorbij komen. Een vriendelijke gast hoeft alleen maar een PHP script te maken die deze info logt en alle PC's af te gaan. Doordat je geen uitlog mogelijkheid hebt vervalt de verantwoording van de gebruiker. Vandaar de oorspronkelijke vraag over de $PHP_AUTH_... Dat er vervolgens een beerput open ging en dat ook blijkt dat met eenvoudige sniffers je zelfs de password zo kunt uitlezen maakt het er niet veel veiliger op. Binnen vier uur ontdek ik een gat intern en extern ... een slechte dag Voorlopig gaan we naar https met eigen password pagina voor verificatie, op de server post data encypten en dan in een session variabele zetten die ook ge-unset kan worden (=logout). Programmeer technisch een uurtje werk. ... en is al klaar.

Op het tweede plan, voor http access (ja een aantal kan/wil niet anders en voorlopig hebben ze al pech zat en zijn ze geblokkeerd ), zullen we gaan kijken naar de password pagina of de data die verstuurd gaat worden (on_submit) niet even MD5 kan krijgen. MD5 is een one way encrypter en maakt het bijna onmogelijk om het oorspronkelijke password te genereren. De script code mag iedereen zien (en is open source), de oorspronkelijke data krijg je niet terug door reverse engineering. Als deze manier zou werken zijn we browser onafhankelijk en dat zou fijn zijn.

Conclusie 1: ik snap nu waarom de postbank site elke keer die java-applet laadt
Conclusie 2: Degenen die de standaard verzinnen hebben toch echt een steekje los zitten. Data onveilig over de lijn, onveilig in geheugen opslaan, data bij elk request mee sturen en data niet kunnen invalideren. Elke boek over beveiliging heeft voor deze vier punten richtlijnen ...

[hamsteg]

MD5 protectie ben ik ook uit ... alles is te googlen alleen moet je het nog aan elkaar plakken. Voor de geinteresseerden, sorry maar in Engels:

• onsubmit MD5 protection and server handling abstract level [ENG]
• Plain text login script, code explained in detail [ENG]

[DexterDee]

hamsteggot schreef op donderdag 15 juni 2006 @ 10:18:
MD5 protectie ben ik ook uit ... alles is te googlen alleen moet je het nog aan elkaar plakken. Voor de geinteresseerden, sorry maar in Engels:

• onsubmit MD5 protection and server handling abstract level [ENG]
• Plain text login script, code explained in detail [ENG]

Recente ontwikkelingen met betrekking op rainbow table cracks laten zien dat het vinden van een collision op een MD5 hash ook niet heel moeilijk is. Als je dan toch optimaal beveiligd wilt zijn, gebruik dan een SHA1 hash. Deze heeft een grotere hash en het is veel complexer om hier een collision van uit te rekenen. De javascript implementatie van SHA1 is hier te vinden:
http://pajhome.org.uk/crypt/md5/index.html

[hamsteg]

Had ik ook gezien maar (zie zelfde artikel zelfs):

Het gebruik van MD5 of SHA-1/2 voor de meeste JavaScript toepassingen (login) zal geen last hebben van "collision resistance property". Deze zwakte in het algoritme is geen kwetsbaarheid is deze web sites en er is geen reden tot paniek.

---

The use of MD5 or SHA-1 for most JavaScript purposes (e.g. challenge-response login) does not rely on the collision resistance property. These weaknesses do not create any vulnerability in such web sites and there is no need to panic.

gebruik daarom naast een fixed hash (je passwd file) ook 1 of meerdere random hashes met een beperkte levensduur. Elke encryptie is te breken ... de vraag is hoelang het duurt. Bij enkelvoudige MD5 kan men een hit hebben binnen een minuut ... maak een dubblele of drievoudige MD5 en men is wel even zoet.

[DexterDee]

hamsteggot schreef op donderdag 15 juni 2006 @ 12:21:
gebruik daarom naast een fixed hash (je passwd file) ook 1 of meerdere random hashes met een beperkte levensduur. Elke encryptie is te breken ... de vraag is hoelang het duurt. Bij enkelvoudige MD5 kan men een hit hebben binnen een minuut ... maak een dubblele of drievoudige MD5 en men is wel even zoet.

dubbele of drievoudige hash is inderdaad slim om te doen, evenals een server side salt met een beperkte levensduur

Ik denk toch dat SHA1 in dit geval (net iets) beter is dan MD5, omdat het minder 'populair' is, het een grotere hash oplevert, de functie al beschikbaar is en ruwweg even snel is als de MD5 functie. Het is gewoon een kwestie van de MD5 functieaanroep door die van SHA1 te vervangen. Het is niet dat je er veel meer extra werk mee op je hals haalt om net iets beter beveiligd te zijn.