[PHP] Een veilige login maken

[Bylie]

Hoi,

Ja ik heb gezocht maar vindt alleen maar stukken die ik kan gebruiken.
Ik heb dus een vraag over het maken van een veilige login mbv php, mysql, sessies en cookies. Ik ben op zoek naar het principe dus code vraag ik niet, mag altijd natuurlijk maar dit wil ik toch zelf doen.

Situatie :
Ik moet een loginsysteem maken voor een site, dat later uitgebreid kan worden naar forum login (dit even terzijde), en het moet toch een beetje veilig zijn.
Met login bedoel ik eigenlijk zoiets als op tweakers, dus je logt in kan evt wat prefs van je acount veranderen EN je bent de volgende keer automatisch ingelogd als je de site nog eens bezoekt.

Mijn oplossing :
Als een user de website bezoekt (hij heeft zich al gerigistreerd) dan zal hij moeten inloggen. Hij vult dus zijn username + pass in en stuurt deze naar de webserver. De webserver gaat dan kijken in de database of de combinatie username/pass 1 record opleverd, is dit zo dan gaat de webserver een unieke key maken (bv combinatie van username + pass + iets random => md5). Die key wordt dan in de DB bij de user opgeslagen en wordt naar een cookie geschreven op de pc van de user. De volgende keer als de user dan de website bezoekt zal er gecontroleerd worden of er een cookie bestaat en als dit zo is wordt er gekeken welke key er in het cookie staat en bij welke username deze hoort. Resultaat de user wordt automatisch ingelogd.

Dit is zo een beetje wat ik al kon verzinnen, alle opmerkingen en aanpassingen zijn welkom want er zullen best wel dingen zijn die over het hoofd zie.

Thx

[Verwijderd]

ACM heeft over dit specifieke onderdeel een mooie faq geschreven..

[Bylie]

Heb ik juist eens bekeken maar, zover ik kan zien, staat er niet echt een principe in beschreven van een "ideale" login als zoiets al bestaat.

[Kaastosti]

Jouw idee lijkt heel erg veel op wat ik ook op mijn site(s) gebruik. Een md5 hash maken van username + pass + random is in ieder geval een goed idee. Lijkt mij in ieder geval een vrij waterdicht systeem zo

Mijn site waar ik dat ook gebruik

[Verwijderd]

Bylie schreef op 12 februari 2003 @ 23:02:
Heb ik juist eens bekeken maar, zover ik kan zien, staat er niet echt een principe in beschreven van een "ideale" login als zoiets al bestaat.

Lees jou code nog eens goed door: dit is dus echt onveilig, je stuurt de geheime code ongeencrypt over het net, iemand hoeft alleen maar die code te sniffen en dat in een cookie te zetten en is binnen...

overigens gaat je username/pw ook al ongencrypt naar de site...

Als je het echt veilig wilt doen sla je natuurlijk nooit info op op de computer van de gebruiker ... Je moet de computer altijd aan de hand van een cookie kunnen indentificeren, jat je dat cookie kun je je voordoen als iemand anders...

beter kun je dus ook md5 toepassen op alle info die je over stuurt...

de secret key laat je client en serverside genereren, maar op de server gooi je er nog een keer md5 overheen.

vervolgens doe je clientside er iedere keer md5 over heen wanneer de inhoud van de sectretkey uit het cookie dus verzonden meot worden...

[Kaastosti]

Als je het echt veilig wilt doen sla je natuurlijk nooit info op op de computer van de gebruiker ... Je moet de computer altijd aan de hand van een cookie kunnen indentificeren

Een cookie info op de computer van de gebruiker... je zal toch op een manier een gebruiker moeten id-en. De enige manier is laten inloggen en een cookie plaatsen.

[Verwijderd]

Kaastosti schreef op 12 februari 2003 @ 23:15:
[...]
Een cookie info op de computer van de gebruiker... je zal toch op een manier een gebruiker moeten id-en. De enige manier is laten inloggen en een cookie plaatsen.

maar doe dan wel met md5

[Bylie]

Tja de veiligheidsgaten die ik zie :

