Hlavní navigace

Názory k článku
Bezpečné přihlašování uživatelů

peta
peta (neregistrovaný)
12. 4. 2006 0:26 Nový

Zabezpečení databáze s hesly

celé vlákno
Ahoj, článek je OK, jen v něm myslím chybí zmínka o tom, že v případě použití challenge-response mechanismu je třeba zvláštní péči věnovat ochraně databáze, kde jsou uloženy otisky hesel. Při zcizení otisků se může zručnější útočník přihlásit v podstatě jako jakýkoli uživatel - stačí jen trochu poupravit uvedený JavaScript, aby již otisk nehashoval. Bohužel ani C-R tedy není "100% bezpečný"...
Lukáš Zapletal

Re: Zabezpečení databáze s hesly

celé vlákno
Bezpečné není nic, zabezpečené -- to už je jiný pojem.

Jinak - v databázi není nutné mít hesla uložené v čistém textu. Stačí, když jsou tam třeba MD5kovaná hesla - klient v javascriptu provede s heslem to samé, než vytvoří samotný response hash.
uživatel si přál zůstat v anonymitě
12. 4. 2006 15:14 Nový

Re: Zabezpečení databáze s hesly

celé vlákno
tohle je fakt vtipny - hashnete si plaintext heslo a poslete ho -> mame nove plaintext heslo a tim je ten samotny hash ;) - protoze ho lze primo poslat serveru ze.
Igor
Igor (neregistrovaný)
13. 4. 2006 11:22 Nový

Re: Zabezpečení databáze s hesly

celé vlákno
Presne tak. Je zajimave, kolik lidi propada tehle iluzi, ze zacnou-li misto hesla pouzivat jeho hash, heslo a potazmo soustavu tim fikane zabezpeci. Jenze z hlediska utocnika se nic nemeni, proste odchyti hash 'hesla' a bude se jim prokazovat stejne, jako by odchytil 'heslo'.
Jirka Kosek
Jirka Kosek (neregistrovaný)
13. 4. 2006 11:47 Nový

Re: Zabezpečení databáze s hesly

celé vlákno
Heslo je tím skutečně zabezpečené. Většina uživatelů používá do různých systémů stejná hesla. Pokud se někdo dostane k databázi hesel jednoho systému, kde jsou jen jejich hashe, nemůže hned hesla použít pro napadeních jiných systémů, kde má daný uživatel účet.

Hesla se v databázi nehashují kvůli tomu, aby bylo těžší celou aplikaci hacknout, ale kvůli tomu, aby následky takového hacku byly pro uživatele menší.
Igor
Igor (neregistrovaný)
13. 4. 2006 13:51 Nový

Re: Zabezpečení databáze s hesly

celé vlákno
Nelze poprit, ze obeti pouzivaji stejna hesla, ani to, ze hash nelze pouzit jinde, za predpokladu, ze jinde shodou okolnosti nepouzivaji stejny postup. Neni zaruka, ze ne, vlastne lze ocekavat, ze se primocare postupy budou opakovat.
Nicmene je treba si uvedomit, ze uziva-li se vsude misto 'hesla' jeho hash, faktickym heslem se stava hash 'hesla', nikoliv zaklad, z nehoz byl vypocten. Ackoliv se do databaze ukladaji hashe, po funkcni strance jde o hesla v plaintext forme, byt pouzitelna pro utoky zase (snad) jen na tomto stroji. Toto je pricinou iluze: rada lidi nechape, jak se hashe promeni v plaintext. Proste voodoo.
To je cena za (nejistou) unikatnost hesel (+ pripadne CR protokol). Neco podobneho tu uz ale padlo.
uživatel si přál zůstat v anonymitě
13. 4. 2006 21:54 Nový

Re: Zabezpečení databáze s hesly

celé vlákno
Něco na tom je. Na druhou stranu, pokud člověk používá dostatečně slabé heslo, se znalostí hashovacího algoritmu a hashe se dá heslo s relativní jistotou zjistit v rozumném čase. A člověk, který se dostane k databázi hashů a zaměří se na jednoho konkrétního člověka, aniž by tento o problému věděl nebo adekvátně zareagoval, ten čas má.
HKMaly aura:99

Re: Zabezpečení databáze s hesly

celé vlákno
Jednu vyhodu to ma: na takto vytvorene heslo se blbe dela slovnikovy utok. Jenze kdo by se delal se slovnikovym utokem kdyz muze heslo jednoduse odposlechnout ...
peta
peta (neregistrovaný)
13. 4. 2006 21:31 Nový

Re: Zabezpečení databáze s hesly

celé vlákno
Nějak si nejsem jistý, zda jsem pochopil tento příspěvek. Heslo se samozřejmě odposlechnout dá - pokud se ovšem nepoužije C-R nebo něco podobného. V tom případě se odchytí pouze zahashovaný řetězec, který je samozřejmě již na nic, protože při příštím přihlášení bude zase jiný...
Andrew
Andrew (neregistrovaný)
17. 4. 2006 19:47 Nový

Re: Zabezpečení databáze s hesly

celé vlákno
Chápeš to správně, ale ostatní ne. Samozřejmě pokud se posílá jen otisk hesla, je to skoro stejné, jako by se posílalo heslo, ale tady se posílá otisk kombinace hesla s jedinečným klíčem, tudíž po odchycení je to k ničemu, neboť při opětovném použití to už nebude platit.
Michal Ludvig aura:100
12. 4. 2006 1:17 Nový

Nojo, ale...

