Plaintext hesla jsou bezpečnější než hashe?

[gazda]

To tvrdí pán DgBd v http://forum.root.cz/index.php?topic=3431.msg28661#msg28661 , kde je to off topic.
Prosím jeho, alebo kohokoľvek iného, aby mi z hľadiska bezpečnosti vysvetlil výhody ukladania plaintext hesiel oproti asysmetrickému šifrovaniu.
Ďakujem.

[Reklama]

[DgBd]

To tvrdí pán DgBd v http://forum.root.cz/index.php?topic=3431.msg28661#msg28661 , kde je to off topic.
Prosím jeho, alebo kohokoľvek iného, aby mi z hľadiska bezpečnosti vysvetlil výhody ukladania plaintext hesiel oproti asysmetrickému šifrovaniu.
Ďakujem.

Ale tak ta otázka nestála. Byl to rozdíl mezi hashovaným heslem a plaintext heslem, kde je plaintext (potenciálně) bezpečnější.

[DgBd]

To tvrdí pán DgBd v http://forum.root.cz/index.php?topic=3431.msg28661#msg28661 , kde je to off topic.
Prosím jeho, alebo kohokoľvek iného, aby mi z hľadiska bezpečnosti vysvetlil výhody ukladania plaintext hesiel oproti asysmetrickému šifrovaniu.
Ďakujem.

Jestli si nepleteš hashe a asymetrickou kryptografii.

[branchman2]

Vyhody plaintextu oproti asymetrickej sifre? Napadaju ma tieto:
-jednoduchsia obnova v pripade vacsieho poskodenia diskov
-overovanie nepotrebuje ziadnu SW podporu
-naprogramovanie je jednoduchsie
-program sa lahsie testuje
-mensie riziko backdooru v kode
-mensia zataz systemu

A este bonus
-nikto nemoze ukradnut privatny kluc

PS: inak som proti plaintextu (aj ked nepouzivam asymetricku kryptografiu, ale hashujem), ale v istych situaciach sa hodi aj plaintext. Napriklad ked som kedysi davno robil domacu ulohu v Pascale, tak som nemal problem pouzit plaintext na overovanie uzivatela.

[gazda]

Jestli si nepleteš hashe a asymetrickou kryptografii.

Prosím, aby ste mi vykali.
Domnieval som sa, že výrazy "zahashovať" a "asymetricky zašifrovať" v kontexte ukladania hesiel možno považovať za synonymá. Je možné, že som sa mýlil.

[Reklama]

[DgBd]

Jestli si nepleteš hashe a asymetrickou kryptografii.

Prosím, aby ste mi vykali.
Domnieval som sa, že výrazy "zahashovať" a "asymetricky zašifrovať" v kontexte ukladania hesiel možno považovať za synonymá. Je možné, že som sa mýlil.

vykají smajlík.

Ano, zahashovat a asymetricky zašifrovat jsou dvě naprosto odlišné disciplíny.

[Mirek Prýmek]

Ale tak ta otázka nestála. Byl to rozdíl mezi hashovaným heslem a plaintext heslem, kde je plaintext (potenciálně) bezpečnější.

Shodneme se na tom, že definice "A je bezpečnější než B" je "B je vystaveno stejným rizikům jako A a alespoň jednomu navíc"?

Jaké riziko navíc má hashované heslo oproti plaintext heslu?

A opravdu neexistují žádná rizika, kterým je vystaveno hashované heslo a není vystaveno heslo plaintextové?

[gazda]

Vyhody plaintextu oproti asymetrickej sifre? Napadaju ma tieto:
-jednoduchsia obnova v pripade vacsieho poskodenia diskov
-overovanie nepotrebuje ziadnu SW podporu
-naprogramovanie je jednoduchsie
-program sa lahsie testuje
-mensia zataz systemu

To nie sú výhody, ktoré možno považovať za výhody z hľadiska bezpečnosti.

