Dlouhé přihlášení

Áno, je to riešené cez cookie, tam si stránka uloží tvoj nick a heslo.

SeparateSK:
„tam si stránka uloží tvoj nick a heslo.“
To hádam nie. Aj keď aj veľký eshop môže urobiť zlý programátor, neverím, že by takúto zvrhlosť niekto urobil. Prihlasovacie údaje v žiadnom prípade nepatria do cookie (ani nikam inam, než na server), to by si mohol vedieť.

Občas se stačí trošku podívat na google..., nicméně podívej se jak to řeší třeba Jakub Vrána

shaggy:
v hashi samozrejme

SeparateSK [#5]:
Ani to asi ne. Pro tyto účely je třeba časově limitovaný token. A navíc, heslo nesdělujeme ani v hashi.

A prečo by aj nie?

Čitelný jméno a heslo v cookie? Děláš si snad srandu ne?

Kto alebo čo hovorí, že sú čitateľné?
$heslo!=$arr["password"] ?

Kľudne môžu byť vo vlastnom encodovaní.

Asi lepší príklad:

A myslíš si snáď, že útočník bude vedieť ako funguje tvoje vlastné encodovanie?

SeparateSK:
„A myslíš si snáď, že útočník bude vedieť ako funguje tvoje vlastné encodovanie?“
A ty si myslíš, že s tak obmedzenými znalosťami (aké máš) vymyslíš enkódovanie, ktoré útočník nedokáže prelomiť?
Traja sme ti napísali, že tieto veci do cookies nepatria. Dostal si aj odkaz na praktické riešenie, ale ty sa napriek tomu ideš hádať?

Len si dajte: javascript:alert(document.cookie) na tejto sieti - djpw.cz ;)
Meno, heslo i expirácia v jednom cookie

shaggy:
„Prihlasovacie údaje v žiadnom prípade nepatria do cookie (ani nikam inam, než na server), to by si mohol vedieť.“

Alphard:
„A navíc, heslo nesdělujeme ani v hashi.“

%7C = |

SeparateSK:
> Kto alebo čo hovorí, že sú čitateľné?
> $heslo!=$arr["password"] ?
Pak je heslo bez problému čitelné. Jediný efekt je, že když uživatel zadá heslo třeba „heslo“, pro tu cookie bude heslo „955db0b81ef1989b4a4dfeae8061a9a6“ a bude se držet v prostém textu.
Jakýkoliv uživatel získá hash hesla se dokáže přihlásit jako ten daný uživatel.

„Len si dajte: javascript:alert(document.cookie) na tejto sieti - djpw.cz ;)“
Tato diskuse historicky vychází z prastaré verze miniBB s hromadou bezpečnostních chyb, které se zdejší vývojáři postupně snaží odbourávat.
Čili ano, v kódu diskuse se mohou vyskytnout věci, které byste doma rozhodně zkoušet neměli :-)
Mimochodem, stejnou chybou trpělo phpBB do verze 3.

Joker:
„Jakýkoliv uživatel získá hash hesla se dokáže přihlásit jako ten daný uživatel.“
Ach, teda pardon, moja chyba, nad týmto som vôbec nepremýšľal a kvôli tomu vznikol celý spor - kvôli mojej nedbanlivosti :-) .

Ehm, čím ten časově limitovaný náhodný token bude pro dlouhé přihlášení bezpečnější? Pokud ukradnu danou sušenku, tak je to přece úplně jedno — oboje bude platit hodně dlouho. Nebo mi něco uniká*?

*) Nebo je pointa v tom, že ze špatně zajištěného hesla v cookie může jít vyčíst originální heslo? To je ale spíš problém obecně špatného hashování hesel.

Str4wberry:
„Nebo je pointa v tom, že ze špatně zajištěného hesla v cookie může jít vyčíst originální heslo?“
To může být problém, ale podle mě větší problém jsou dvě věci:
1. Dokud má uživatel stejné heslo, bude stejný i token. Pokud odchytím token a uživatel o tom neví, můžu se na něj přihlašovat, dokud si nezmění heslo, které si většina uživatelů nemění nikdy.
Když uživatel dostane token, který se při odhlášení zruší a při dalším přihlášení přidelí jiný, můžu se na jeden odchycený token přihlašovat jen do chvíle, než se ten uživatel odhlásí.
2. Pokud vím, jak má přihlašovací cookie vypadat (což obvykle není těžké zjistit), můžu se znalostí hashe uživatelova hesla, aniž bych prolomil jeho skutečné heslo, vytvořit přihlašovací cookie, na základě které mě systém automaticky přihlásí pod účtem daného uživatele.
A sám uživatel tomu nemůže nijak zabránit, pokud systém neumožňuje natvrdo zakázat automatické přihlašování.