celé vlákno
Pekny, ale pokud je "utocnik" v pozici ze muze data odchytavat, tak musime pocitat s tim ze je muze i modifikovat (man-in-the-middle), treba tim ze ma pod kontrolou router nebo proxy server. Pak mu staci upravit prenaseny Javascript a heslo si s jeho pomoci bud nekam ulit, nebo nechat v extra hlavicce poslat nezasifrovane, nebo tak neco.

Podobny problem je v okamziku kdy se prihlasovaci formular nachazi na nezabezpecene strance, ackoliv jeho odeslani vede nekam na https:// adresu. Tak je to treba pri prihlasovani do Seznamu z jeho homepage. Kdyz bude "utocnik" po tech heslech opravdu touzit, tak proste cestou ke klientovi tuhle nezabezpecenou stranku upravi tak aby se formular odesilal nekam na jeho server.

Pravda, je to o neco slozitejsi nez pouhe poslouchani pomoci snifferu, ale zase ne o moc.

Shrnuti: neni SSL od zacatku do konce => neni bezpecnost.
antonin chadima
antonin chadima (neregistrovaný)
12. 4. 2006 7:29 Nový

Re: Nojo, ale...

celé vlákno
tak tak
platYpus
platYpus (neregistrovaný)
12. 4. 2006 13:10 Nový

Re: Nojo, ale...

celé vlákno
> Shrnuti: neni SSL od zacatku do konce => neni bezpecnost.

Nesouhlasim a davam protipriklad: S/KEY
Ivo Peterka aura:73
12. 4. 2006 16:51 Nový

Re: Nojo, ale...

celé vlákno
Tak jsem myslel to ohodnocení 1 jako dobrý názor a ono je to tady obráceně. Bohužel už to nemůžu opravit. Ach jo ... . Jinak S/KEY je opravdu dobrý systém ...
Bilbo
Bilbo (neregistrovaný)
12. 4. 2006 13:19 Nový

Re: Nojo, ale...

celé vlákno
Precejen pustit sniffer je nekdy jednodussi (napr. pokud je na siti hub a ja jsem na spravnem miste) nez provoz modifikovat (pokud mam pristup rovnou na router, neni co resit, ale pokud jsem jen na stejnem segmentu site .. )

Pustit sniffer zvladne i kdejaky script kiddie ze zakladni skoly, dat tam proxy co bude modikfikovat nejaky konkretni javascript uz treba ne ...
Michal Kára
Michal Kára (neregistrovaný)
12. 4. 2006 7:37 Nový

Bezpecne ukladani vs. challenge-response

celé vlákno
Nojo. Ale pokud mam hesla v databazi "bezpecne ulozena" (hashovana), nemuzu pouzivat challenge response... Takze si clovek musi vybrat.

Jinak se v algoritmu pouziva nedavno "prolomena" funkce md5. Je pravdou, ze v tomto pripade jeji zranitelnost AFAIK nevadi, ale stejne by mozna bylo lepsi pouzit neco jineho, napr. SHA.
HKMaly aura:99

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
Ne tak docela. Hesla muzes mit klidne hashovana trikrat, ale plati ze na overeni challenge-response tohoto typu klientovy staci vedet co mas v databazi (muzes mit v databazi hash hesla a na klientovy pocitat response z hesla tak, ze nejdriv udelas hash - ale pak uz nemuzes overit, ze klient skutecne mel to heslo a ne jen ten hash, ktery mohl ziskat napriklad ukradenim databaze).

Challenge-response tohoto typu proste zvysi bezpecnost proti odposlouchavani a snizi bezpecnost proti ukradeni databaze.

Jedina spravna cesta pro challenge-response (ktera ma vyhody obou) je asymetricka kryptografie. Jenze obavam se, ze RSA v javascriptu nespocitas ... a i kdyby, pouzit na to SSL je vyhodnejsi. (SSL challenge-response je situace, kdy se klient prihlasuje vlastnim certifikatem).
Michal Kára
Michal Kára (neregistrovaný)
12. 4. 2006 7:55 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
Cekal jsem ze s tim nekdo vyrukuje. Ano, pak musim na klientovi pri prihlasovani provest stejny hash, jako jsem delal pri ukladani do databaze. Coz ale znamena, ze:

1) Hashovaci funkce je verejna a kdokoli ziska DB, muze podniknout slovnikovy utok (a nedelejme si iluze o odolnosti beznych hesel BFU proti nemu).
2) Staci upravit klienta a misto hesla pouzit hash z DB.

Samorejme, RSA to resi, ale s JS je s ni problem.

Dalsi vec je, pokud je potreba se prihlasovat i pres POP3, IMAP, SMTP atp., kde zadny javascript do klienta nepropasuji ;-)
Wejn
Wejn (neregistrovaný)
12. 4. 2006 9:36 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
Dalsi vec je, pokud je potreba se prihlasovat i pres POP3, IMAP, SMTP atp., kde zadny javascript do klienta nepropasuji ;-)
To sice ano, ale vsechny zminene protokoly maji SSL i TLS variantu ... a kazdy slusny hosting (a to uz nemluvim o kazdem slusnem spravci) zabezpecene pripojeni nabizi, pokud ho rovnou nevynucuje.
Bilbo
Bilbo (neregistrovaný)
12. 4. 2006 13:22 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
"muze podniknout slovnikovy utok"