- De username en pass wordt idd via een form gepost naar de server, maar om clientside iets te encrypten? Je kan toch altijd de source zien?
- Je werkt met een key (hash van username + pass + random iets) die in een cookie gezet wordt en in de db bij een bepaalde user. Een cookie kan natuurlijk gewijzigd worden, dus er kan een andere key geprobeerd worden. Maar dit lijkt mij ongeveer hetzelfde als paswoordje raden, niet echt tegen te houden dus.

[Verwijderd]

Altijd handig om bij mensen met een vast ip een ipcheck in te bouwen. Is het weer wat veiliger. Maar helemaal veilig kan het gewoon nooit.

[tech-no-logical]

mijn ideale login (even snel, misschien brengt 't je op een idee) :
basic of digest http-authenticatie via webserver en db, dit alles over https. in php de username uitlezen via server-environment, als dat al belangrijk is (bijvoorbeeld bij role-based applicaties).

[Explore]

Ik heb een dergelijk topic een tijdje geleden ook al geopend, zie hier. Ik maak gebruik van een andere methode, al heeft het systeem wel raakvlakken... Lees dat topic nog maar eens.

[Soultaker]

Dit is weer zo'n typische PHP-programmeurs-willen-moeilijk-doen topic (NOFI). In de search zijn al tientallen topics te vinden, waarin inlogsystemen besproken worden. De enige zinnige samenvatting die ik daarvan kan geven, is:

• Gebruik een PHP sessie (en dus geen cookie) om gegevens in op te slaan, zodat er geen gevoelige gegevens naar de client gestuurd worden

• Sla, in verband met privacy, bij voorkeur geen wachtwoorden op in je database, maar een gehashte variant ervan (MySQL PASSWORD() function, of gewoon md5() in PHP). Voor authorisatie is dit meer dan genoeg; vergeten wachtwoorden kunnen niet teruggevonden worden, maar een wachtwoord kan wel altijd gereset worden.

• Doe GEEN moeite om packet sniffen, IP spoofing en andere methoden tegen te gaan! Tenzij je een webbased lanceerinstallatie voor nucleaire intercontinentale raketten aan het bouwen bent, loont het NIET de moeite!

Alle onzin die nu al langskomt over md5 hashes berekenen van combinaties van inloggegevens en sessie id's, is verspilde moeite. Het is niet of nauwelijks veiliger! Begin er dus gewoon niet aan. In een typische situatie is het vele malen eenvoudiger om een netwerk of key logger (al dan niet hardwarematig) op de PC in kwestie te installeren, dan om op een andere wijze het inlogsystem te "hacken". Daarbij is het zeer onwaarschijnlijk dat iemand het de moeite waard vind.

Overigens is tech-no-logical's oplossing ook erg geschikt. Als je zelf je webserver beheert, of de mogelijkheid hebt om gebruik te maken van HTTPS met gebruikersauthenticatie, dan kun je die zeker overwegen. Denk er wel aan dat je dan eigenlijk een 'officieel' certificaat wil hebben (dat door een 'betrouwbare' partij zoals bijvoorbeeld Verisign of Thawte uitgegeven en gegarandeerd wordt) en dat is doorgaans niet gratis. De uiteindelijke oplossing is wel heel erg veilig, vooral tegen het onderscheppen van netwerk verkeer. Tegen key loggers of andere dingen doe je natuurlijk niets.

[ Voor 25% gewijzigd door Soultaker op 13-02-2003 14:59 ]

[TheDane]

wat ik niet snap wat iedereen altijd roept

sla geen wachtwoorden (plain-text) op in je database

waarom niet !?

Als iemand zo goed is om in je database te komen om 't wachtwoord te achterhalen, dan kan ie veel meer kwaad aanrichten dan alleen onder anderman's account te gaan lopen pielen.

Zorg er dus voor dat je database dichtgespijkerd zit. zorg ervoor dat je database server dichtgespijkerd is. maar ga niet lopen fiemelen over een plaintextje in je database.

Als m'n voordeur open staat terwijl ik op vakantie ben heeft 't ook vrij weinig nut om m'n dure spulletjes ergens achter een bank ofzo te verstoppen.

[kaandorp]

Als iemand zo goed is om in je database te komen om 't wachtwoord te achterhalen, dan kan ie veel meer kwaad aanrichten dan alleen onder anderman's account te gaan lopen pielen.

Zorg er dus voor dat je database dichtgespijkerd zit. zorg ervoor dat je database server dichtgespijkerd is. maar ga niet lopen fiemelen over een plaintextje in je database.

Als m'n voordeur open staat terwijl ik op vakantie ben heeft 't ook vrij weinig nut om m'n dure spulletjes ergens achter een bank ofzo te verstoppen.

Uhm.. Maar vaak beheer je de server niet zelf en heb je het dus zelf niet in de hand of iemand in je database rommelt. Daarbij komt nog dat ik vind dat mensen die toegang hebben tot een database niet direct alle wachtwoorden hoeven te weten. Een admin op een NT netwerk hoeft toch ook niet alle wachtwoorden van zijn gebruikers te zien

[itsme]

TheDane schreef op 13 February 2003 @ 15:01:
wat ik niet snap wat iedereen altijd roept

[...]


waarom niet !?

Als iemand zo goed is om in je database te komen om 't wachtwoord te achterhalen, dan kan ie veel meer kwaad aanrichten dan alleen onder anderman's account te gaan lopen pielen.

Zorg er dus voor dat je database dichtgespijkerd zit. zorg ervoor dat je database server dichtgespijkerd is. maar ga niet lopen fiemelen over een plaintextje in je database.

Als m'n voordeur open staat terwijl ik op vakantie ben heeft 't ook vrij weinig nut om m'n dure spulletjes ergens achter een bank ofzo te verstoppen.

Hier ben ik het volledig mee eens.
Er is maar 1 rede om dit niet te doen, de admin kan user passwords lezen.
Maar of dit zo bezwaarlijk is? Van de admin kan namelij wel worden verwacht dat dit een integer persoon is. Als je heb niet kunt vertouwen, wie dan wel?

kaandorp schreef op 13 February 2003 @ 15:10:
[...]


Uhm.. Maar vaak beheer je de server niet zelf en heb je het dus zelf niet in de hand of iemand in je database rommelt. Daarbij komt nog dat ik vind dat mensen die toegang hebben tot een database niet direct alle wachtwoorden hoeven te weten. Een admin op een NT netwerk hoeft toch ook niet alle wachtwoorden van zijn gebruikers te zien

Mja dat is ook weer waar ...
Als je zelf de database niet beheert is het md5'en wel heel relevant.
Een admin op een NT netwerk behoord integer te handelen, van hem mag worden verwacht daar niet naar te kijken.

md5 is daarnaast makkelijk toe te passen, dus het is maar een kleine moeite ...

[ Voor 30% gewijzigd door itsme op 13-02-2003 15:13 ]

[BtM909]

TheDane schreef op 13 February 2003 @ 15:01:
waarom niet !?

Als m'n voordeur open staat terwijl ik op vakantie ben heeft 't ook vrij weinig nut om m'n dure spulletjes ergens achter een bank ofzo te verstoppen.

Ondanks dat je je voordeur op slot doet, hebben een aantal mensen alsnog een kluis in het huis.

Het gaat om het idee: mocht er iemand binnenkomen in je systeem, dat de schade beperkt kan blijven.

Je zal maar een verkeerde query uitvoeren voor je wekelijkse mailinglist en per ongeluk je gebruikers tabel ophalen....

Tuurlijk ben je al fout bezig, maar better safe than sorry.

[TheDane]

hmmm, good points kaandorp & BtM909 ..

heb eigenlijk nog nooit een databaseserver buitenshuis gehad, dusja

[xces]

intressant topic..
- .htaccess in geval van apache
- ip restrictie, mjah dit heeft ook weer zijn nadelen
- ip/username logger (zodat je bepaalde users kunt disallowen, password sharing etc)
- session object
- logins met een timeout maken
- password md5-en is een hele goede, icm reset mogelijkheid
- email validatie invoeren (staan stukjes code op het net voor, maar code wou je nie)

Mijn login is als volgt (logt alles wat nuttig is, logins (false of geldige), acties op tabellen, ips etc):
1: htaccess
2: username/password
3: session timeout

Veel veiliger kan het denk ik niet, als ze de gegevens willen hebben dan komen ze er toch wel achter...