[PHP] Admin gedeelte beveiligen

[T1psY]

voor het ontwikkelen van een webwinkel kwam ik tegen het volgende probleem aan:
het administratiegedeelte. Hieruit wordt ook de stock beheerd, facturatie gedaan, kassa/bankrekening bijgehouden etc. Nu vroeg ik mij af hoe ik dit het best kon beveiligen.

Ofwel achter een PHP-login systeem en dan controleren of het wel degelijk de admin is die ingelogd is, hierbij denk ik aan MySQL Injection voorkomen, MD5 (of SHA1) versleuteling van wachtwoorden ed...

Of dmv .htaccess de gehele map "admin" beveiligen. Echter ik las ergens op internet dat dit ook te hacken was door rainbow tables? Weet niet in hoeverre de informatie klopt.

De shop zal beheerd kunnen worden door meer mensen, die zelf hun wachtwoord moetten kunnen wijzigen (hierdoor valt de optie .htaccess denk ik al af).

Wat zouden jullie mij aanraden?

[Lourini]

Met .htaccess kun je toch ook IP gebruiken ipv gebruiker/wachtwoord?

[T1psY]

Ja maar je zit met dynamic IP dus dit kan veranderen. die optie valt dus al af.

[Hipska]

Je kan met php toch bij een wachtwoord change toch gewoon dat nieuwe wachtwoord in je .htpasswd file laten schrijven?

[T1psY]

Ja dit had ik ondertussen ook al gevonden, maar dan moet je aangeven op welke regel. Kunnen de beheerders dan niet op 1 manier een andere gebruiker zijn wachtwoord zien ?

[Rmg]

T1psY schreef op donderdag 11 februari 2010 @ 18:49:
voor het ontwikkelen van een webwinkel kwam ik tegen het volgende probleem aan:
het administratiegedeelte. Hieruit wordt ook de stock beheerd, facturatie gedaan, kassa/bankrekening bijgehouden etc. Nu vroeg ik mij af hoe ik dit het best kon beveiligen.

Ofwel achter een PHP-login systeem en dan controleren of het wel degelijk de admin is die ingelogd is, hierbij denk ik aan MySQL Injection voorkomen, MD5 (of SHA1) versleuteling van wachtwoorden ed...

Of dmv .htaccess de gehele map "admin" beveiligen. Echter ik las ergens op internet dat dit ook te hacken was door rainbow tables? Weet niet in hoeverre de informatie klopt.

De shop zal beheerd kunnen worden door meer mensen, die zelf hun wachtwoord moetten kunnen wijzigen (hierdoor valt de optie .htaccess denk ik al af).

Wat zouden jullie mij aanraden?

rainbow tables zijn tables met daarin alle mogelijke wachtwoord combinaties en hun hashes, dus als je .htpasswd file op straat ligt dan zijn je wachtwoorden zo terug te halen, idem met een database die op straat ligt.

in principe is basic http auth alleen te bruteforcen zolang je het op een juiste manier gebruikt ( .htpasswd buiten de webroot zetten om maar iets te noemen )

[T1psY]

dus ik heb een map, met daarin de webshop (de 'root' van de website) met daarin een submap /admin.
In deze map 'admin' zet ik een .htaccess en een .htpasswd met de log-in gegevens.
is dit een goede beveiliging voor de admin-gedeelte van de website dan ?

[Rmg]

T1psY schreef op donderdag 11 februari 2010 @ 19:07:
dus ik heb een map, met daarin de webshop (de 'root' van de website) met daarin een submap /admin.
In deze map 'admin' zet ik een .htaccess en een .htpasswd met de log-in gegevens.
is dit een goede beveiliging voor de admin-gedeelte van de website dan ?

nee want de htpasswd moet buiten de webroot in /home/<domein>/passwords bijvoorbeeld iig niet op een plek die vanaf het internet te bereiken is

[Precision]