Pokud by bylo klasicke prihlasovani s jmenem a heslam posilanym v plaintextu tak by to mohl udeloat taky .... tenhle pristup pri situaci, kdy dojde k vykradeni databaze, nema oproti posilani v plaintextu zadne nevyhody (ale ani vyhody)
Michal Kára
Michal Kára (neregistrovaný)
12. 4. 2006 15:22 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
Ja jsem myslel, ze kdyz vykrade zahashovana hesla, tak je sice neuvidi primo, ale muze na ty hashe co ukradl udelat slovnikovy utok a velke mnozstvi hesel prevede do plaintextu. Mame zkusenosti s XChatem ;-)
darBis

RSA v JavaScriptu

celé vlákno

RSA v JavaScriptu spocitat lze, viz treba JavaScript Encryption Program (je tam i ukazkove "sifrovatko") nebo Google (?q=…).

Sice to neni zadny fofr, ale na zasifrovani hesla to ujde.

Jakub Vrána aura:60
12. 4. 2006 10:45 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno

A co takhle?

  1. U každého uživatele bude uložen login, challenge a md5(hmac_md5(password, challenge)).
  2. Při přihlašování se AJAXem zjistí, jaký challenge uživatel naposledy použil, a pošle se hmac_md5(password, old_challenge) a md5(hmac_md5(password, new_challenge))
  3. Na serveru se navíc ověří, jestli md5(old_hmac) souhlasí s tím, co je uloženo v databázi, a pokud ano, přepíše se to novými hodnotami.

Autorem této myšlenky je Paul Jonhston. Přikládám Proof of Concept.

junix
junix (neregistrovaný)
13. 4. 2006 17:18 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
Napad je to zajimavy, ale take se mi zda, ze ma svoje mouchy, opravte me, jestli se mylim: Uzivatel je autorizovan na zaklade predchozi vyzvy, a old_hmac (ze ktereho se na serveru udela md5, ale to neni zas tak podstatne). Je tu tedy zpet riziko odposlechu, kteremu jsme se snazili zabranit. Dokonce je to jeste horsi, protoze: Pri kazdem odposlechu zjistime ctverici: old_challenge, old_hmac, new_challenge, new_hmac K naslednemu prihlaseni staci dvojice: new_challenge, new_hmac protoze se nas na ni bude system ptat jako na old_challenge. A ted pozor! Server nema k dispozici heslo, algoritmus hmac je pouze na klientu. Pokud ho vynechate a poslete cokoliv, co vypada jako hash, server nema jak overit, ze je to skutecne hmac vaseho hesla a challenge! Muzete tedy poslat ctverici: old_challenge, old_hmac, new_challenge, random_hmac a system vas prihlasi a dokonce prepise hmac na vas nahodny, takze puvodni uzivatel uz se tam nedostane, zatimco utocnik ano a to uplne bez znamlosti hesla!
Jakub Vrána aura:60
13. 4. 2006 17:32 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
Důležité je uvědomit si, že se neposílá new_hmac, ale md5(new_hmac). Pokud to útočník odposlechne, k ničemu mu to neposlouží, protože k příštímu přihlášení chceme samotný old_hmac. Tedy ta část, kterou nepovažujete za nepodstatnou, je skoro nejpodstatnější.
junix
junix (neregistrovaný)
13. 4. 2006 18:23 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
Nojo, dik za upozorneni. To je ono. Samozrejme by se slo pokusit ten hash cracknout, ale vzhledem k tomu, ze hmac je take md5 z 'neceho', tak by mel mit 128 bitu (16bytu), tudiz dost odolny vuci brute force a prakticky nemozny vuci slovniku. To uz je jednodussi z old_hmac cracknout skutecne heslo, presto, ze se na nej aplikuje MD5 dvakrat. Prefixy $k_ipad a $k_opad se spocitaji ze znalosti old_challenge, takze crackujete pouze heslo a bude to trvat pouze O(1) krat dele, nez kdyby se crackovala obycejna MD5.

Jinak nevidim zas takovou nutnost sahat si pro predchozi challenge AJAXem. Nejedna se o nezavisly kanal, a je akorat zavisly na tom, ze uz potrebuje znat uzivatelske jmeno
Jakub Vrána aura:60
13. 4. 2006 20:38 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
Jak jinak získat předchozí challenge, když ne AJAXem nebo podobnou technikou? Tedy pominu-li možnost poslat předchozí challenge všech uživatelů rovnou s formulářem nebo rozdělit přihlášení do dvou kroků.
sly
sly (neregistrovaný)
10. 8. 2006 15:27 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
AJAX je zasadni chyba. za pouzivani berlicek k implementaci funkci(onalit) bych vesel. za koule.
sly
sly (neregistrovaný)
10. 8. 2006 15:24 Nový

Re: Bezpecne ukladani vs. challenge-response

celé vlákno
"napr. SHA" :)))
michal_sjx
michal_sjx (neregistrovaný)
12. 4. 2006 10:23 Nový

postranni kanal

celé vlákno
Kdyz pouziji hmac, tak tim jen presunu bezp. problem smerem na DB - musim chranit i otisky.
Tak kde potrebuji opravdu bezpecnost, tak bud pouzivam postranni kanal a nebo pristupove fraze.
postranni kanal: poslu si overovaci kod treba smskou.... meze se nekladou ;)
pristupova fraze: jako heslo, ale je to napr. minimalne 20 znaku dlouhe a pri prihlasovani se neposila cela fraze, ale jenom nahodne vybrane bity nasledne prevedene do hashe. Kdyz se utocnik dostane ke frazi, tak je samozrejme problem... Ale student ze stredni v prvaku se k ni stejne nedostane ;).