-mensie riziko backdooru v kode

Prosím vysvetliť.

A este bonus
-nikto nemoze ukradnut privatny kluc

To je pravda, ale ťažko to považovať za výhodu. Je dom bez zámkov oproti uzamykateľnému bezpečneší preto, lebo nemožno ukradnúť kľúč?

PS: inak som proti plaintextu (aj ked nepouzivam asymetricku kryptografiu, ale hashujem), ale v istych situaciach sa hodi aj plaintext. Napriklad ked som kedysi davno robil domacu ulohu v Pascale, tak som nemal problem pouzit plaintext na overovanie uzivatela.

Iste, nie každé dvere treba zamykať. V pôvodnom vlákne išlo o systémy registrátorov domien. Pri nich je bezpečnosť dôležitá.

[DgBd]

Ale tak ta otázka nestála. Byl to rozdíl mezi hashovaným heslem a plaintext heslem, kde je plaintext (potenciálně) bezpečnější.

Shodneme se na tom, že definice "A je bezpečnější než B" je "B je vystaveno stejným rizikům jako A a alespoň jednomu navíc"?

Jaké riziko navíc má hashované heslo oproti plaintext heslu?

A opravdu neexistují žádná rizika, kterým je vystaveno hashované heslo a není vystaveno heslo plaintextové?

U hashovaně uloženého hesla musíte heslo přenést přes linku, čímž ho vystavujete riziku odposlechnutí. U plaintext hesla se použije výzva-odpověď, takže útočník nezíská nic užitečného.

[branchman2]

Domnieval som sa, že výrazy "zahashovať" a "asymetricky zašifrovať" v kontexte ukladania hesiel možno považovať za synonymá. Je možné, že som sa mýlil.

Synonyma? Asymetricky zasifrovane heslo sa da vhodnym klucom jednoznacne desifrovat na povodne heslo. Neexistuje tu nieco ako kolizia.
Ako sifrovanie (aj ked nie asymetricke) si mozes predstavit to, ze by sa kazde pismeno abecedy posunulo o znak dalej (z by islo na a). Existuje cesta spat, ale kto o nej nieco nevie, tomu zasifrovane heslo nic nepovie.

U hashu nutne existuju kolizie, lebo neobmedzene velka mnozina hesiel sa hashuje na nieco pevnej dlzky (ak by kolizie neexistovali, tak mame velmi efektivnu kompresiu). Z hashu sa neda rekonstruovat povodne heslo a vela hashov je robenych tak, aby bolo tazke zistit lubovolny retazec, ktory sa na ne zahashuje (tj. su kryptograficky bezpecne).
Ako hash si mozes predstavit spocitanie poctu vyskytov jednotlivych pismen s tym, ze heslo musi byt zo slovnika. Neexistuje tu moznost dostat sa priamo k povodnemu heslu, ale tomuto by zase vyhovelo aj heslo s poprehadzovanymi pismenkami.

PS: viem, ze tie priklady nie su velmi dobre; kto ma lepsie (pochopitelne aj pre zaciatocnika), ten nech ich sem da.

[DgBd]

Ale tak ta otázka nestála. Byl to rozdíl mezi hashovaným heslem a plaintext heslem, kde je plaintext (potenciálně) bezpečnější.

Shodneme se na tom, že definice "A je bezpečnější než B" je "B je vystaveno stejným rizikům jako A a alespoň jednomu navíc"?

No, asi ne :-) Já bych to viděl jako seznam všech potenciálních rizik váhově oceněných. A je bezpečnější než B v případě, suma_vah(A)<suma_vah(B). A a B totiž nemusí být podmnožiny jedna druhé.

[branchman2]

-mensie riziko backdooru v kode

Prosím vysvetliť.

V 10 000 riadkovom kode na sifrovanie sa spravi lahsie chyba (prip. backdoor) ako v 3 riadkovom kode na porovnanie retazcov.