Als home/[username]/public_html de map is waar je alles plaatst (de 'root' van de website, zoals je het zelf noemt), dan zit je admin in home/[username]/public_html/admin Je zou het beter zo doen: home/[username]/private of home/[username]/passwords je snapt het principe wel, gewoon niet publiekelijk maken, zodat het onder geen bedding gedownload kan worden.
- edit: te laat

[MueR]

T1psY schreef op donderdag 11 februari 2010 @ 18:49:
Ofwel achter een PHP-login systeem en dan controleren of het wel degelijk de admin is die ingelogd is, hierbij denk ik aan MySQL Injection voorkomen, MD5 (of SHA1) versleuteling van wachtwoorden ed...

Of dmv .htaccess de gehele map "admin" beveiligen. Echter ik las ergens op internet dat dit ook te hacken was

Waarom niet beiden? Een algemene HTTP authentication, plus een user-based login. De kans dat iemand allebei weet te hacken is verwaarloosbaar. Zeker als je ook financiele gegevens daar in hebt staan is dat aan te raden. En ja, alles is te hacken met heel veel tijd en resources.

[ Voor 8% gewijzigd door MueR op 11-02-2010 19:48 ]

[Verwijderd]

Ik zou misschien ook sha512(misschien overkill, maja) gebruiken. Met een key in het midden. Dus zoiets:

code:

<?php
$key = 'blaat';
$passwd = hash('sha512',$beginpass.$key.$eindpass);
?>

[Reddol]

En de key kan je natuurlijk ook nog MD5 laten hashen ofzo. Zo zijn de wachtwoorden niet te achterhalen. Ook niet met een rainbow table. (Lijkt mij hè),

De key moet je wel op letten dan, deze moet altijd hetzelfde blijven

[Verwijderd]

T1psY schreef op donderdag 11 februari 2010 @ 18:53:
Ja maar je zit met dynamic IP dus dit kan veranderen. die optie valt dus al af.

En als je nou een hostnaam gebruikt middels dyndns.org of iets dergelijks?

[Verwijderd]

- Gebruik HTTPS
- Zet rechten op de mysql user, zodat deze bijvoorbeeld niet iemand zijn password kan wijzigen of een extra user aan kan maken
- De kans dat jij een target zal vormen, zal erg klein zijn. Anders ga je ook niet op een shared hosting zitten (gokje)
- Gebruik een one-time password, ook bekend van internetbankieren (zie bijvoorbeeld WiKiD, je hebt wel een 2e server nodig voor gegarandeerde veiligheid)
- Zorg voor goede rechten op de bestanden met bijv. chmod en chown

[T1psY]

wat bedoel je met op shared hosting zitten? De bedoeling is dat we voor de webshop een dedicated server gaan installeren. Hier zal ook wel hosting op gebeuren van andere websites, die wel door ons beheerd zijn. De "eigenaar" van die website kan zijn website dan bewerken in een door ons gescript CMS.

[Rmg]

Reddol schreef op donderdag 11 februari 2010 @ 20:28:
En de key kan je natuurlijk ook nog MD5 laten hashen ofzo. Zo zijn de wachtwoorden niet te achterhalen. Ook niet met een rainbow table. (Lijkt mij hè),

De key moet je wel op letten dan, deze moet altijd hetzelfde blijven

Dubbel hashen vergroot vaak alleen maar de kans op collisions

[YopY]

Als beveiliging zo'n belangrijk punt is, zou je dan niet liever overwegen om een investering te doen in een commerciële webshop applicatie, danwel een goed uitontwikkeld (eventueel OSS) systeem te gebruiken? Zorg er in ieder geval voor dat je het jezelf niet te moeilijk maakt, en onthoudt dat er maar één zwakke plek in je systeem hoeft te zitten om het helemaal open te breken.