Kdyz bezpecnost, tak postanni kanal. To je muj nazor.
martin
martin (neregistrovaný)
12. 4. 2006 23:16 Nový

Re: postranni kanal

celé vlákno
A neni nahodou mechanismus pristupove fraze jenom jina varianta challenge-responze?

Response = F(challenge, passwd)

Vyber bitu, ktere ma klient z hesla vybrat a zahashovat je vlastne challenge, misto hmac_md5 se jen pouzije jina funkce (tj. vyber bitu + nejaky hash).
Zbyva otazka, jestli ten vyber bitu je bezpecnejsi, nez HMAC.
Michal S aura:56

Re: postranni kanal

celé vlákno
Ano mas pravdu, ale pristupova fraze se nedostane na sit cela, budou tam chybet informace (bity). Krom toho jeste budou treba prohnany pres hmac. Vysledkem bude, ze utocnik potrebuje odchytit daleko vice prihlaseni a jeste slusne kouzlit s hmac. To se promitne do celkoveho casu potrebneho k uspesnemu utoku. Navic neni zaruceno, ze se v dobe utoku jeste heslo nezmeni.

Odpoved: neni pokud se user prihlasuje treba 100x za minutu. Jinak je to bezpecnejsi.
junix
junix (neregistrovaný)
13. 4. 2006 11:09 Nový

Re: postranni kanal

celé vlákno
Popravde nevidim zvyseni bezpecnosti vuci challenge-response. Tady se taky nedostava na sit heslo, ale bavime se o tom, ze ke kompromitaci dojde v pripade, ze se utocnik dostane k databazi otisku. Tohle riziko mi pripada stejne, protoze i v pripade passphrase musi byt nekde ulozena cela, aby se mohly vybrat prislusne casti i na serveru a overit platnost.
michal_sjx
michal_sjx (neregistrovaný)
12. 4. 2006 23:18 Nový

Re: postranni kanal

celé vlákno
Me ted jeste napadl jeden bezva kanal, kde se da predavat parametr pro prihlasovaci formular. Neni to nic noveho. Proste obrazek s kodem, ktery user musi opsat. Vyhoda je v tom, ze hacker ho osniffuje, ale musi u toho sedet v realnem case a v realnem case udelat utok rychleji nez se user prihlasi ... to prakticky odboura vetsinu utocniku, kteri by chteli vystavovat desitky hesel na web ;).
junix
junix (neregistrovaný)
13. 4. 2006 11:15 Nový

Re: postranni kanal

celé vlákno
To moc postrani kanal neni. Jak bys chtel overit konkretniho uzivatele? Ten postrani kanal znamena, ze SMS se posle na konkretni cislo, ktere ma ten uzivatel zadane na uctu, takze se podle nej pozna, ze prislo na jeho telefon, a ze je to dost pravdepodobne on.

Ve tvem pripade bys dal ten kod kazdemu, kdo vlezl na prihlasovaci formular? Nebo by se k tomu zadavalo heslo? Pak je obrazek k nicemu, jen treba "schovany" challenge, coz neodstranuje zadne bezpecnostni problemy pri prihlasovani.
Igor
Igor (neregistrovaný)
13. 4. 2006 11:32 Nový

Re: postranni kanal

celé vlákno
Nejen hacker u toho musi sedet v realnem case, ale take legitimni uzivatel.
Vedle toho zablokujes vsechny slepce nebo obecne kohokoliv, kdo z jakehokoliv duvodu nevidi grafiku. To uz to tam muzes rovnou hazet ve Flashi...
Petr Mika aura:100

Digest Access Authentication

Reseni se nabizi samo i bez vynalezani kola:

viz. http://www.faqs.org/rfcs/rfc2617.html
Abraxis
Abraxis (neregistrovaný)
12. 4. 2006 16:36 Nový

Jednoduse?

celé vlákno
Co takhle:
- server posle klientovi vyzvu (napr. hashnuty aktualni cas + nejaky salt)
- klient udela hash hesla a tento hash hesla jeste jednou zhasuje s vyzvou
- klient posle serveru vysledny hash

Funkcni oproti odposlechum...
Jakub Vrána aura:60
12. 4. 2006 16:46 Nový

Re: Jednoduse?

celé vlákno
Na serveru musíte kontrolovat, jestli už výzva nebyla použitá, jinak to je skoro k ničemu. Nevím, co máte na mysli tvrzením "hash hesla jeste jednou zhasuje s vyzvou", ale pokud to je třeba pouhé zřetězení, tak to pravděpodobně není tak bezpečné jako HMAC, který byl za tímto účelem navržen. Jinak nevidím, čím se tento postup liší od článku.
Pakanek aura:100

napadeni seznamu

Pokud je mi dobře známo, tak obětí takového útoku byla školní síť, s kterou nemá seznam nic společného - jak to sám tvrdí. Nebo je to jinak? Vypustil tuto informaci nějaký lepší zdroj než je senzace-chtivá TV N@va?

http://www.novinky.cz/internet/82262-seznam-cz-zadny-hacker-nenapadl.html
Petr
Petr (neregistrovaný)
12. 4. 2006 20:16 Nový

Podezrele veci

celé vlákno
0. Vsimnete si, ze v tomto pripade nemusi server vubec challenge posilat. Klient si muze challenge domyslet (je to aktualni cas). Proc se tedy server obtezuje s jejim generovanim? Pokud chcete challenge ze serveru, at je skutecne nahodna.

1. Naprosto to nechrani proti "grand chessmaster" problemu (on-line man-in-the-middle). U https mam moznost zkontrolovat certifikat druhe strany. Tady nemam nic.