A je tu este jedna vyhoda, na ktoru som zabudol: ako pisal DgBd, pri plaintexte (alebo hashovani/sifrovani, ktore zvlada aj klient) nie je treba prenasat hesla. Viz napr. problem socialistickeho milionara.

[Mirek Prýmek]

U hashovaně uloženého hesla musíte heslo přenést přes linku, čímž ho vystavujete riziku odposlechnutí. U plaintext hesla se použije výzva-odpověď, takže útočník nezíská nic užitečného.

Ok. Plaintext heslo má zase tohle riziko navíc: admin se hrabe v ldapu, přijde k němu kamarád na kafe a na monitoru uvidí nezašifrované heslo. Kdyby viděl hash (a heslo bylo silné), je mu to k ničemu.

Takže máme tuhle situaci:

řešení "hash" je vystaveno rizikům 1,2,3
řešení "plaintext" vystaveno rizikům 1,2,4

Takže budeme muset definici "A je bezpečnější než B" nadefinovat přesněji: suma (pravděpodobnost rizika * škoda) je pro A menší než pro B

Riziko 3 je "kdokoli si může přečíst komunikaci po drátě, ví hned heslo a může ho regulerně použít" a 4 je "kdokoli si přečte databázi, ví hned heslo a může ho regulerně použít".

Riziko 3 snížím tak, že drát zabezpečím. Riziko 4 podle mě eliminovat nejde (návrhy si rád poslechnu).

Takže riziko 3 se nám smrsklo na "kdokoli dokáže nabourat zabezpečený kanál", zatímco riziko 4 zůstává "kdokoli si může přečíst databázi".

Podle mě je 4 pravděpodobnější a tedy hash bezpečnější.

[DgBd]

U hashovaně uloženého hesla musíte heslo přenést přes linku, čímž ho vystavujete riziku odposlechnutí. U plaintext hesla se použije výzva-odpověď, takže útočník nezíská nic užitečného.

Ok. Plaintext heslo má zase tohle riziko navíc: admin se hrabe v ldapu, přijde k němu kamarád na kafe a na monitoru uvidí nezašifrované heslo. Kdyby viděl hash (a heslo bylo silné), je mu to k ničemu.

Takže máme tuhle situaci:

řešení "hash" je vystaveno rizikům 1,2,3
řešení "plaintext" vystaveno rizikům 1,2,4

Takže budeme muset definici "A je bezpečnější než B" nadefinovat přesněji: suma (pravděpodobnost rizika * škoda) je pro A menší než pro B

Riziko 3 je "kdokoli si může přečíst komunikaci po drátě, ví hned heslo a může ho regulerně použít" a 4 je "kdokoli si přečte databázi, ví hned heslo a může ho regulerně použít".

Riziko 3 snížím tak, že drát zabezpečím. Riziko 4 podle mě eliminovat nejde (návrhy si rád poslechnu).

Takže riziko 3 se nám smrsklo na "kdokoli dokáže nabourat zabezpečený kanál", zatímco riziko 4 zůstává "kdokoli si může přečíst databázi".

Podle mě je 4 pravděpodobnější a tedy hash bezpečnější.

""kdokoli si může přečíst databázi" v praxi znamená, že má obvykle dostatečná oprávnění k provádění dalších akcí typu záměna hashe při přenosu a pod.

plaintext je problematický například při zálohování.

[Mirek Prýmek]

""kdokoli si může přečíst databázi" v praxi znamená, že má obvykle dostatečná oprávnění k provádění dalších akcí typu záměna hashe při přenosu a pod.

To není pravda. Kamarád, který přišel na kafe, žádná oprávnění nemá. (QED)

Navíc pokud někdo získá schopnost měnit databázi, pak samozřejmě získá libovolný přístup k čemukoli, ale to je společné riziko oběma řešením (rizika 1,2), které nás vůbec nezajímá - čili je to irelevantní.