Trvalé přihlášení

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.

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.

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.

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?

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.