Autor Zpráva
Sylar
Profil
Zdravím,
řeším otázku trvalého přihlášení a našel jsem mnoho návodů jak na to přes cookies. Drtivá většina si ukládá ID usera a nějaký náhodně generovaný token, případně ještě platnost. Chci se zeptat, jaký je rozdíl když uživateli vygeneruji token s platností třeba rok (pokud chci aby mohl být trvale přihlášen takovou dlouhou dobu) a ten uložím do cookie s jeho ID naproti tomu, když do ní uložím třeba jeho login a např. hash jeho hesla. Moc v tom nevidím rozdíl, obojí je uložené v DB i v cookie a ověřuje se stejným procesem - porovnám login/ID uživatele s nějakým hashem/tokenem v DB, pokud sedí, přihlásím uživatele. Může se někdo k těch cookies souborům, kde je toto uloženo dostat na nezabezpečené a/nebo na zabezpečené verzi? Pokud ano, v obou případech se dokáže přihlásit a nezdá se mi to moc bezpečené.
juriad
Profil
Sylar:
Pokud se jedná o http a nikoli https, data po síti tečou nešifrovaně. Přenášel by se tedy nešifrovaně i ten hash hesla. Abys dosáhl stejně bezpečnosti, musel by si uživatel měnit heslo stejně částo, což neudělá. Další výhoda tokenu je, že jej můžeš měnit často (má platnost rok, ale při prvním jeho použití se změní na nový). To prakticky znemožňuje útočníkovi jeho použití - má čas 1 request; navíc server může detekovat, že jeden token byl použit dvakrát (útočníkem a uživatelem) a zruší session oběma.
Pokud používáš nějaký tupý hashovací algoritmus (md5 bez soli například), lze z hashe často zjistit původní heslo (zadej do googlu d577273ff885c3f84dadb8578bb41399) a hrozí únik hesla nebo možnost použití stejného hashe na jiné stránce, kde má tento uživatel také účet a používá to samé heslo.
Keeehi
Profil
juriad:
navíc server může detekovat, že jeden token byl použit dvakrát (útočníkem a uživatelem) a zruší session oběma
Pokud se nepletu, tak by to mohlo způsobit problém při práci ve více oknech. Takže by se asi muselo povolit neomezené množství požadavků z jedné IP adresy se stejným tokenem.
Sylar
Profil
juriad:
Rozumim, takze pote co uzivatele prihlasim pres token z cookies, vygeneruji novy, ten mu ulozim zpet a ten puvodni smazu.

Pises, v pripade nezabezpecene verze, znamena to, ze v pripade zabezpecene verze je to mnou psane reseni relativne bezpecne, protoze se data posilaji sifrovane?

Pro hesla pouzivam password_hash() ta by mela byt (snad) bezpecna (?), proto jsem myslel, ze pouziti hashe namisto tokenu nevadi.
juriad
Profil
Keeehi:
Více oken stejného prohlížeče sdílí cookies. A anonymní režim můžeš považovat za samostatný prohlížeč.
Každý prohlížeč má své vlastní úložiště cookies, a tedy nutně i vlastní session, a tedy své vlastní tokeny. A pro vytvoření této session je potřeba přihlášení (jméno a heslo).
Já neříkám, že uživatel nemůže být přihlášen vícekrát najednou.

Sylar:
Skoro. Síť není jediné místo, kde může dojít k úniku dat. Teď si myslíme, že ty hashovací algoritmy jsou dobré, zítra to může být jinak, budeš snad předělávat svou aplikaci? Jediný důvod, proč posílat hashe hesla při každém requestu namísto náhodného tokenu, je pohodlnost programátora, a to mi nepřijde jako dostatečný důvod.

Tvůj projev je špatně srozumitelný, piš prosím s diakritikou.
Keeehi
Profil
juriad:
Tak asi nechápu, jak často se token mění a co tuto změnu inicializuje. A na základě čeho server rozpoznává dva rozdílné prohlížeče sídlící stejný token, tedy že někdo útočí. Mohl bys to prosím popsat?
Sylar
Profil
juriad:
Jasný, to máš pravdu, jen mne to zajímalo.

Sorry, psal jsem z telefonu.

Keeehi:
Jak jsem psal výše, token by se měl měnit v momentě, kdy uživatel přijde na stránku. Pokud jej má uložen v cookie a v databázi se ověří, že je platný, ihned vygeneruji nový, uložím ho zpět do cookie a ten původní z DB smažu nebo nějak označím, že byl použit.
juriad
Profil
Keeehi:
V okamžiku přihlášení server vygeneruje token, který se uloží do cookie a zároveň si jej poznamená do databáze do seznamu platných tokenů toho uživatele. Každý další request klienta na server pošle zároveň tuto cookie. Tokeny se v prohlížeči v cookie přepisují, takže při každém requestu se posílá vždy ten nejnovější.
V okamžiku přijetí cookie serverem, se podívá, zda je token platný:
* ano -> vygeneruje nový a nastaví jej do nové cookie. Starý token buď smaže nebo zkrátí jeho platnost na něco směšněho (1 minuta), protože teoreticky uživatel může ze stejného zařízení a prohlížeče odeslat requestů více a kvůli situaci na síti můžou dojít v libovolném pořadí. Pouhé zkrácení na rozdíl od smazání snižuje bezpečnost, takže je možné tokeny mazat a v prohlížeči třeba přes localStorage komunikovat mezi jednotlivými taby tak, aby probíhal maximálně jeden request v každý okamžik (vím, je to nedokonalé), nebo se na to vykašlat a doufat, že uživatel tak rychle nekliká. Problematické je například načítání obrázků poskytovaných skriptem, který vyžaduje ověření (a tedy kontrolu tokenu), prohlížeč dotahuje obrázky paralelně.
* ne -> ukončí platnost všech tokenů, a vynutí tedy, aby se uživatel znovu přihlásil. Méně dramatické by bylo zrušení tokenů pro danou session. Více by bylo zablokování účtu do zadání kódu, který uživatel dostane do e-mailu.
Vždy při kontrole tokenů v databázi zároveň probíhá mazání těch neplatných.

Vaše odpověď


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: