cwbe coordinatez:
101
792011
2663954
2663960
2664128

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::2
7 ❤️


show[ 2 | 3] flat


dio0
Jay0
piece_of_IT0
space.pussy0
Keram0
peter.parker0
Refresh0
este jeden, uz velmi technicky clanok, ako objasnenie autentifikacie, ktora bola pouzita v predchadzajucej demonstracii.
Taktiez je k dispozicii krajsia PDF verzia: http://www.hudak.info/kyb-crammd5.pdf




Implementácia CramMD5 autentifikácie


PHP / JavaScript

mx, 2006-10-01


Úvod


Základný problém prihlasovania sa cez http protokol (pri absencii https), prípadne pri prihlasovaní sa na služby tretích strán, je možnosť odchytenia plaintext hesla, či už na strane poskytovateľa internetového pripojenia (prípadne na trase od klienta na server), alebo priamo na serveri zo strany implementátora služby.


Riešením by bolo, neprenášať heslo v plaintext tvare a tým zamedziť uloženiu a následnému zneužitiu hesla.



Teoretické východiská


CramMD5 autentifikácia je založená na predspracovaní hesla na strane klientskej stanice. Základom je skriptovací jazyk (najčastejšie použitý JavaScript), ktorý vytvorí na základe vstupných dát poskytnutých serverom MD5 hash, ktorý sa použije na porovnanie hesla na strane serveru. Tento hash sa potom prenesie v plaintext forme nezašifrovanou linkou a tým zamedzí odchyteniu plaintext hesla. Takýto hash je potom v závislosti na implementácii platný pre dané spojenie, prípadne obmedzený aj špecificky na IP adresu.



Implementačné detaily


Riešenie CramMD5 autentifikácie sa skladá z klientskej a serverovej časti.



Klientská časť


V prípade, že nie je používateľ autentifikovaný, zobrazuje sa – ako v každej klasickej webovej aplikácii – prihlasovací formulár. V prípade CramMD5 autentifikácie je rozšírený o niekoľko skriptov a skryté polia, obsahujúce kontrolné informácie. (Ako konkrétne príklady implementácie použijem zdrojový kód demonštrácie sociálnych sietí.)




<form action="" method="POST" onSubmit="return (SecOnSubmit())">

    <b>ID: </b><input name="sec_login" />

    <b>PWD:</b><input id="SecPwd" name="sec_password" type="password" />



    <input id="SecCraMD5" name="sec_cramd5" value="0" type="hidden" />

    <input id="SecCraMD5Hash" name="sec_cramd5_hash" value="<?php echo md5(uniqid(rand(), true)); ?>" type="hidden" />


    <input type="submit" value="Submit Credentials" />

    

    <script language="JavaScript"><!--

        // will hide the warning if javascript enabled and sets sec_cramd5 to 1

        document.getElementById('SecCraMD5').value = '1';

    //--></script>

</form>



Okrem vstupných polí sec_login a sec_password môžeme vidiet aj skryté polia sec_cramd5 a sec_cramd5_hash. Ich význam je nasledovný:



  • sec_cramd5 obsahuje informáciu o dostupnosti CramMD5 mechanizmu. Použije sa pritom jednoduchý trik s nastavením hodnoty poľa pomocou JavaScriptu. V momente, ked JavaScript nastaví pole na hodnotu „1“, môžeme si byť istí, že JavaScript je dostupný a CramMD5 autentifikácia bude použitá.

  • sec_cramd5_hash je hash, ktorý generuje server unikátne pre každé zobrazenie login formuláru. V tejto implementácii je použitý jednoduchý model, ktorý dovoľuje potenciálnemu útočníkovi zachytiť aj tento hash a poslať ho spolu s odchyteným MD5 hashom hesla na server, čím ho samozrejme autentifikuje. Pokiaľ by sme mali záujem o vyššiu úroveň bezpečnosti, môžeme do sec_cramd5_hash zaobaliť informácie o session vygenerovanej na serveri a po prihlásení túto session zrušiť, čím sa už ďalší používateľ s týmito informáciami neprihlási. Taktiež do hashu vieme zaobaliť IP adresu počítača, z ktorého klient stránku vyžiadal (čo môže byť problematické pri firemných sieťach s proxy servermi).



Po odoslaní takéhoto formulára sa vykoná onsubmit handler SecOnSubmit(), ktorého zdrojový kód vyzerá nasledovne:



function SecOnSubmit() {

    var pwdObj = document.getElementById('SecPwd');

    var hashObj = document.getElementById('SecCraMD5Hash');

    

    pwdObj.value = hex_md5(hashObj.value + hex_md5(pwdObj.value));

    return (true);

}



