Remote login via http

[Standeman]

Als een soort van "webservice" kan een gebruiker bij ons data in onze database stoppen door zich te authoriseren en een form te posten met wat data erin. Ik zit me af te vragen hoe het (buiten https om) het veiliger zou kunnen maken, zodat dictionary / replay attacks (veel!) moeilijker zo niet onmogelijk worden.

Op het moment wordt een http request naar deze "webservice" geauhtoriseerd aan de hand van een username, sha-1(password+rand(salt)) en random salt in de form variabelen. Vervolgens haal ik het password op uit de DB en kijk of sha-1(password+rand(salt)) overeenkomt met diegene die ik bereken.

Nu is het dus mogelijk om met een dictionary attack uit te gaan vogelen hoe de hash wordt gemaakt bijv door
"$dictionary_word+password" en "password+$dictionary_word" te gaan bruteforcen.
Verder is een replay-attack ook nog gewoon mogelijk. Eigenlijk zou ik dan alle salts bij moeten houden en het request moeten rejecten als de salt al een keer gebruikt is.

Heeft iemand tips hoe ik de authorisatie kan verbeteren? Ik heb de bel al wel horen luiden, maar ik ben nog op zoek naar de klepel geloof ik.

De kans dat iemand dit wil gaan misbruiken is naar mijn inschatting niet zo heel groot, maar beter safe than sorry.

[ Voor 14% gewijzigd door Standeman op 12-02-2009 15:28 ]

[Spider.007]

Volgens mij kun je zowel de dictionary attack als de replay attack voorkomen door de tijd dat het formulier wordt opgevraagd in de hash te verwerken, en beide gegevens van de client weer terug te verwachten en dan dus te controleren op sha1(password+rand(salt+timestamp))

Zie trouwens ook http://oauth.net/ voor inspiratie; of implementeer het zelf meteen ff

[ Voor 8% gewijzigd door Spider.007 op 12-02-2009 16:12 ]

[Standeman]

Spider.007 schreef op donderdag 12 februari 2009 @ 16:12:
Volgens mij kun je zowel de dictionary attack als de replay attack voorkomen door de tijd dat het formulier wordt opgevraagd in de hash te verwerken, en beide gegevens van de client weer terug te verwachten en dan dus te controleren op sha1(password+rand(salt+timestamp))

Zie trouwens ook http://oauth.net/ voor inspiratie; of implementeer het zelf meteen ff

Heb je helemaal gelijk in. Maar moet dan de tijd van de client en die van de server dan niet exact gelijk lopen? Of zit die timestamp ergens in het HTTP request?

[SKiLLa]

Die (server-) TimeStamp verwerk je in de hash die je naar de client stuurt. En bij de post-back destillieer je de eerder verstuurde timestamp uit de hash en vergelijk je het huidige (server-) tijdstip ermee; is het verschil groter dan X minuten --> foutmelding.

[Standeman]

SKiLLa schreef op dinsdag 17 februari 2009 @ 00:50:
Die (server-) TimeStamp verwerk je in de hash die je naar de client stuurt. En bij de post-back destillieer je de eerder verstuurde timestamp uit de hash en vergelijk je het huidige (server-) tijdstip ermee; is het verschil groter dan X minuten --> foutmelding.

Ahh.. dat maakt alles duidelijk. Ik geloof dat ik nogal wat te leren heb over security

[Verwijderd]

Er zijn nog meer opties.

Je kan de webservic b.v. zo instellen dat die alleen naar lokale requests luistert.

De enigste manier om dan een dictionairy attack te doen is via je login form. Als je ook nog eens een timeout mee geeft bij je form

$waittime = time() + 4;
while($waittime > time())
{
}

Duurt het iig 4 seconden voor dat de requestterug komt. Als je replay attack wil voorkomen kan je natuurlijk het pogingen aan het IP-adres koppelen. Als dit 3 foutieve is toon je een Captcha en bij 5 foutieve pogingen blokeer je hem voor 10 minuten.

Als je helemaal paranoia wil gaan toon je standaard de captcha bij het login form. Maar als het form zo belangrijk voor je is raad ik je toch om om te zoeken naar een 'second level of audenthication' b.v. webseal (http://publib.boulder.ibm.../am51_webseal_guide15.htm)

[CH4OS]

In de TS geef je al aan om het buiten HTTPS om te doen. Wat is hiervan de reden als ik vragen mag?
De simpelste oplossing lijkt mij een HTTPS implementatie van de website, tenzij er een gegronde reden is om géén HTTPS te gebruiken.

[Verwijderd]

https voorkomt geen dictionairy attacks!

[Standeman]

GJtje schreef op dinsdag 17 februari 2009 @ 12:21:
In de TS geef je al aan om het buiten HTTPS om te doen. Wat is hiervan de reden als ik vragen mag?
De simpelste oplossing lijkt mij een HTTPS implementatie van de website, tenzij er een gegronde reden is om géén HTTPS te gebruiken.

Ik wilde HTTPS even buiten beschouwing laten in deze discussie, dat heb ik namelijk al redelijk door en vertroebelt de discussie misschien een beetje.

[ Voor 5% gewijzigd door Standeman op 17-02-2009 16:11 ]

[Standeman]

@shad0w
Dat soort trucs zijn weer te omzeilen met IP spoofing. Ok, misschien niet zo makkelijk, maar zeker niet onmogelijk.
Verder zullen Captcha's niet zoveel zin hebben aangezien aan de andere kant ook een geautomatiseerd systeem draaid.

[leuk_he]

Standeman schreef op donderdag 12 februari 2009 @ 15:12:
De kans dat iemand dit wil gaan misbruiken is naar mijn inschatting niet zo heel groot, maar beter safe than sorry.

andere hoek:

Risico analyse maken? Wat als de gebruiker via het geijkte systeem misbruik maakt? Wat kan hij meer aals hij dit misbruiken kan automatiseren? Hoe ondek je oneigenlijk gebruik? wie wordt er dan gewaarschuwd (is dit een ANDERE gebruiker ?)

[Standeman]

leuk_he schreef op dinsdag 17 februari 2009 @ 16:26:
[...]

andere hoek:

Risico analyse maken? Wat als de gebruiker via het geijkte systeem misbruik maakt? Wat kan hij meer aals hij dit misbruiken kan automatiseren? Hoe ondek je oneigenlijk gebruik? wie wordt er dan gewaarschuwd (is dit een ANDERE gebruiker ?)

Heel goed punt. Wanneer iemand gaat lopen klooien komt er data in onze DB die waarschijnlijk niets zeggend is. Uiteindelijk kan je die ene tabel flink fullen waardoor de DB traag gaat worden wat uiteindelijk zal leiden tot een DoS.

Oneigenlijk gebruik kan worden gedetecteerd d.m.v. IP, alleen sommige IP adressen mogen een request sturen. Hoewel IP spoofing natuurlijk mogelijk is.