2. Nevim, jestli pouzita funkce now() nema problemy s prechodem z letniho casu na zimni ("zopakuje se hodina", takze jde prehrat hodinu stare zpravy).

3. Obecneji, kazda synchronizace casu na serveru otevira prostor pro replay utok.

4. Kde je ochrana proti slovnikovemu utoku? Napriklad omezeni poctu pokusu za jednotku casu apod.

4b. Kde je ochrana proti slovnikovemu utoku II? Utocnik odposlechne challenge a ji odpovidajici heslo a potom off-line zkusi slovnikovy utok "uhodni heslo, aby z nej a ze znameho challenge vznikl znamy hmac". - Tohle je nesrovnatelne jednodussi nez napadnout nejakou variantu Diffie-Hellmana, kterou se zasifruje kanal jeste drive, nez nejaka autentifikace vubec probiha.

5. Ulozeny MD5 hash hesla je vlastne heslo do systemu. (To, co uzivatel chape jako "heslo", je jen mnemotechnicka pomucka pro vytvoreni skutecneho hesla.) Takze mame v databazi de facto ulozena skutecna hesla. To jsme si pomohli...

6. Zpusob, kdy overeni na serveru nepouzije odeslany challenge, ale challenge obdrzeny od klienta (tj. potencialne pozmeneny) rozhodne nevzbuzuje duveru. Kdyby nic, server by mel overit, ze tento challenge byl skutecne tomuto klientovi odeslan (tato vazba pritom v tabulce chybi!). A mel by overit, ze to neni prilis davny challenge.

7. Kdyz uz jsme u toho, pouziti MD5 take nevzbuzuje uplnou duveru :-) Ne ze by utoky byly prakticke (rychle hledani kolize je porad neco jineho nez invertovani hashe), ale u soudu vas kazdy trochu schopny pravnik roztrha :-)


Rekl bych, ze predevsim #4b je vyznamny duvod, proc bych cloveka s takovouto implementaci vyhnal. Existuji lepsi protokoly, ktere takto napadnout nelze. Jsou mozna implementacne slozitejsi, ale knihovny existuji (a navic clovek to pise jednou a pouziva mockrat).
Jakub Vrána aura:60
12. 4. 2006 21:38 Nový

Re: Podezrele veci

celé vlákno
0, 2, 3. Jedná se o vaši nepozornost. Čas se ukládá jen proto, aby se daly mazat staré záznamy. Pro challenge se používá ID.

1. Nechrání, článek se o to ani nesnaží a na další výhody HTTPS upozorňuje. Řeší jeden konrétní problém a to je zabránění odposlechu hesel bez HTTPS.

4. S článkem to nijak nesouvisí, je to další věc, na kterou je vhodné se zaměřit.

5. Ano, v článku toto riziko mělo být zmíněno a v diskusi už to několikrát zaznělo. Podívejte se prosím na komentář http://www.root.cz/clanky/bezpecne-prihlasovani-uzivatelu/nazory/86698/, který tento problém podle mě řeší.

6. Vazba klient-challenge by se jistě ukládat mohla, ale bezpečnost by to podle mě zvýšilo jen minimálně. Pokud bych challenge uložil do session proměnné a útočník by byl schopen odposlechnout challenge, jistě by byl schopen odposlechnout i session ID. Vazba přes IP adresu může být problematická (jeden člověk může používat více adres). Průběžné mazání starých challengů je v článku zmíněno.

7. Postup je na hashovací funkci nezávislý. MD5 jsem zvolil proto, že je nejznámější a známé útoky se k tomuto použití nedají nijak využít.

4b. Můžete tedy prosím popsat postup, který tímto problémem netrpí? Klidně formou honorovaného článku, redakce vám jistě vyjde vstříc.
Petr Mika aura:100

Re: Podezrele veci

celé vlákno
K cemu cela tato saskarna, kdyz mame neco cemu se rika
Digest Access Authentication

(viz muj, zrejme nepovsimnuty prispevek vyse)

http://www.faqs.org/rfcs/rfc2617.html

Cituji:

3 Digest Access Authentication Scheme

3.1 Introduction

3.1.1 Purpose

The protocol referred to as "HTTP/1.0" includes the specification for
a Basic Access Authentication scheme[1]. That scheme is not
considered to be a secure method of user authentication, as the user
name and password are passed over the network in an unencrypted form.
This section provides the specification for a scheme that does not
send the password in cleartext, referred to as "Digest Access
Authentication".

The Digest Access Authentication scheme is not intended to be a
complete answer to the need for security in the World Wide Web. This
scheme provides no encryption of message content. The intent is
simply to create an access authentication method that avoids the most
serious flaws of Basic authentication.
Michal Krause aura:95
13. 4. 2006 9:34 Nový

Re: Podezrele veci

celé vlákno
Soudím, že tohle řešení má také své mouchy.

Kupříkladu asi nejde dost dobře udělat volitelné přihlášení (jako například tady u přidávání příspěvku - můžu se přihlásit, ale nemusím).

Uživatelská přítulnost také poněkud trpí, protože pokud někdo přijde na chráněnou stránku, nejsem schopen mu rozumně a přehledně sdělit, proč musí být přihlášen (je možné, že je tu omylem), a navíc nedávám uživateli zrovna mnoho možností, jak případně zbloudění napravit (vyskočí na něj přihlašovací okno a dokud s ním něco neprovede, nemůže udělat back, zvolit z menu jinou stránku a podobně).

