Neco lepsiho nez md5

Non_E: "když je podepsán cekitem, což není žádná certifikační autorita?" Certifikační autoritu ti může udělat jakýkoliv server (jenom sám sobě server CA být nemůže), takže cekit.cz certifikační autoritou je, teď jenom jde o to, jak důvěryhodnou.

peta: Aha, takže v tom mám zase bordel :)
Původně jsem si myslel, že už jsem to pochopil, ale asi nee. Myslel jsem si, že když se uživatel registruje, tak se mu heslo do DB uloží jako md5($heslo).$IP , což by vedlo k tom, že pokud se uživatel přihlásí z jiné IP než z té, z které se registroval, tak ho to nepustí i když zadá správné heslo. Což asi bude blbost :(
Já nevím, jestli jsem natvrdlej, ale asi to bez příkladu nepochopim ;)

Tom (manual.wz.cz)
:)))
tak jinak. Kontrola na IP je volitelna polozka. Uzivatel az po registraci, pri novem prihlaseni zvoli, zda se ma ci nema kontrolovat i IP.
// login
S[ip] = (G[ip] == 1) ? $ip : "";
// overeni
(DB[heslo].$ip == S[heslo].S[ip])

G - get
S - session
DB - udaj s databaze
$ip = getIP() zjisti aktualni IP

cili pokud ukradnes session a nemas stejnou IP, tak je ti to prd platne. Samozrejme jsem pouzil scitani a je mozne do session dat jen ip = 1/0 a ip prisifrovat k heslu md5(), treba. To jen, abys to pochopil.

Tak podobne se generuje ten overovaci kod.
Vygenerujes kod, zapises jej do formulare do skryteho inputu, zapises jej do databaze a pokud se neshoduji, tak at jde utocnik do haje. Bohuzel toto reseni muze v pripade rychle akce utocnika zablokovat praveho uzivatele.
Ale mozna jsem videl nejake lepsi reseni s timto kodem, jen to nepouzivam, tak mi to vypadlo. Tusim na interval.cz

Tom: No hlavně, že jsme si rozuměli. Já nemyslel ani tolik ca v technickém smyslu jako institucionálním. A ani tak cekit afaik nezveřejnil svůj veřejný klíč.

Peta: to by tam muselo být víc jak 10MB místa (teď zabírám asi 40MB) a pak bych chtěl stejnou adresu jak teď.

peta:
>>Ten parazitni program lze zavesit na tvuj komp a odchytavat, co do stranky vyplnujes, pripadne, jake mackas klavesy.

nejak mi unika co ma keylogger spolecnyho se zabezpecenim https, ale to uz mas jedno.

a ten tvuj postup s IP adresou ma jednu hodne nedomyslenou vec.
-jsem doma,zaregistruju se, a pri prvnim prihlaseni si zvolim ze chci i zabezpeceni pomoci IP.
- pak pudu nekam jinam (do prace apod), budu se chtit prihlasit, ale protoze budu mit jinou IP tak to podle tvyho principu nepude, protoze ty IP michas s MD5 hesla,...
proste nedomysleny

kontrola IP je dobra vec, ale musi to bejt jenom upozorneni, kdyz se prihlasis z jiny IP nez bezne, pripadne ze se tvoje IP lisi od IP posledniho prihlaseni. ale zase to musi bejt uporozneni kteryho si clovek vsimne

No s Ip adresou je to myslim zbytecne, nakolko ludom nedokazes vysvetlit rozumne o co ide... A stejnak vacsina ludi ma DSL-ko a to znamena ze maji porad jinou IP adresu hoci sedi doma u sviho compu... Takze kdyby to user s DSL inerentem omylem zaskrtnul (kontrola pomoci IP), tak zrejmne uz nikdy by se nelognul... Mala pravdebodobnost aby dostal opet stejnou IP jako mnel pri zaskrtavani... To by mu zabralo casu... kdyby chcel skouset...
Takze vazat heslo na IP urcite nema zmysl. Vice skody nez uzitku - non user friendly!

Něco lepšího jak md5? Co md6 :-)) ?
někde jsem četl, že se md5 dá rozumně rychle "prolomit", tedy najít řetězec, pro který dává stejný hash jenom pro krátká jednoduchá hesla. Pokud zvolíte heslo jako "Cosi_Hnusneho1#", tak jsem ochoten tvrdit, že nalezení řetězce, který generuje stejný hash přes md5 bude trvat určitě déle jak pár minut. Schválně to zkusím.