Další výhoda samostatného tokenu je, že když nebude čistě náhodný, ale závislý na nějaké informaci od klienta (třeba i user-agent), ani ukořistěním přihlašovacího tokenu nebude jednoduše možné se přihlásit z jiného počítače.

Ad 1)
Narážel jsem na to, že pokud chci mít trvalé přihlášení, tedy hodně dlouhou dobu platnosti, tak se ta výhoda v časovém omezení nemusí moc projevit. Protože i ten časově limitovaný token bude platit hodně dlouho. (Schválně jsem se podíval na cookie u trvalého přihlášení na Twitteru a platnost se tam zdá být 30 let.)

Ale máš pravdu, že odhlášením a přihlášením se lehce snižuje risiko dlouhodobého zneužívání.

Ad 2)
Myslíš to tak, že se nějak dostaneš k hashi uživatelova hesla a díky tomu se dokážeš přihlásit? To ale stejně tak platí pro jakýkoliv token.

Hraní si s user-agentem může vést k nechtěnému odhlašování třeba po aktualisaci prohlížeče. Na druhou stranu pokud dokáže útočník získat cookie, řekl bych, že dokáže i toho user-agenta.

U tokenu je výhoda, že se může změnit jednou za čas (třeba jednou denně) i bez odhlášení uživatele. Tím by se taky nejspíš dalo zamezit ukradení cookie. Nehledě na to, že v prostředích kde je potřeba vysoká bezpečnost jde token svázat s jedinou IP adresou, což je pro útočníka další velká překážka.

„U tokenu je výhoda, že se může změnit jednou za čas (třeba jednou denně) i bez odhlášení uživatele.“
To se ale stejně tak prodlouží i zloději, ne?

„jde token svázat s jedinou IP adresou, což je pro útočníka další velká překážka“
Což je překážka i pro běžného uživatele, protože ho to bude pořád odhlašovat, když se mu IP změní. Pokud je potřeba vysoká bezpečnost, tak se asi vůbec nebudeme bavit o trvalém přihlášení, že? :–)

Str4wberry:
„To se ale stejně tak prodlouží i zloději, ne?“
Aby se token mohl změnit, musí se to stát při nějaké akci uživatele kdy jde změnit cookie. Tedy třeba při přechodu na jinou stránku. Šance, že se toto stane útočníkovi je malá. A pokud se to stane útočníkovi, pak to uživatele odlásí (protože má starý token) a při dalším přihlášení získá token pro sebe oprávněný uživatel, takže útočník zase prohraje. Není to stoprocentní, ale myslím, že pořád lepší než jeden neměnný token na třicet let.

„Pokud je potřeba vysoká bezpečnost, tak se asi vůbec nebudeme bavit o trvalém přihlášení, že? :–)“
Pravda, taky mi to pak došlo.

Nezablokujeme tím možnost být trvale přihlášen na více strojích (prohlížečích) najednou?

Str4wberry:
Zablokujeme. Alternativně jde prostě vypsat někdě (v profilu uživatele) všechna aktivní přihlášení s možností je zrušit. Pro přidanou bezpečnost pak případně informovat (v profilu nebo na mailu) o tom, že se někdo přihlásil z nové IP adresy nebo něco podobného. Otázka ale je, jestli tomu někdo věnuje pozornost.

To ale bude otravné. Přihlásit se z nové IP je celkem běžná záležitost. (Sám jsem na tuto diskusi poslal příspěvky z více než 200 IP adres.) A také taková informace bude pro běžné uživatele španělská vesnice.

Str4wberry:
Právě. Přesto se to někde dá vidět a mě osobně to vyhovuje. Asi to ale nemá smysl pro web, kde není třeba zabezpečení moc hlídat. Ono beztak jde prakticky jen o pohodlnou správu tokenů.

