cwbe coordinatez:
101
792011
2663954
2663960
2664128
2669177
2669200

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
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: 1, 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: 2, 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