.htpasswd en een user login systeem (die je niet te complex maakt als het even kan - hoe meer features, hoe groter de kans op fouten / lekken) zouden anders genoeg moeten zijn. Zorg er wel voor dat je eerst wat informatie binnenhaalt over session management (koppel een sessie aan het IP van een gebruiker, bijvoorbeeld, zodat het session cookie wel gestolen kan worden, maar niks uitmaakt voor de beveiliging), hashing / salting van wachtwoorden (MD5 is daar te zwak voor, overigens), en natuurlijk de vraag wie je toegang geeft en wie niet.

Maar .htpasswd voldoet ook voor de meeste zaken. En dat is redelijk eenvoudig in te stellen.

[Soultaker]

Een late reactie, maar wat Raz- zegt klopt niet.

Raz- schreef op donderdag 11 februari 2010 @ 19:01:
rainbow tables zijn tables met daarin alle mogelijke wachtwoord combinaties en hun hashes, dus als je .htpasswd file op straat ligt dan zijn je wachtwoorden zo terug te halen, idem met een database die op straat ligt.

Apache's htpasswd files gebruiken salted hashes (zoals het ook hoort) dus die zijn niet gevoelig voor een aanval met rainbow tables. Overigens hou je die bestanden voor de zekerheid wel geheim natuurlijk, want een dictionary attack werkt nog steeds als je zwakke wachtwoorden gebruikt.

Raz- schreef op donderdag 11 februari 2010 @ 19:35:
nee want de htpasswd moet buiten de webroot in /home/<domein>/passwords bijvoorbeeld iig niet op een plek die vanaf het internet te bereiken is.

Standaard blokkeert Apache de toegang tot bestanden die beginnen met .ht (dus .htaccess en .htpasswd en dergelijke) dus ook als je die binnen de webroot zou plaatsen, dan kan men er nog niet van buiten bij. Je kunt dat ook eenvoudig testen. Deze setup is dus prima.

Overigens zou ik in principe wel aanraden om digest authentication te gebruiken in plaats van basic authentication. Alle gangbare browsers ondersteunen dat tegenwoordig, en het verschil tussen de twee methoden is dat bij digest authentication het wachtwoord niet plain-text verstuurd wordt. Wanneer een gebruiker via HTTP (in plaats van HTTPS) verbind over het internet zou bij basic authentication het wachtwoord afgeluisterd kunnen worden.

[bindsa]

Als je de rechten van MySQL goed regelt, dan is een gesalt sha1 wachtwoord meer dan voldoende. Inloggen ook nog eens regelen met .htpasswd lijkt mij een beetje overkill. Zolang je een goede input check en het liefst parametrized query gebruikt is MySQL gewoon heel veilig en hoef je ook niet te vrezen voor SQL injecties.

[Rmg]

Soultaker schreef op dinsdag 16 februari 2010 @ 17:29:
Een late reactie, maar wat Raz- zegt klopt niet.

[...]

Apache's htpasswd files gebruiken salted hashes (zoals het ook hoort) dus die zijn niet gevoelig voor een aanval met rainbow tables. Overigens hou je die bestanden voor de zekerheid wel geheim natuurlijk, want een dictionary attack werkt nog steeds als je zwakke wachtwoorden gebruikt.

ok ok sinds 2.1 gebruikt het ook voor md5 salted hashes in 2.0 wordt daar nog geen woord over gerept en gebruiken ze daar ongesalte hashes, wel een specifieke md5 versie voor apache maar daar zijn ook tables voor te krijgen.

Standaard blokkeert Apache de toegang tot bestanden die beginnen met .ht (dus .htaccess en .htpasswd en dergelijke) dus ook als je die binnen de webroot zou plaatsen, dan kan men er nog niet van buiten bij. Je kunt dat ook eenvoudig testen. Deze setup is dus prima.

http://httpd.apache.org/docs/2.3/programs/htpasswd.html

Security Considerations

Web password files such as those managed by htpasswd should not be within the Web server's URI space -- that is, they should not be fetchable with a browser.

best practice > werkt prima

[Verwijderd]