Str4wberry:
„pokud chci mít trvalé přihlášení, tedy hodně dlouhou dobu platnosti, tak se ta výhoda v časovém omezení nemusí moc projevit“
To je pravda, i tak se ale uživatel bude asi odhlašovat častěji, než si měnit heslo.
Krom toho mě napadl zhruba mechanismus, jaký popisuje Amunak:
Trvalé přihlášení vlastně funguje tak, že když uživateli vyprší relace a pošle nějaký token, systém mu automaticky vyrobí relaci novou. A to je zároveň docela výhodný bod, kdy lze samostatný token zahodit a vyrobit nový.
Každý token by tak vlastně sloužil k jednorázovému přihlášení. Při přihlášení ve chvíli, kdy vypršela session na serveru, bych „spotřeboval“ token a zároveň dostal nový.
Útočník by musel token odchytit a zároveň i použít v době mezi jeho získáním a spotřebováním uživatelem.
Takové přihlášení by ale zároveň spotřebovalo token a příští otevření stránky oprávněným uživatelem vyvolá situaci, kterou je možné detekovat a řešit. Neboli je možné detekovat i úspěšné neoprávněné přihlášení.

„Myslíš to tak, že se nějak dostaneš k hashi uživatelova hesla a díky tomu se dokážeš přihlásit? To ale stejně tak platí pro jakýkoliv token.“
Ale aby útočník mohl získat samostatný token, musí ho uživatel nejdřív vytvořit. Nelze tak nabourat účet, který nemá aktuálně platné trvalé přihlášení.
Při použití hashe hesla je token vygenerovaný a platný vždycky. I když bude uživatel paranoidní a trvalé přihlášení nikdy nebude používat, útočník si stejně může vyrobit cookie.
S jednorázovými tokeny navíc útočník musí stihnout token získat i spotřebovat v době od jeho vygenerování do spotřebování oprávněným uživatelem.

„Hraní si s user-agentem může vést k nechtěnému odhlašování třeba po aktualisaci prohlížeče.“
To ano.
Ale lze používat jen nějaké části (třeba název prohlížeče a operační systém). Takhle mám k dispozici škálu různých parametrů a můžu zvolit vhodný poměr mezi otravováním uživatelů a bezpečností.

„pokud dokáže útočník získat cookie, řekl bych, že dokáže i toho user-agenta.“
Pokud ví, co vlastně potřebuje. Že umí získat cookie ještě neznamená, že zná algoritmus sestavování tokenu na serveru (nebo alespoň ví, jaké údaje se pro to používají).

„Nezablokujeme tím možnost být trvale přihlášen na více strojích (prohlížečích) najednou?“
Můžu token svázat s počítačem, po jedné zdejší starší debatě s argumentem přecházení s jedním zařízením mezi WiFi sítěmi možná raději přes jiné údaje než IP, a zároveň umožnit více tokenů.
I když, kdybych si s tím chtěl vyhrát, bylo by možné udělat mechanismus, který by kontroloval víc faktorů a určité změny toleroval, například povolil změnu IP, pokud je stejný user-agent anebo změnu user-agenta, pokud je stejná IP, prohlížeč a operační systém.

Je pravda, že když už bych chtěl dělat takhle vychytaný systém, šlo by jako token použít i ten hash hesla, prostě bych přidal tabulku, ze kterých míst je povolené trvalé přihlášení. Ale pořád by to se samostatným tokenem bylo ještě o trošku bezpečnější.

Pořád přemýšlím, čím se to znovuvytvoření tokenu liší v případě oprávněného uživatele a narušitele. Z tvého popisu mi akorát vyplývá, že je menší čas na první použití ukradené sušenky, protože v ukradené podobě funguje jen do další akce oprávněného uživatele.

Jenom ujasním požadavky na funkčnost:
Neodhlášení při změně IP,
neodhlášení při aktualisaci prohlížeče,
možnost být současně přihlášen na více zařízeních.

Řekněme, že sušenku budu získávat pomocí XSS JavaScriptem, zároveň si pošlu všechna dostupná data o uživateli, takže pro mě nebude problém nasimulovat konkrétní OS a prohlížeč.