Mike (specialfx.xf.cz)
Pokousim se to vysvetlovat Tomovi. On to snad uz pochopil.
Ted jeste tobe, boze :)
Prostuduj si mou minulou zpravu. Jde o to, ze v databazi mas heslo ulozene BEZ IP. Tu tam primichavas az pri kontrole a porovnavas ji s IP se kterou se uzivatel prihlasil NIKOLI REGISTROVAL.
Cili, kdyz to odchyti nekdo s notebook a nemali stejnou ip, tak se neprihlasi, protoze mas zakstle porovnavani IP pro to jedno konkretni prihlaseni.
Tys to jeste nevidel? www.rd2.cz
Nicmene kvuli uzivateli muzes vytvaret log cas a ip poslednich 5 prihlaseni, treba.

4-b.xf.cz (4-b.xf.cz)
Nic nevysvetlovat, proste default to nechas checked a do napovedy doplnis, ze kdyby jim neslo se prihlasit, muzou to odskrtnout.

Jo, jeste jsem se chtel zeptat: kdyz si to heslo poslu na nejakej php skript pres html formular, tak se to heslo posle nesifrovany a da se to nejak odposlechnout, je to tak? Jak to teda mam udelat, aby se poslalo uz zasifrovany?

pouzijes sifrovany prenos pomoci protokolu https (s tim ale na WZ nepochodis)

ChristmasPoo: to jsem tady řešili posledních 30 příspěvků: buďto HTTPS (což, jak pravil Mike je na WZ bez šance), nebo to heslo zašifruj u uživatele pomocí JS, ale to odradí maximálně tak těžký amatéry :)

Trošku jsem nad tím přemýšlel a jediný co mě napadlo a je jakž-takž spolehlivý, že heslo bude pouze číselné (nazývejme jej "H"), server uživateli vygeneruje nějaké jedinečné číslo (třeba "X") a při odeslání se pomocí JS provede například logX H a odešle jej místo původního hesla. Protože server bude vědět, co se u uživatele dělo a má k dispozici ty samé údaje (X má například v session) provede nějaký zpětný přepočet a heslo porovná s DB.

Tom (manual.wz.cz)
"provede nějaký zpětný přepočet a heslo porovná s DB"
tak o tom se tu tez celou dobu bavime, jako :)
existuje JS ktery vytvari SHA1 nebo MD5 hash, dokonce RSA.
a propo, kdyz uz heslo zasifrujes logaritmem, proc udaj z DB nezasifrujez timtez a pak porovnas 2 logaritmicke cisla. Nebo to muzes zpetne desifrovat, mno :)

peta:
ale, vždyť jo =)
jenom u toho šifrování pomocí MD5, SHA1 a spol je ten problém (jak jsem psal výše), že pokud to někdo zachytí, tak mu bude okamžitě jasný, že nikdo není tak blbej, aby měl jako heslo např. a82c8a9f536794df3d36cdc001f583f4 , že půjde o nějaký HASH. Tudíž mrkne na formulář a hned zjistí, která bije ;)
To, co jsem navrhoval já, má výhodu v tom, že pokud bude heslo pouze z čísel a bude se "nějak" přepočítávat (třeba tím logaritmem) podle náhodně vygenerovaného čísla ze serveru, bude mít potencionální útočník dost slušně ztíženou pozici (i když bude vědět, jak se heslo u uživatele přepočítává) a aby rozlousknout původní heslo bude přinejmenším hodně složité a časově náročné (při dostatečné délce hesla)

Tak to jo... ja jsem to myslel spis nez zasifrovany pres to https jako ze se to posle na server zasifrovany pomoci toho md5 treba, chapes. Po http. Ze kdybych to tam nejak zretezil treba s tim loginem a nebo si s tim jinak pohral, jak to tu nekdo navrhoval, ze pak uz by to nebylo asi jednoduchy zjistit. No to je jedno, jestli to jde takhle jenom pomoci JavaScriptu a jestli to taky neni velkej problem zjistit, tak se s tim nebudu stvat, jen me to zajimalo, diky.