Ik raad je aan om FreeBSD als OS te gebruiken op een dedi server. Met FreeBSD kan je jails aanmaken (geen full, maar Wikipedia: Operating system-level virtualization). Zet bijvoorbeeld de admin in een aparte jail, de frontend in een aparte jail en mysql in een aparte jail. Zet de juiste rechten per ipadres/user in mysql en je hebt een redelijk goede beveiliging.

De andere websites zet je dan ook in een andere jail met eventueel een eigen mysql server .

Alternatieven zijn natuurlijk te vinden: KVM (linux), Xen, zie wikipedia.

[Soultaker]

Raz- schreef op dinsdag 16 februari 2010 @ 20:17:
best practice > werkt prima

Natuurlijk werkt dat prima, dat bestrijd ik niet. Maar toen T1psY vroeg of zijn setup goed was, antwoordde jij met "nee want de htpasswd moet buiten de webroot [..] iig niet op een plek die vanaf het internet te bereiken is".

Dat is onzin, want zoals ik aangaf hoeft die .htpasswd file niet buiten de webroot, want hij ís (standaard) niet vanaf het internet te bereiken. Met de voorgestelde setup was dus niets mis, en je antwoord had ja moeten zijn. Verder even goede vrienden hoor.

Verwijderd schreef op dinsdag 16 februari 2010 @ 20:45:
Ik raad je aan om FreeBSD als OS te gebruiken op een dedi server. Met FreeBSD kan je jails aanmaken [..]

FreeBSD jails zijn zeker mooi, maar dit lijkt me overkill. De TS wil gewoon authenticatie geregeld hebben, en dat kan ook zonder jails prima. Verder kan een jail wel bijdragen aan de algemene veiligheid van het systeem, maar het concrete probleem van de TS wordt er niet mee opgelost.

[ Voor 27% gewijzigd door Soultaker op 16-02-2010 22:15 ]

[Rmg]

Soultaker schreef op dinsdag 16 februari 2010 @ 22:12:
[...]

Natuurlijk werkt dat prima, dat bestrijd ik niet. Maar toen T1psY vroeg of zijn setup goed was, antwoordde jij met "nee want de htpasswd moet buiten de webroot [..] iig niet op een plek die vanaf het internet te bereiken is".

Dat is onzin, want zoals ik aangaf hoeft die .htpasswd file niet buiten de webroot, want hij ís (standaard) niet vanaf het internet te bereiken. Met de voorgestelde setup was dus niets mis, en je antwoord had ja moeten zijn. Verder even goede vrienden hoor.


[...]

ok ok, Het werkt maar het wordt aangeraden,door o.a. de apache docs, om je htpassd files buiten je webroot te zetten. Dit voegt wat veiligheid toe wat extra belangrijk kan zijn op shared servers waarvan je de configuratie niet zelf beheert

[DiedX]

Mannemanneman, wat een adviezen voor een webshop...

1 advies vond ik echt goed: waarom programmeer je de shop zelf?

Verder:

* Wie heeft de dedicated server in beheer? Heeft hij/zij daar ervaring mee?
* Backup, backup, backup...
* Over hoeveel omzet hebben we het nu? Tientjes? Hondertjes? Tonnetjes? Dit bepaald in hoeverre je gewilt bent als een target
* Waarom geen VPN? OpenVPN met een certificaat kom je een heel end mee...
* Waarom geen certificaat gebaseerde htaccess?

Edit; OpenVPN gaat hier niets toevoegen. Je komt uit op dezelfde webserver met dezelfde programmeurs. Dan kan je beter zeker weten dat de gebruiker is die je denkt wie het is. OpenVPN gaat daarbij niet helpen, maar maakt het lastiger... Though: certificaten for the win!

[ Voor 28% gewijzigd door DiedX op 16-02-2010 23:42 . Reden: Zie edit ;) ]

[Brantje]

Heb je dit ook al gezien?