Je to multiplatformový JavaScript kód, ktorý zozbiera informácie z formulára, zavolá externý skript, ktorý vygeneruje MD5 hash z vložených údajov a prepíše výsledkom pole password vo formulári. Týmto postupom si zabezpečíme, že v prípade funkčnosti CramMD5 autentifikácie prejde z poľa sec_password len náš hash a v konečnom dôsledku si uľahčíme spracovanie na strane serveru.


V prípade, že CramMD5 nie je podporovaný, handler sa nevykoná a na server je poslané plaintext heslo taktiež cez pole sec_password spolu s informáciou v sec_cramd5, že autentifikácia nie je podporovaná.



Serverová časť



<?php

    
include_once dirname(__FILE__).'/passwordList.class.php';



    class
ESecException extends Exception { /* blank */ }


    

    class
CSec {

        static public function
authenticate

            
($in_PwdFile, $in_ID, $in_Password, $in_CraMD5, $in_CraMD5_Hash) {


        

            
$pwd_Hash = CPasswordList::getPasswordById($in_PwdFile, $in_ID);

            if (!
$pwd_Hash) throw new ESecException('User unknown.');


            

            if (
$in_CraMD5 == '1')

                
$sec_Hash = CSec::generateCraMD5Hash($pwd_Hash, $in_CraMD5_Hash);

            else {


                
$sec_Hash    = $pwd_Hash;

                
$in_Password = md5($in_Password);

            }

            

            return (
$sec_Hash == $in_Password);


        }

        

        static public function
generateCraMD5Hash($in_Pwd_Hash, $in_CraMD5_Hash) {

            return (
md5($in_CraMD5_Hash.$in_Pwd_Hash));

        }


    }

?>




Serverová časť je – ako vidieť na listingu – v tomto prípade veľmi priamočiara, na základe kontrolných údajov vyberie vhodnú metódu autentifikácie a vytvorí požadovaný porovnávací hash. Následne vo výsledku volania funkcie rozhodne o zhode / nezhode hashu a pošle logickú informáciu ako výsledok. Prihlasovací mechanizmus následne rozhodne o ďalšom postupe.


V tejto časti môže byť taktiež implementované bezpečnostné vylepšenie, napríklad kontrola IP adresy, alebo spolupráca s databázou, alebo sessions.



Využitie mechanizmu


CramMD5 nájde uplatnenie všade tam, kde je podstatná bezpečnosť hesiel a istota používateľov aj bez možnosti preskúmať serverovú časť aplikácie. Technológia zabezpečí, že pri splnení všetkých požiadaviek, nie je používateľovo heslo odosielané na server v žiadnom prípade (pokiaľ nie je požiadavka na zmenu hesla, v tom prípade je nutné posielať toto heslo minimálne v tvare MD5 hashu na uloženie do databázy).






000001010079201102663954026639600266412802669177
ventYl
 ventYl      03.10.2006 - 20:24:28 , level: 1, UP   NEW
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: 2, 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: 3, 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: 4, 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

000001010079201102663954026639600266412802665512
prufrock
 prufrock      02.10.2006 - 11:15:17 , level: 1, UP   NEW
Napadá mě amatérský způsob jak "udělat" autentifikaci(?? pojem) - tedy jak přihlásit uživatele xy k serveru bez nutnosti posílat heslo jako plaintext: generování nějakého hashe díky algoritmu co bude počítat hash z hesla a času (např. GME převedeno na minuty) na straně jak serveru tak klienta. Problém je synchronizace... Hmm určitě to lze i jinak... Tohle co tady popisuješ je něco co se standardně používá?

00000101007920110266395402663960026641280266551202665538
mx
 mx      02.10.2006 - 11:25:57 , level: 2, UP   NEW
to co si opisal je vlastne variacia na to, co tu popisujem
(a ten cas robit netreba, riesenim je session v databaze platna presne na jeden login)
toto co popisujem sa pouziva, nevymyslel som to ja, len som to nikde nevidel pekne vysvetlene aj s prikladmi a par ludi sa ma pytalo, co je to zac :)

0000010100792011026639540266396002664128026655120266553802669509
ventYl
 ventYl      03.10.2006 - 23:08:46 , level: 3, UP   NEW
tento mechanizmus je popisany na root.cz

000001010079201102663954026639600266412802665512026655380266950902669577
mx
 mx      03.10.2006 - 23:40:22 , level: 4, UP   NEW
ten geekovsky linuxovo onanisticky platok som prestal citat uz davno :)