A v neposlední řadě, myslím, že neexistuje zaručená a ve všech prohlížečích funkční metoda, jak se odhlásit (kromě restartu prohlížeče).
Petr Mika aura:100

Re: Podezrele veci

celé vlákno
Pripadne mouchy ma, ale to co jste uvedl je naprosto mimo misu

1) resi se tu BEZPECNOST prihlasovani

2) pokud uzivatel nevi proc se ma prihlasit tak evidentne leze nekam kde nema co delat - proto tam to prihlasovani je aby tam nelezl :-O

3) pote co neprojde overovacim mechanismem je mozne zobrazit stranku s informaci kde je, proc po nem bylo pozadovano prihlaseni a svete div se muze si pote kliknout na jakykoliv odkaz ktery mu predhodime, nebo si samozrejme muze kliknout ve svem prohlizeci "zpet"
Jakub Vrána aura:60
13. 4. 2006 10:24 Nový

Re: Podezrele veci

celé vlákno
Michal poukazuje na to, že použití HTTP autentizace je někdy jednoduše nevhodné. A např. chybějící možnost odhlášení bez zavření prohlížeče může být docela zásadní problém. Proto celá tato "šaškárna".

Pro vaše požadavky zmíněné problémy problematické nejsou (se zřejmě záměrným vynecháním problému odhlašování nebo možnosti volitelného přihlášení). To ale neznamená, že to není problematické pro nikoho.
uživatel si přál zůstat v anonymitě
15. 8. 2006 11:48 Nový

Re: Podezrele veci

celé vlákno
Odhlaseni:
<?php
header("HTTP/1.1 401 Unauthorized");
?>
uživatel si přál zůstat v anonymitě
15. 8. 2006 18:24 Nový

Re: Podezrele veci

celé vlákno
Toto prohlížeče (přinejmenším Firefox 1.5 a IE6) k zapomenutí přihlašovacích údajů bohužel nepřiměje, při příštím zobrazení stránky se přihlašovací údaje opět pošlou. Kdysi fungovalo odhlášení pomocí odkazu http://logout:logout@www.example.com/, tyto odkazy jsou ale od IE6 pod XP-SP2 defaultně zakázané.
uživatel si přál zůstat v anonymitě
16. 8. 2006 11:44 Nový

Re: Podezrele veci

celé vlákno
Zkousel jsem to jen v Safari, kde to jde. Google nasel navod, kterej se tim zabyva. Nemam cas to zkouset, ale treba tam nektere tipy budou fungovat :-) http://www.berenddeboer.net/rest/authentication.html#permanent-logout
Jakub Vrána aura:60
16. 8. 2006 14:52 Nový

Re: Podezrele veci

celé vlákno
Asi nejzajímavější informace v článku podle mě je, že od IE6SP1 lze platnou autentizaci smazat pomocí <script>document.execCommand('ClearAuthenticationCache');</script>.
Petr
Petr (neregistrovaný)
13. 4. 2006 19:14 Nový

Re: Podezrele veci

celé vlákno
Ad 4b. Vetsinou jde o veci publikovane (a mnohdy patentovane :-)). Prislo by mi nefer postavit honorovany clanek na tom, ze neco opisu z literatury.

Zaklad problemu je v tom, ze uzivatele nejde donutit, aby pouzival silne heslo. Pocet bitu, ktere si clovek bezchybne zapamatuje, je silne omezen. Je pravdepodobne, ze vetsina systemu zalozenych na heslech podlehne slovnikovemu utoku.

Kdyz tohle bylo receno, porad jeste je moznost to utocnikovi velmi ztizit. Je velky rozdil, pokud muze otestovat desetitisice hesel za sekundu (z nich pocita jen "rychly" MD5 hash) nebo zda ho donutime hodne pocitat a overeni jednoho hesla trva sekundy. - Dokonce tomu jde i zabranit, pokud pomoci hesla (a i nasledne) podepisujeme jen nahodne stringy nebo pokud pripada v uvahu mnoho hesel.

Takze prvni napad, zalozeny na asymetricke sifre (uvadim ho proto, ze je z me hlavy; ostatni veci budu citovat z literatury :-)): Heslo se pouzije jako seed to dobreho generatoru pseudonahodnych cisel. Pomoci nej vygeneruji standardnim postupem key-pair. Server dostane public key. Prihlasovani vypada tak, ze v klientu do stejneho generatoru zadam heslo (tedy tentyz seed jako puvodne), vygeneruju privatni klic a zasifruju timestamp. Server to rozsifruje ulozenym klicem, overi, ze timestamp je v rozumnem rozsahu (aby nedoslo k replay stare zpravy), konkatenuje timestamp se svym timestampem, zasifruje to ulozenym klicem a posle nazpet. Klient to rozsifruje, overi, ze puvodni timestamp je rovny jeho timestampu a ze timestamp serveru je v rozumnem rozsahu (druha prevence replay). Vezme timestamp serveru, zasifruje jej svym klicem a posle to na server. Server overi, ze to odpovida jeho puvodni zprave a povazuje uzivatele za autentifikovaneho. (Z praktickych duvodu muze byt dobry napad padovat timestamp nebo konkatenaci timestampu nahodnymi bajty.)