to 4-b.xf.cz:(asi 10 prispevkov vyssie): ja som to nelamal ces bruteforce, nesom blb :), vtedy by sa luskanie 5 znakoveho hesla este dalo spravit do hodiny 6znakoveho do 10 hodin 7 znakoveho do 2 dni(tym ti aj odpovedal na otazku, ze keby si dal dlhsie heslo, jeho luskanie by bolo nemozne), ale isiel som na to ces databazu hashov(skus vygooglit seekhash), je to databaza cca 300 000 hashov a medz nimi sa nachadzal aj hash tvojho hesla :)

tom@sQo: "vtedy by sa luskanie 5 znakoveho hesla este dalo spravit do hodiny 6znakoveho do 10 hodin 7 znakoveho do 2 dni(tym ti aj odpovedal na otazku, ze keby si dal dlhsie heslo, jeho luskanie by bolo nemozne)"
Kdyby tohle platilo, tak by bylo MD5 absolutně nejlepší komprimační nástroj, který kdy existoval, protože by z libovolně dlouhého řetězce udělal 32 znakový hash ;)
Podle mě je při použití správných metod úplně jedno, jestli je heslo 5 znakové, nebo 1000 znakové. Tobě totiž nejde o původní heslo, ale o kolizní řetězec (viz výše ;)

Tom (manual.wz.cz)
"
MD5 absolutně nejlepší komprimační nástroj, který kdy existoval, protože by z libovolně dlouhého řetězce udělal 32 znakový hash ;)
"
Mnooo, ono to tak v podstate je, jen pro urcitou dekomprimacni metodu by musel vyjit prvni kolizni retezec prave ten, ktery jsi sifroval.
Takze v podstate muzes na konec pridavat znaky tak, aby prvni kolizni vysel ten tvuj a pak poznacit, kolik znaku jsi pridal. Pokud mas oba algoritmy, tak to neni tak obtizne zprogramovat.

peta: "Mnooo, ono to tak v podstate je". Takže načtu 10MB soubor do proměnné, proženu ho MD5kou a pošlu jej bez problémů v SMS jako 32 znaků. Potom to adresát přepíše do programu na "lámání" MD5ky a dostane několik kolizních řetězců, mezi nimiž i můj 10MB soubor! Hmm ... Čéče, tohle je průlom v historii komprimace dat ;) Končím s tar.bz2 a přecházím na MD5 =D

Tom (manual.wz.cz)
to je pravda, ty muzes misto pridavani znaku zaznamenat jenom, kolikata kolize je ten retezec.

peta (peter-mlich.wz.cz):

Ale z haše můžeš dostat nekonečně mnoho řetězců, ne? A kdybys někde zaznamenal kolikátá kolize je ten řetězec a pak ho podle toho chtěl najít, tak to bys ty řetězce musel mít v nějaké databázi, ne? A když vezmu, že by tam byly i 10MB řetězce, tak to by musela být teda hodně velká databáze. Teda podle mýho názoru a podle toho co o tom vím. Možná jsem nějakej fakt přehlídl a kecám...

idealni je pouzit nejdrive crypt(); a nasledne md5();

ChristmasPoo (oktavab2004.unas.cz)
"tak to bys ty řetězce musel mít v nějaké databázi, ne?"
To je prave ten pristup, zes zatim nic takoveho neprogramoval.
Ano, pro rychlou dekompresi bys musel mit databazi hashu, coz v dnesni dobe neni takovy problem. Jmenuje se to slovnikovy pristup. najdes slovicko s cislem poradi a mas hned vysledek. Dekomprese ze 16B na 10MB za vterinu :)

Ale ty tu databazi muzes generovat kolidnim algoritmem. ktery bys musel mit ale presne stejny, jako u komprimacniho programu, kde zjistuje poradi kolizniho retezce.

