| Autor | Zpráva | ||
|---|---|---|---|
| midlan Profil |
Ahoj, přemýšlel jsem o tom jak na stránce přihlásit uživatele natrvalo ale zároveň bezpečně. Napadlo mě ukládat tokeny společně s user-agent a ip do databáze a token každých 5 minut regenerovat. Všechno vypadá skvěle až na jednu věc - počet záznamů v databázi. Teoreticky kdyby byla návštěvnost 10 lídí denně a každý by na stránkách strávil 15 minut to máme za rok 10(lidí)*3(tokeny)*365(dní) = 10950 záznamů. To je podle mě hodně. Jako prevence mě napadlo třeba jednou za 3 měsíce vyprázdnit tabulku tokenů a změnit název cookie, ale to by zas všechny poodhlašovalo a kdo by na to taky pořád myslel :/
|
||
| Alphard Profil |
#2 · Zasláno: 16. 8. 2012, 00:40:23
Uniká mi smysl existence nových tokenů, pokud ty staré neztratí platnost ani po roce.
Z ukládané ip adresy budu všichni mobilní uživatelé jistě nadšeni. |
||
| Majkl578 Profil |
#3 · Zasláno: 16. 8. 2012, 00:51:12
Alphard:
„Z ukládané ip adresy budu všichni mobilní uživatelé jistě nadšeni.“ A z ukládání user-agenta jistě také, takový Chrome nemá zrovna velké mezery mezi aktualizacemi, nemluvě třeba o denních aktualizacích Aurory. midlan: Jaký je problém v použití sessions s expirací např. 30 dní (a bez kontroly IP a user agenta)? |
||
| midlan Profil |
#4 · Zasláno: 16. 8. 2012, 11:35:13
Alphard:
„Uniká mi smysl existence nových tokenů, pokud ty staré neztratí platnost ani po roce.“ Jedná se o aplikaci kde bezpečnost hraje velkou roli. 5 minutové regenerování+ukládání informácí by mělo ztížit uhodnout nebo ukrást token. Majkl578: „Jaký je problém v použití sessions s expirací např. 30 dní (a bez kontroly IP a user agenta)?“ právě ta bazpečnost, proto mají v základu sessions platnost jen 24 minut (alespoň v mojem php.ini) |
||
| Majkl578 Profil |
#5 · Zasláno: 16. 8. 2012, 11:49:55
midlan:
„Jedná se o aplikaci kde bezpečnost hraje velkou roli.“ Tak v prvé řadě použij HTTPS, pak se nemusíš bát session hijackingu. Pak mi ale nejde dohromady vysoce zabezpečená aplikace a trvalé přihlášení. |
||
| midlan Profil |
#6 · Zasláno: 16. 8. 2012, 12:33:29
Majkl578:
Takže navrhuješ se na trvalé přihlášení vybodnout úplně? Na jednu stranu bude uživatele otravovat přihlašování dokola při každé návštěvě, ale zase se jim na účet nedostane nikdo ani na jejich PC :/ Já fakt nevim co zvolit :D |
||
| Joker Profil |
#7 · Zasláno: 16. 8. 2012, 12:53:26
midlan:
Trvalé přihlášení u „vysoce zabezpečené“ aplikace je nežádoucí, protože když se pak uživatel přihlásí z nějakého veřejného/cizího počítače a třeba místo odhlášení jen zavře stránku, zůstane to přihlášení trvale aktivní pro kohokoliv, kdo si k tomu počítači sedne. „bude uživatele otravovat přihlašování dokola při každé návštěvě“ Zodpovědní uživatelé se stejně budou muset pokaždé přihlašovat, protože při ukončení práce s aplikací vyžadující vysoké zabezpečení by se měli explicitně odhlásit. A zároveň je to připomínka toho zabezpečení. Kdyby mě například elektronické bankovnictví automaticky přihlásilo protože si pamatuje mé předchozí přihlášení, asi bych vážně uvažoval o změně banky. |
||
| midlan Profil |
#8 · Zasláno: 16. 8. 2012, 15:52:45
Dobře přihlášení natrvalo tedy zavrhuji. Ale co teď, mám použít sessions? Mají sessions nějak ošetřené že nevygenerují někomu znovu aktivní session_id?
|
||
| Joker Profil |
#9 · Zasláno: 16. 8. 2012, 16:37:44
midlan:
Jelikož je ten identifikátor generovaný náhodně, teoreticky je možné vygenerovat dva stejné. PHP by ale mělo takovou situaci ohlídat a nedovolit přidělení identifikátoru, který už používá jiná session. Identifikátor je ale možné nastavit i v PHP, takže například ve skriptu, který by uložil session data a později chtěl obnovit už zaniklou relaci s jejím původním identifikátorem, by teoreticky kolize mohla nastat (jestliže by zrovna shodou okolností pod stejným ID byla jiná aktivní relace). Ale je to hodně nepravděpodobné (pokud by nebyly řádově alespoň tak miliony současně aktivních relací). |
||
| midlan Profil |
#10 · Zasláno: 16. 8. 2012, 16:47:58
Joker:
„Jelikož je ten identifikátor generovaný náhodně, teoreticky je možné vygenerovat dva stejné. PHP by ale mělo takovou situaci ohlídat a nedovolit přidělení identifikátoru, který už používá jiná session.“ To jsem si právě myslel protože už se mi dvakrát stalo že jsem přišel na stránky a byl jsem přihlášen jako někdo cizí (buď mám tokový štěstí nebo jim to nemazalo vypršelé sessions z disku :D). Asi použiju vlastní řešení kde bude něco takového vyloučené. Díky všem. |
||
| japlavaren Profil |
#11 · Zasláno: 16. 8. 2012, 16:48:34 · Upravil/a: japlavaren
pozri si, ako je to riesene v admineri - myslim, ze to ma jakub vrana i na blogu
tu http://php.vrana.cz/trvale-prihlaseni.php |
||
| Alphard Profil |
#12 · Zasláno: 16. 8. 2012, 18:32:37
midlan:
„To jsem si právě myslel protože už se mi dvakrát stalo že jsem přišel na stránky a byl jsem přihlášen jako někdo cizí“ To se mi stalo jen když jsem se někam dostal přes odkaz, který obsahoval sessid v url. Což je samozřejmě pro dobře zabezpečenou aplikaci nepřijatelné. Náhodné příhlašení se na jinou osobu při normální implementaci přihlašovacího systému se mi zdá nereálné. Aby to vaše vlastně řešení nebylo chybové ještě víc... japlavaren: Před chvílí midlan uznal, že trvalé přihlášení není v souladu s vysoce zabezpečenou aplikací. |
||
| midlan Profil |
#13 · Zasláno: 16. 8. 2012, 20:42:52
Alphard:
> To se mi stalo jen když jsem se někam dostal přes odkaz, který obsahoval sessid v url. Což je samozřejmě pro dobře zabezpečenou aplikaci nepřijatelné. > Náhodné příhlašení se na jinou osobu při normální implementaci přihlašovacího systému se mi zdá nereálné. [/i] Stalo se mi to tady asi tak 6-7 let zpátky, ani jsem tam neměl založený účet. „Aby to vaše vlastně řešení nebylo chybové ještě víc...“ Snad ne :) Stejně mám radši když mám všechno ve vlsatní režii :) |
||
| Majkl578 Profil |
midlan:
„asi tak 6-7 let zpátky“ To už je poměrně dlouho. Určitě šlo o sessions a ne nějakou vlastní, pofidérní implementaci? midlan: „Snad ne“ Pak tedy v ideálním případě zveřejni svoji implementaci, která bude lepší než built-in řešení (jeho algoritmus najdeš tady). Nejednoho člověka by určitě zajímalo. (Případě na Stack Overflow je zajímavé téma týkající se unikátnosti a možného snížení pravděpodobnosti kolize.) |
||
|
Časová prodleva: 15 dní
|
|||
| midlan Profil |
#15 · Zasláno: 1. 9. 2012, 13:41:17
Majkl578:
„Pak tedy v ideálním případě zveřejni svoji implementaci, která bude lepší než built-in řešení“ Ok uvedu to (trochu opžděně ale snad to nevadí) kdyby to někoho zajímalo, případně mi můžete říct kde to má slabiny :) Tokeny ukládám společně s IP, user-agentem a datumem vytvoření tokenu do databáze. Tokeny starší než 8 minut z databáze automaticky mažu. Uživateli nastavuji cookie s tokenem s platností 8 minut. Pokud je token uživatele starší než 5 minut, vegenruji mu nový s platností dalších 8 minut (tohle je opatření aby uživatele neotravovalo automatické odhlašování pokud se v aplikaci 'pohybuje'). Funkce na generovaní tokenů vypadá následovně: <?php
function generate($lenght = null){
if($lenght === null) {
$lenght = mt_rand(30, 40);
}
$stack = '.-_abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ';
$str = '';
for($chars = strlen($stack)-1; $lenght >= 0; $lenght--) {
$str .= $stack[mt_rand(0, $chars)];
}
return $str;
}
$token = generate();
?>Ještě musím pro zvýšení bezpečnosti udělat sloupeček s tokeny v databázi case-sensitivní (btw. kdyby někdo věděl jak tak písněte) a nastavit druhou cookie do konce sezení prohlížeče aby nebylo možné zůstat přihlášený po zavření prohlížeče (např.: uživatel po minutě od přihlášení zavře prohlížeč, tzn token by byl ještě 7 minut byla platný a někdo by toho mohl zneužít). |
||
|
Časová prodleva: 12 let
|
|||
0