[php] User systeem echt veilig?

[Stimp]

Ik ben bezig met een inlog systeem voor users met php. Ik doe dit met sessies, omdat de mogelijkheden van htaccess niet voldoende zijn, of te ingewikkeld voor de doeleinden (logging enz).

Het script wat ik nu heb geschreven doet het volgende:

1. User komt op een beveiligde pagina, er wordt verwezen naar een functie die controleert of er ingelogd is, deze staat in een class waar alle functies bij elkaar staan voor het login-gebeuren.

2. Functie geeft door dat er niet ingelogd is, user krijgt een inlog scherm voor zn neus.

3. User logt in (password wordt gewoon naar het php bestand gestuurd)

4. Als de login gegevens kloppen met wat in de database staat (password wordt in het php bestand md5 geencrypt, en vergeleken met het md5-encrypt password in de db). Als dit allemaal klopt wordt er een random nummer in de database, en in de sessie gezet.

5. Daarna wordt op iedere pagina deze met elkaar vergeleken.

Dingen die ik misschien nog kan toevoegen:
- md5 encryptie bij de client, zodat het wachtwoord niet gewoon naar php wordt verstuurd.
- controle op ip, dus na een aantal logins achter elkaar geen mogelijkheden meer om in te loggen.

Zijn dit dingen die het extra veilig maken? En zijn er nog dingen die ik vergeten ben?

[SWINX]

lijkt me best wel veilig als je die md5 encryptie ook nog ff op de browser doet..

IP-check kan natuurlijk alleen bij mensen met een vast IP, en dat houdt in dat ze ook niet op school/ op werk op bij de buren in mogen loggen.... is misschien een beetje jammer

[Verwijderd]

waarom vraagt iedereen toch altijd of een systeem veilig is .. ik bedoel.. je kan het zelf na gaan toch .. wij zijn geen hackers.. echt overal word gevraagd.. is dit veilig.. jah .. is veilig..

[djack]

Je kan met keys gaan werken, .....
Hier mee bedoel ik een key bij de klant een key op de server (ssh princiepe)
ook natuurlijk https

[Stimp]

Verwijderd schreef op 13 november 2002 @ 16:39:
waarom vraagt iedereen toch altijd of een systeem veilig is .. ik bedoel.. je kan het zelf na gaan toch .. wij zijn geen hackers.. echt overal word gevraagd.. is dit veilig.. jah .. is veilig..

mja ik weet het , ik heb ook vaker dit soort topics zien langskomen. Maar het probleem is dat je nooit 100% weet of je manier van denken wel helemaal waterdicht is. Daarom dacht ik dus, maar even voor de zekerheid vragen

Ik zal iniedergeval ook op de client md5 encryptie toepassen. Ik hoor graag nog meer suggesties.

djack schreef op 13 november 2002 @ 16:39:
Je kan met keys gaan werken, .....
Hier mee bedoel ik een key bij de klant een key op de server (ssh princiepe)
ook natuurlijk https

Bedoel je dus, dat ik zo´n random waarde ook nog in een cookie ofzo bij de client moet opslaan? Het lijkt me niet echt dat dat het een stuk veiliger maakt.

[Verwijderd]

Een systeem is nooit 100% waterdicht...

[Eärendil]

Is md5 encryptie bij de client niet een beetje overbodig als je ook al een beveiligde verbinding hebt?

[Sjaaky]

md5 encryptie bij de client kan, maar bedenk wel dat als iemand het md5 wachtwoord onderschept, hij met de md5 nog steeds kan inloggen. De md5 is dan eigenlijk het wachtwoord.

[The Bad Seed]

Waarvoor moet het gaan dienen? Als het is om je familiefoto's oid met een pw te beveiligen is het overkill om https of keys te gaan gebruiken. (Voor de meeste andere doelen eigenlijk ook)

[ACM]

Nightelf schreef op 13 november 2002 @ 16:20:
4. Als de login gegevens kloppen met wat in de database staat (password wordt in het php bestand md5 geencrypt, en vergeleken met het md5-encrypt password in de db). Als dit allemaal klopt wordt er een random nummer in de database, en in de sessie gezet.

Bedoel je dat je de md5-sum berekend van de string?
Of de md5-variant van crypt gebruikt? (Dus crypt() met een extra lange salt, of op een systeem dat default md5-crypt doet)

- md5 encryptie bij de client, zodat het wachtwoord niet gewoon naar php wordt verstuurd.
- controle op ip, dus na een aantal logins achter elkaar geen mogelijkheden meer om in te loggen.

Het eerste voorkomt dat een hacker die de boel onderschept het password kan bekijken, maar niet dat ie niet meer in kan loggen. Md5 op de client is echter niet echt een standaard functie, dus maak je de boel er wel gevoeliger voor wat betreft portability.

Controleren op ip's is wel een aardige, maar maakt de boel wel minder flexibel als je langere sessie's wilt ondersteunen.
Btw, het lijkt me verstandiger als je een sessie-id ofzo genereerd (of gewoon php-sessies gebruiken) waardoor je niet elke request opnieuw het password opgestuurd krijgt.

Echter is de vraag "waarvoor is het" veel belangrijker, want je moet niet _te_ veel moeite ervoor gaan doen als de gevolgen van een hack-poging niet groot zijn (zeker als de kans erop al niet heel hoog is)

[Verwijderd]

en een post-referer check?

[ACM]

Verwijderd schreef op 13 November 2002 @ 18:37:
en een post-referer check?

Referer's zijn leuk, maar een referer is niet betrouwbaar (zijn te faken en uit te schakelen).

Wat je evt kan doen is het sessieid in de formulieren verwerken om te voorkomen dat formulieren van vreemde plaatsen gepost kunnen worden.

[Verwijderd]

ACM schreef op 13 november 2002 @ 18:43:

[...]

Referer's zijn leuk, maar een referer is niet betrouwbaar (zijn te faken en uit te schakelen).

Wat je evt kan doen is het sessieid in de formulieren verwerken om te voorkomen dat formulieren van vreemde plaatsen gepost kunnen worden.

Tuurlijk zijn ze onveilig.... maar het maakt het geheel wel weer wat veiliger... ik bedoel... waarom maken jullie hier op GoT er dan nog gebruik van?