Dalsi metody:
1. EKE (popsano v S.M.Bellovin, M.Merrit: Encrypted Data Exchange: Password-Based Protocols Secure Against Dictionary Attack. Proceedings of the 1992 IEEE Computer Society Conferenec on Research in Security and Privacy; viz tez B.Schneier, Applied Cryptography, kapitola 22.5; patentovany algoritmus). Myslenka je v tom, ze se pomoci hesla zasifruje nahodny public klic, odpovidajicim private klicem se sifruje dalsi nahodny klic, a pak si obe strany prokazou, ze tento druhy nahodny klic znaji tak, ze si vymeni zasifrovane nahodne stringy. (Klient posle sifrovany nahodny s1, server desifruje s1 a posle sifrovanou konkatenaci s1 a nahodneho s2, klient desifruje zpravu, overi spravnost s1 a posle zasifrovany s2, server desifruje a overi spravnost s2.) Slovnikovy utok je nemozny, nebot vse je nahodne. - K odstraneni man-in-the-middle se jeden z tech nahodnych klicu nevytvori nahodne, ale Diffie-Hellmanem. Man-in-the-middle si musi s kazdou stranou dohodnout vlastni klic, jinak bude uprostred jen smutne koukat na zasifrovane zpravy (tj. pasivne odposlouchavat). Vzhledem k tomu, ze ten klic si obe strany predavaji ve zprave a ze ke konstrukci zpravy je potreba znat to heslo, ma ten man-in-the-middle smulu.

2. Fortified Key Negotiation (popsano v R.J.Anderson, T.M.A.Lomas: Fortifying Key Negotiation Schemes with Poorly Chosen Passwords. Electronic Letters, v.30, n.13, 23 Jun 1994; viz tez B.Schneier, Applied Cryptography, kapitola 22.6). Myslenka je v tom, ze krome normalni hash funkce se jeste pouzije hash funkce s mnoha kolizemi (takze poslanemu hashi muze odpovidat velmi mnoho hesel. Touto funkci se hashuje neco, co obsahuje puvodni heslo a nahodne Diffie-Hellman-generovany klic. (Diffie-Hellman pripadneho in-the-middle-mana donuti, aby na obe strany pouzival jiny klic a tedy bude odhalen, kdyz si obe strany klic predavaji jako soucast hashe nebo sifry.) Odposlechnuti nestaci (zprave na drate odpovida mnoho moznych hesel) a man-in-the-middle nejde (bez znalosti hesla a vzhledem ke kolizi se nepodari na druhou stranu poslat spravnou zpravu). - Autentifikace pak probehne stejne jako v minulem bode - obe strany si navzajem dokazou, ze umeji zpravu s nahodnymi stringy desifrovat.

3. Schnorr (napr. C.P.Schnorr: Efficient Signature Generation for Smart Cards. Advances in Cryptology - EUROCRYPT, '88 Proceesings; viz tez B.Schneier, kapitola 21.3; patentovano). V tomto pripade jako private key zvolime hash hesla (pripadne modulo q), dopocteme public key a ten ulozime na serveru. Protokol je challenge-and-response - server posle dost velke nahodne cislo (Shnorr doporucuje 72-bitove cislo), klient posle odpoved a server overi, ze overovaci rovnice odpovedi vychazi. (Odolnost proti slovnikovemu utoku vychazi jen z pomalosti uvedenych vypoctu, podobne jako u mnou navrhovaneho schematu.)



Obecne ale myslim, ze utocnik pujde nejakou jinou cestou. Napriklad ze nabouchne prohlizec, ktery provadi ty javascripty, a ziska heslo tam odtud. Ale to uz je jina pohadka :-)
Jakub Vrána aura:60
13. 4. 2006 21:35 Nový

Re: Podezrele veci

celé vlákno
Mohl byste prosím popsat, proč se provádí jednotlivé kroky ve vašem schématu? Některé mi přijdou samoúčelné. Na druhou stranu mám dojem, že když bude náhodné číslo připojené k timestampu dostatečně velké a náhodné, tak je slovníkový útok prakticky nemožný (protože kromě hesla musím zkoušet i náhodná čísla).
Petr
Petr (neregistrovaný)
13. 4. 2006 23:17 Nový

Re: Podezrele veci

celé vlákno
Nevim presne, o kterych krocich mluvime. Je to ta oboustranna vymena nahodnych stringu (puvodne timestampu)? Ta zajistuje dve veci: Server vidi, ze uzivatel zna klic (protoze dokaze otevrit dlouhou zpravu, z ni vyndat substring a ten opet zasifrovat). Uzivatel vidi, ze server zna klic (a tedy ze nejakemu utocnikovi jen tak neposkytuje "munici" - zasifrovane pakety pro pozdejsi replay attack); pokud server nezna klic, uzivatel uz nic zasifrovaneho neposle.

(Pro timestampy ve skutecnosti je jeden z tech kroku nadbytecny - za predpokladu, ze se muzeme spolehnout na synchronizovane hodiny mezi klientem a serverem.)

Jestli to je to generovani public/private klice z hesla, tak to je ten zdrzujici krok, ktery ma odradit utocnika od slovnikoveho utoku. Pokud trva vygenerovani paru nekolik sekund, kolik hesel za den lze vyzkouset?
Petr
Petr (neregistrovaný)
13. 4. 2006 23:12 Nový

Re: Podezrele veci

celé vlákno
Djova, teda ted jsem to zmastil vsechno dohromady. Pouceni pro priste: Dam si kafe driv, nez budu takhle odpovidat. - Musim si ted odpovedet sam, jinak neusnu :-)