Uvažoval som nad bezpečným riešením prenosu citlivých údajov pomocou šifry RSA (verejný a privátný kľúč). Napríklad. užívateľ chce odoslať na server svoje heslo. Najprv len požiada server o verejný kľúč vygenerovaný php skriptom. Po tom čo dostane tento kľúč, prichádza na rad JavaScript, ktorý heslo zadané užívateľom pomocou tohoto kľúča zašifruje a zašifrované pošle na server, kde nejaký iný php skript pomocou svojho privátneho kľúča heslo dešifruje, prípadne ho zašifrované uloži do DB a dešifruje a použije až pri prvom prihlásení užívateľa. Analogicky by sa dalo postupovať v smere server - - > klient Už ostáva len maličkosť napísať tieto skripty v php a JavaScripte :-) A ešte jeden maličký problém: výpočtová náročnosť. Neviem ako sú na tom obidve jazyky, ale predpokladám, že asi nebudú vhodné pre náročné matematické výpočty.
Vygooglil som jeden taký program v JavaScripte, ale problém je, že generovanie kľúča má na starosti program (asi to bolo Delphi), ktorý vygeneruje jednak kľúče, jednak aj JS kód, ktorý sa potom musí ručne doplniť do skriptu. Ináč ,ak zvolíte 1024 bitový kľúč, aj tomu Delphi to trvá niekoľko desiatok sekúnd. Aký je váš názor na takéto riešenie? Bola by to vhodná úloha napríklad pre Javu (applet)? To by bolo na strane klienta, ale ako by sa to na strane servera dalo, to už netuším.

peta: co já vím, tak slovníkové útoky (nedejbože útoky hrubou silou) na MD5ku a spol. jsou již dost slušně zastaralé. Dnes se využívá tzv. tunelování, kdy se podle struktury HASHe vygeneruje řetězec, jehož hash je shodný s původním HASHem.
"Dekomprese ze 16B na 10MB za vteřinu :)" je podle mě s prominutím pitomost, protože taková DB, u které by jsi měl alespoň 50% jistotu, že narazíš na původní řetězec by měla pěkných pár (set ? ) TB, což za vteřinu prohledat nezvládneš ani na moderních strojích.
A ještě jeden aspekt, který jsi patrně vynechal: pokud takto "zkomprimuji" 10MB soubor, tak jak ty poznáš, že jsem ti v těch 32 znacích poslal 10MB soubor a ne nějaké pětimístné heslo? Hm... ?

barguzin: o něčem podobném jsem psal o nějakých 10 příspěvků výše. Klidně bych to zrealizoval, ale s JS neumím a tudíž nevím, jak "zašifrovat" jeden řetězec druhým :( U hesel obsahující 0-9 to není problém, tam se provede nějaké to + - * / a spol a je klid, ale u hesel s obsahem a-z,A-Z,0-9+spec znaky je to celkem problém ;)

Tom (manual.wz.cz)
Ja si tu porad pripadam, s prominutim, za pip. Porad pisi dokola totez, uz asi 10ty prispevek.
"jak ty poznáš, že jsem ti v těch 32 znacích poslal 10MB soubor a ne nějaké pětimístné heslo?"
A ja psal, kdyz mas stejny algoritmus pro detekci pri kompresi jako pro detekci pri rekonstrukci, tak 100% dostanes stejny vysledek.
Takze priklad
y = x*x + x //nejaky neznamy algoritmus
y = 30
Newtonovuv algoritmus:
x = 1 / L = 30 / P = 1*1+1 = 2 // L>P x+5;
x = 6 / L = 30 / P = 6*6+6 = 42 // L<P x=je mezi 1 az 5, volim 2
...
az do 6
Pocet kroku je 6, 10M jsem zasifroval na 30|6 sifra|id reseni. V 6stem kroku dosahnu reseni. z toho vyplyva, ze at uz mas moznych kolizi treba milion, tak je dost pravdepodobne, ze md5(10MB)+id (cili poradi ve vygenerovanych resenich) bude stale o moc mensi cislo nez 10MB, protoze v kazdych 100 reseni bude asi jen 5, rekneme.

Nevim, jak to lepe popsat, uz mi takove otazky nedavejte a vrhnete se na moderatory, 70 prispevku je fakt sila zobrazovat.

peta (peter-mlich.wz.cz):

A ty myslíš, že i když to uděláš pomocí těch stejných algoritmů, tak ti to vyhodí jenom jeden kořen (původní řetězec)? Podle mě je nereálný zašifrovat obousměrně 10 000 000 (a nějaký drobný) bytů do 32 bytů. Tam určitě musí dojít k nějakým ztrátám. Tak kdyžtak zašifruj nějaký 10MB video, hoď sem ten 32 bytovej řetězec a pošli ten prográmek a já to zkusím rozjet;-)

Webzdarma zvládnete to sami

Nové příspěvky