[DexterDee]

Afgezien van het algoritme van hashing bij het inloggen en bovenstaande tips nog twee extra tips om het veiliger te maken:

- Login throttling / limiting. Zorg ervoor dat een IP adres maar X pogingen heeft om in te loggen en als dit niet lukt zet je dat IP adres voor Y minuten op een blacklist. Simpel en effectief tegen dictionary attacks.

- Session hijacking. Controleer de sessie of deze nog van hetzelfde IP adres afkomt. Verder kun je een hash vergelijken van verschillende CGI variabelen waarvan je weet dat deze niet veranderen (zoals de user agent). Indien je inconsistenties aantreft, invalidate je de sessie en forceer je de user om opnieuw in te loggen.

[DiedX]

DexterDee schreef op woensdag 17 februari 2010 @ 12:21:
- Login throttling / limiting. Zorg ervoor dat een IP adres maar X pogingen heeft om in te loggen en als dit niet lukt zet je dat IP adres voor Y minuten op een blacklist. Simpel en effectief tegen dictionary attacks.

Sorry, maar hierin ga ik niet mee. Met een botnet van een paar miljoen heb ik genoeg unieke IP-Adressen om een bruteforce te doen waar ik onder je radar vlieg. Kom ik toch weer terug op de certificaten

[DexterDee]

DiedX schreef op woensdag 17 februari 2010 @ 13:28:
[...]

Sorry, maar hierin ga ik niet mee. Met een botnet van een paar miljoen heb ik genoeg unieke IP-Adressen om een bruteforce te doen waar ik onder je radar vlieg. Kom ik toch weer terug op de certificaten

Sorry, maar daarin ga ik weer niet mee. Certificaten vormen een uitstekende bescherming, maar het gaat hier om risk vs. reward. We hebben het hier niet over een server met uiterst geheime staatsdocumenten. Certificaten moet je genereren, uitdelen en installeren op je lokale PC. Daar kleeft dus een hele administratie aan vast. Bovendien kun je op andere PC's geen gebruik meer maken van de website, tenzij je je certificaat ergens neerzet en de kennis (en mogelijkheden) hebt om deze te installeren.

Komen we terug op je botnet. Met een password policy van minimaal 6 tekens, waarvan 1 hoofdletter en 1 cijfer kom je uit op een dikke 56 miljard mogelijke combinaties. En dat is alleen maar het password. Mocht je de username nog erbij willen bruteforcen dan is het een hopeloze zaak. Een botnet van 100.000 PC's wordt al gezien als groot, maar een botnet met letterlijk miljoenen drones, daar kunnen maar enkelen op deze aardbol over beschikken. Bovendien leven die dingen niet bijzonder lang. Om "onder de radar" te vliegen kun je de webserver niet teveel belasten. Met miljoenen drones moet je juist uitkijken dat je niet meteen onbedoeld een DDOS uitvoert als je de boel aanzet. Met het juiste tempo om "onder de radar" te blijven ben je dus jaren bezig om een match te vinden. Niet erg praktisch en ook verre van realistisch.

Login throttling is simpel te implementeren in een paar uurtjes en houdt verreweg de meeste hackers en scriptkiddies tegen.

[DiedX]

DexterDee schreef op woensdag 17 februari 2010 @ 14:45:
[...]

Sorry, maar daarin ga ik weer niet mee. Certificaten vormen een uitstekende bescherming, maar het gaat hier om risk vs. reward.

Het goed implementeren van een CA (waarschijnlijk heb je die ook in webformulier-vorm) kost je een dagje. Ik zie het probleem niet? (Edit): http://freshmeat.net/projects/catool/

Qua usernames heb je gelijk, maar daar valt redelijk snel achter te komen. LinkedIn zoeken op de webshopnaam, en daar de werknemers van pakken. $$$

[ Voor 4% gewijzigd door DiedX op 17-02-2010 15:02 . Reden: CATool toegevoegd ]