Nejdriv k rozpleteni man-in-the-middle: Normalne se o man-in-the-middle mluvi tehdy, kdyz sifruju a ten uprostred to resifruje. V nasem pripade se samozrejme o nic takoveho jednat nemuze. Samotna komunikace je nezabezpecena proti odposlechu a nezabezpecena proti manipulaci. Po prihlaseni muze teoreticky kdokoliv menit pakety, posilat za me prikazy a tak. Tohle vsechno plyne z rozhodnuti nepouzit SSL. (Obecne: Proti odposlechu je potreba sifrovat a pocatecni key exchange musi vyuzit sdileneho tajemstvi - hesla - aby MiM nemel sanci. Proti manipulaci staci pripojovat nejaky HMAC, zalozeny napriklad na vymenenem klici.)

V nasem pripade se snazime zabezpecit proti nasledujicim utokum:
- slovnikovy utok na heslo
- replay starych paketu
- "triknuti" uzivatele, aby pri zpracovani vhodne zvolene challenge prozradil neco o hesle.

K tomu memu protokolu: 1. Samozrejme tam neni potreba timestamp. Stejne jako v ostatnich protokolech, znalost klice (resp. jedne casti na klientu a druhe casti na serveru) staci posilat nahodne stringy a kontrolovat je. Klient posle s1 sifrovany svym klicem. Server desifruje s1 (nic s nim delat nemuze), pripoji k nemu s2 a zasifruje to svym klicem. Klient desifruje, odsouhlasi s1, zasifruje uz jen s2 a posle to serveru. Server to zkontroluje. Pokud s1 a s2 jsou dostatecne nahodne, replay se nepovede.
2. No a samozrejme neni *nutny* public/private klic. Jde to udelat i symetricky. Vyhoda pouziti public/private je v tom, ze na serveru ulozim jen jeden klic; i v pripade uniku dat ze serveru je utocnik nemuze pouzit na prihlaseni.

K EKE: S tim Diffie-Hellmanem jsem to zmastil neomluvitelne. Nic takoveho potreba neni. Jeste jednou shrnuti: Klient vytvori nahodny public/private par, public klic zasifruje pomoci sveho hesla a posle ho serveru. Server rozsifruje public klic, vygeneruje nahodny symetricky klic a zasifruje ho pomoci public klice a pak jeste pomoci hesla. Klient vse desifruje. Pak si oba stroje navzajem prokazou, ze ten symetricky klic znaji. Utocnik nemuze provest slovnikovy utok, nebot aby mu k necemu byl, musel by nasledne jeste prolomit asymetrickou sifru, aby se k symetrickemu klici dostal (az symetricky klic sifruje neco, kde lze zkouset poznat, zda mam spravny klic).
martin
martin (neregistrovaný)
12. 4. 2006 21:39 Nový

Re: Podezrele veci

celé vlákno
ad 0, 2: Challenge neni cas, ale poradove cislo, ten cas je v tabulce jenom proto, aby se dala dobre uklizet.

Ale nejlepsi reseni to neni, da se tim udelat DoS:

Uzivatel A dostane challenge X, uzvatel Z (zaskodnik) dostane X+1, ale zkusi odeslat svuj formular se svym heslem a challenge X, kdyz bude rychlejsi nez A, vymaze radek s challenge X z tabulky "challenges" a uzivatel A se neprihlasi. Kdyz tohle bude uzivatel Z opakovat dostatecne rychle, zabrani urcitemu procentu uzivatelu v prihlaseni. (ne ze se bude porad tupe prihlasovat, ale bude si opakovane nacitat prihlasovaci formular, dokud se mu challenge budou zvetsovat jen o 1, vidi, ze je tam sam, jakmile se mu challenge zvysi vice nez o 1, vi, na jake challenge ma utocit)

Obrana:
A. Limitovat pocet zobrazeni prihlasovaciho formulare na 1 adresu
+ zaroven to brani prilis rychlemu rustu tabulky challenges
- velka firma za http proxy s 1 IP adresu bude mit problem
- Porad jde udelat DDoS :-)

B. misto predikovatelne challenge z auto_incrementu pouzit neco jineho, napr.
$UNIQUE_ID (ovsem neresi nadmerny rust tabulky "challenge"). Pridelenou challenge
si ale misto do databaze muzu ulozit do $_SESSION a mam tim i zajistenu vazbu na browser, kteremu jsem challenge poslal (viz bod 6) a nemusim se starat o udrovani tabulky challenge v rozumnych mezich.
HKMaly aura:99

Re: Podezrele veci

celé vlákno
Co porad lidi maji s tou magickou $_SESSION ... proc se nerekne rovnou, ze se to ulozi do databaze nebo do souboru na disk a id zaznamu se posle klientovy v cookie ? Jenze pak by neslo machrovat s vetami typu "misto do databaze" ...
Leoš Bitto
Leoš Bitto (neregistrovaný)
13. 4. 2006 23:26 Nový

Re: Podezrele veci

celé vlákno
Na tohle (neukládání session na serveru) existuje jednoduchý trik: veškerá data poslat klientovi (např. v cookie) spolu s jejich digitálním podpisem (stačí k datům přidat tajné heslo a výsledek prohnat kvalitní hashovací funkcí). No a když klient pošle data s příštím požadavkem zpět, ověříme na serveru ten digitální podpis a pokud sedí, máme jistotu že jsou data autentická.
kinghowa
kinghowa (neregistrovaný)
17. 4. 2006 20:41 Nový

Re: Podezrele veci

celé vlákno
Povedená otázka, smekám nad (pod) ní. Škoda, že nemám čas na ní odpovědět.

trocha sváteční ironie ;-)
Zasílat nově přidané příspěvky e-mailem