cwbe coordinatez:
101
792011
2663954
2663960
2664128
2669177

ABSOLUT
KYBERIA
permissions
you: r,
system: public
net: yes

neurons

stats|by_visit|by_K
source
tiamat
K|my_K|given_K
last
commanders
polls

total descendants::
total children::1
show[ 2 | 3] flat
cosi podobne som implementoval ja v mojej rocnikovej praci cca rok dozadu... oproti tomuto som pouzil len male zmeny (inac nadava sa tomu udajne aj challange-response autentification):

- pre kazdy session som si drzal jeden tzv. certifikat, ktory sa po kazdom pokuse o autentifikaciu v danom sessione okamzite znehodnotil a nahradil novym - nutne z dovodu zabranenia replay utokom
- namiesto obycajneho hex_md5() som pouzil md5_hmac. Rozdiel je asi taky, ze md5() hashuje retazec za pouzitia jeho dlzky ako hashovacieho kluca, zatial co md5_hmac() umoznuje ako hashovaci kluc pouzit cokolvek. Ja som ako hashovaci kluc pouzival certifikat. Preco? Lebo je to jednoducho bezpecnejsie, ako plain md5.

pri zmene hesla je mozne pouzit javascriptove implementacie nejakych asymetrickych sifrovacich algoritmov, ako napriklad gpg, alebo RSA, aby bolo heslo zasifrovane pred prenosom a desifrovane az na serveri.

tento mechanizmus ale neriesi man in the middle attack ani v jednom pripade




00000101007920110266395402663960026641280266917702669200
mx
 mx      03.10.2006 - 20:33:50 , level: 1, UP   NEW
mno, tak postupne:
1) tvoje certifikaty su nieco ako mnou navrhovane jedinecne zaznamy v databaze, teda, ak predpokladam, ze hned po refreshi stranky (teda, po autentifikovani) sa zaznam zmaze (a ked ho naviazes na ip adresu, tak to obmedzis este viac)
2) hex_md5 som pouzil preto, lebo som v danom momente nasiel ako prvu hex_md5 javascript implementaciu (kedze som to cele zbuchal za nejaku hodinu aj s cestou (myslim to demo)), ale uznavam... anyway, kolizii md5ky doteraz bolo najdenych malo, i ked boli ... ak tou nebezpecnostou myslis to
3) man in the middle - zabranis kazdopadne tomu, aby bolo heslo exposnute v plaintexte komukolvek, tzn, ze aj pri MITM dostane utocnik len md5hash hesla + challenge, pri rozumne zvolenom challenge moze skusat myslim, ze do smrti, problemy s odchytenim paketov vsak neriesi, transport layer nie je sifrovany

kazdopadne dobre pripomienky, nesnazil som sa robit mudreho, len mi to pride ako dobra alternativa ku klasickej plaintext autentifikacii a je velmi jednoducha na implementaciu a imho zvysuje bezpecnost systemu dost vyrazne

0000010100792011026639540266396002664128026691770266920002669507
ventYl
 ventYl      03.10.2006 - 23:07:49 , level: 2, UP   NEW
doteraz tych kolizii bolo sice najdenych malo, ale tunely v md5 existuju a masivne znizuju nekolizovatelnost md5 ako takej, pouzitie hmac dava vacsie spektrum moznosti a minimalne zvysuje rozstrel hodnot a ich variabilitu.

ono naozaj v tomto pripade ide hlavne o to, aby nebolo exposnute heslo, nakolko man in the middle attack je v tomto okamihu absolutne zbytocny a je asi tak na urovni obycajneho pasivneho sledovania. v suvislosti s tym ma napadla taka vec, ako by mohli byt napriklad untheftable sessions... je to iba zatial iba v rovine idey, ale principialne by to mohlo fungovat takto (ak nebude zadrhel s cookiesami).

povedzme, ze pomocou javascriptu si zadefinujeme pre nejaku neexistujucu cast nasho webu cookie (tym zabezpecime, ze sa cookie nebude posielat na server nikdy).

nasledne po prihlaseni pouzijeme nejaky algoritmus (napriklad md5_hmac(md5(heslo), sess_key), ktorym si vygenerujeme session vector. sess_key mu bude poslany zo servera. tento vector ulozime do tejto cookie, ktora sa nikdy neposiela (ale dufam, ze sa aspon da pomocou JS vybrakovat z prehliadaca, ak nie, tak smola, vykonat sa to neda).

po prihlaseni by sa rovnaky proces spravil aj na serveri (ten ma uz v DB ulozenu md5 hodnotu hesla, cize mu staci spravit md5_hmac(md5_hesla, sess_key).

a princip neodcudzitelnosti sessionu by spocivalo v tom, ze:
pri kazdom posielani formularu by sa vykonala nejaka operacia so session vectorom tak, aby ju nebolo mozne bez hesla predpovedat (mozno by sa dal pouzit algoritmus RC5) a tato hodnota by sa ulozila do skrytej cookie a vysledna hodnota by sa pribalila k formularu. na serveri by sa po prijati formularu vykonalo to iste, ak by server nedosiel k rovnakemu vysledku manipulacie s vectorom, ako je uvedene vo formulari, request by ignoroval, v opacnom pripade by si zmeny poznamenal a request by spracoval.

zadrhele:
1) nie je zname, ci je mozne takto ulozit cookie a zabranit tomu, aby sa posielala
2) momentalne ma nenapada ziadny algoritmus, ktory by umoznil synchronizaciu klienta a servera bez toho, aby bolo medzi nimi nutne prenasat nejake inicializacne udaje (ale tu RC5 by pouzit slo, u wifi je sice nachylna na prelomenie, ale potrebnych pol miliona requestov sa nedosiahne u tohto typu komunikacie)
3) v pripade veci, ako zrusenych requestov, padnuteho spojenia a podobne, by dochadzalo k desynchronizacii klienta, cize by asi bolo vhodne prenasat spolu so spojenim aj nejake inicializacne vektory, alebo nieco take, popripade implementovat restart poziadavky...

je to len kusa idea a napadla ma len tak mimochodom...

000001010079201102663954026639600266412802669177026692000266950702669571
mx
 mx      03.10.2006 - 23:35:54 , level: 3, UP   NEW
no, spoliehat sa pri autentifikacii na javascript je v principe nebezpecne, donutis tym uzivatela akceptovat tvoje poziadavky ... potom by sa dalo pokojne spravit aj take, ze si spravis jeden skryty frame, ktory nikdy nebudes refreshovat a riesis vsetky veci s modifikaciou nejakeho tokenu tam.
potom by to bolo - ak ma o pol dvanastej moj mozog neklame - celkom jednoduche
na strane klienta nechas bezat generator tokenu, ktory bude mat v pamati plaintext heslo (na klientskej strane, neprenesie sa nikdy po sieti) a stranka si ho z druheho frame vzdy pred submitom vyziada, spracuje do nejakej podoby a odosle naspat serveru ...
-- tuto som zmazal niekolko riadkov a zacal rozoberat inu uvahu, takze ak to bude nekonzistentne s uvodom, tak sorry --
co tak md5() poctu odoslani dat na server?
server vie, kolko ich je, lebo vie session id a klient si ich vie pocitat pri odosielani
samozrejme, problem rozsynchronizovania tam nastava, pokial sa stane nieco s linkou a tym padom by doslo k logoutu, ale to je dan za bezpecnost
toto je take jedno jednoduche riesenie, co ma napada momentalne