Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: gazda 16. 12. 2011, 14:44:48
-
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.
-
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ší.
-
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.
-
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.
-
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.
-
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.
-
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é?
-
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á.
-
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.
-
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.
-
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é.
-
-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.
-
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ší.
-
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í.
-
""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í.
-
U hashovaně uloženého hesla musíte heslo přenést přes linku...
Nie, nemusím. Asi sa domnievate, že keď sú heslá zahashované v databáze, musí sa použiť DIGEST authentication (?). - Nie, to sa nemusí. Možno použiť FORM alebo BASIC a potom je aj výber hashovacej funkcie na autorovi systému a teda sa nemusí použiť DIGEST-om predpísaná md5. Ak sa použije FORM alebo BASIC, treba samozrejme dať pozor aby komunikácia išla cez HTTPS.
-
Synonyma? ...
Áno, máte pravdu, nedajú sa považovať za synonymá. Rozdiel mi je a bol jasný, poplietol som mená.
-
U hashovaně uloženého hesla musíte heslo přenést přes linku...
Nie, nemusím. Asi sa domnievate, že keď sú heslá zahashované v databáze, musí sa použiť DIGEST authentication (?). - Nie, to sa nemusí. Možno použiť FORM alebo BASIC a potom je aj výber hashovacej funkcie na autorovi systému a teda sa nemusí použiť DIGEST-om predpísaná md5. Ak sa použije FORM alebo BASIC, treba samozrejme dať pozor aby komunikácia išla cez HTTPS.
Vy se v tom neskutečně motáte. U hashovaného hesla nemůžete použít digest authentication, protože v digest autentizaci používá cleartext heslo, které nemáte.
Pokud přenášíte přes HTTPS, tak to už se bavíme o další vrstě zabezpečení a ne o bezpečnosti samotného hashovaného hesla.
-
... nie je treba prenasat hesla. Viz napr. problem socialistickeho milionara.
Áno, socialistický milionar sa pri pri plain texte dá použiť. Pre mňa novinka, ďakujem za ňu.
Je socialistický milionar bežne podporovaný na klientoch? Alebo sa to (v prípade browserov) robí len JavaScriptom?
-
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ší.
Pokud drát zabezpečíte, tak už nehodnotíte bezpečnost hashovaného hesla versus cleartext hesla, ale bezpečnost hashovaného hesla po zabezpečeném kanále versus cleartext hesla, což je už něco jiného.
-
Prosim Vas, co je ten komunisticky milionar ? nemuzu to na google prefiltrovat
-
Prosim Vas, co je ten komunisticky milionar ? nemuzu to na google prefiltrovat
http://en.wikipedia.org/wiki/Socialist_millionaire
-
Pokud drát zabezpečíte, tak už nehodnotíte bezpečnost hashovaného hesla versus cleartext hesla, ale bezpečnost hashovaného hesla po zabezpečeném kanále versus cleartext hesla, což je už něco jiného.
Samozřejmě, že nehodnotím "bezpečnost hashovaného hesla". Co by to jako mělo být?
Hodnotím bezpečnost systému X, kde se hesla ukládají hashovaně a úplně stejného systému s jediným rozdílem: hesla jsou ukládána v plaintextu.
Pokud budou oba používat zabezpečenou komunikaci s uživatelem, je hash bezpečnější, protože není napadnutelný kamarádem, který přišel na kafe.
-
U hashovaně uloženého hesla musíte heslo přenést přes linku...
Nie, nemusím. Asi sa domnievate, že keď sú heslá zahashované v databáze, musí sa použiť DIGEST authentication (?). - Nie, to sa nemusí. Možno použiť FORM alebo BASIC a potom je aj výber hashovacej funkcie na autorovi systému a teda sa nemusí použiť DIGEST-om predpísaná md5. Ak sa použije FORM alebo BASIC, treba samozrejme dať pozor aby komunikácia išla cez HTTPS.
Vy se v tom neskutečně motáte.
Vaše "U hashovaně uloženého hesla musíte heslo přenést přes linku..."
som pochopil ako
"U hashovaně uloženého hesla musíte (hashované) heslo přenést přes linku (zo servera ku klientovi)..."
U hashovaného hesla nemůžete použít digest authentication, protože v digest autentizaci používá cleartext heslo, které nemáte.
Ak používam DIGEST Auth (a žiadnu inú), na serveri nemusím ukladať plaintext heslo, stačí ukladať výsledok md5(username:realm:password)
Pokud přenášíte přes HTTPS, tak to už se bavíme o další vrstě zabezpečení a ne o bezpečnosti samotného hashovaného hesla.
Súhlas.
-
Pokud drát zabezpečíte, tak už nehodnotíte bezpečnost hashovaného hesla versus cleartext hesla, ale bezpečnost hashovaného hesla po zabezpečeném kanále versus cleartext hesla, což je už něco jiného.
Samozřejmě, že nehodnotím "bezpečnost hashovaného hesla". Co by to jako mělo být?
Hodnotím bezpečnost systému X, kde se hesla ukládají hashovaně a úplně stejného systému s jediným rozdílem: hesla jsou ukládána v plaintextu.
Pokud budou oba používat zabezpečenou komunikaci s uživatelem, je hash bezpečnější, protože není napadnutelný kamarádem, který přišel na kafe.
Pořád tvrdím, že hodnotíte něco jiného než bylo na začátku v zadání. Tam se o další vrstvě zabezpečení nehovořilo.
-
U hashovaně uloženého hesla musíte heslo přenést přes linku...
Nie, nemusím. Asi sa domnievate, že keď sú heslá zahashované v databáze, musí sa použiť DIGEST authentication (?). - Nie, to sa nemusí. Možno použiť FORM alebo BASIC a potom je aj výber hashovacej funkcie na autorovi systému a teda sa nemusí použiť DIGEST-om predpísaná md5. Ak sa použije FORM alebo BASIC, treba samozrejme dať pozor aby komunikácia išla cez HTTPS.
Vy se v tom neskutečně motáte.
Vaše "U hashovaně uloženého hesla musíte heslo přenést přes linku..."
som pochopil ako
"U hashovaně uloženého hesla musíte (hashované) heslo přenést přes linku (zo servera ku klientovi)..."
U hashovaného hesla nemůžete použít digest authentication, protože v digest autentizaci používá cleartext heslo, které nemáte.
Ak používam DIGEST Auth (a žiadnu inú), na serveri nemusím ukladať plaintext heslo, stačí ukladať výsledok md5(username:realm:password)
Ano, technicky máte pravdu, problém je v tom, že uložené md5(username:realm:password) je ekvivalent cleartext hesla :-) Tj. v této fázi už nemáte uložené hashované heslo, ale cleartext heslo.
-
Pořád tvrdím, že hodnotíte něco jiného než bylo na začátku v zadání. Tam se o další vrstvě zabezpečení nehovořilo.
V tom případě je zadání nesmyslné, protože hodnotit bezpečnost technologie nezávisle na kontextu, ve kterém je použita, popřípadě v kontextu, který neodpovídá realitě (nezabezpečené spojení), je totální békovina.
To bych taky mohl říct, že je bezpečné napsat si heslo na lísteček na monitor a při upozornění, že si ho někdo může přečíst, protestovat, že v zadání nebylo, že existují taky jiní lidi než já.
-
Krom toho, tebou zmíněný challenge-response mechanismus není nic jiného, než vytvoření zabezpečeného kanálu...
-
Pořád tvrdím, že hodnotíte něco jiného než bylo na začátku v zadání. Tam se o další vrstvě zabezpečení nehovořilo.
V tom případě je zadání nesmyslné, protože hodnotit bezpečnost technologie nezávisle na kontextu, ve kterém je použita, popřípadě v kontextu, který neodpovídá realitě (nezabezpečené spojení), je totální békovina.
To bych taky mohl říct, že je bezpečné napsat si heslo na lísteček na monitor a při upozornění, že si ho někdo může přečíst, protestovat, že v zadání nebylo, že existují taky jiní lidi než já.
Špatné přirovnání. S lístečkem by to bylo tak, že si ho napíšu na lísteček na monitor, přičemž přístup do kanceláře, kde ten lísteček je, mám jenom já. Jak moc je to heslo bezpečné?
Prostě mícháte víc vrstev zabezpečení do sebe.
-
Krom toho, tebou zmíněný challenge-response mechanismus není nic jiného, než vytvoření zabezpečeného kanálu...
To v žádném případě. To je ověření toho, že A disponuje stejným tajemstvím jako B, tj. autentizace. Žádný zabezpečený kanál tam rozhodně není.
-
Hodnotím bezpečnost systému X, kde se hesla ukládají hashovaně a úplně stejného systému s jediným rozdílem: hesla jsou ukládána v plaintextu.
Áno, vlákno bolo myslené takto. Pánovi DgBd sa ospravedlňujem, že som to nepovedal dosť jasne.
-
Hodnotím bezpečnost systému X, kde se hesla ukládají hashovaně a úplně stejného systému s jediným rozdílem: hesla jsou ukládána v plaintextu.
Áno, vlákno bolo myslené takto. Pánovi DgBd sa ospravedlňujem, že som to nepovedal dosť jasne.
Teď je otázka, proč se omlouváte mně. Přesně takto to tvrdím já. Mirek k tomu přidal ještě zabezpečený kanál :-)
-
Špatné přirovnání. S lístečkem by to bylo tak, že si ho napíšu na lísteček na monitor, přičemž přístup do kanceláře, kde ten lísteček je, mám jenom já. Jak moc je to heslo bezpečné?
Prostě mícháte víc vrstev zabezpečení do sebe.
No nic, přestává mě to bavit, takže se omezím na konstatování, že https+hash je za běžných okolností bezpečnější než http+c_r+plaintext.
To v žádném případě. To je ověření toho, že A disponuje stejným tajemstvím jako B, tj. autentizace. Žádný zabezpečený kanál tam rozhodně není.
Ok. Takže je to vlastně to samé jako když B pošle A tajemství X jenom tak po drátě, že?
Nebo je tam nějaký zabezpečený kanál?
-
Teď je otázka, proč se omlouváte mně. Přesně takto to tvrdím já. Mirek k tomu přidal ještě zabezpečený kanál :-)
Nic jsem k ničemu nepřidal. Otázka je, jestli součástí systému X je zabezpečený kanál k uživateli.
Já tvrdím, že:
1. pokud ne, je to nerealistická situace
2. pokud ano, hashovaná hesla jsou bezpečnější
-
Špatné přirovnání. S lístečkem by to bylo tak, že si ho napíšu na lísteček na monitor, přičemž přístup do kanceláře, kde ten lísteček je, mám jenom já. Jak moc je to heslo bezpečné?
Prostě mícháte víc vrstev zabezpečení do sebe.
No nic, přestává mě to bavit, takže se omezím na konstatování, že https+hash je za běžných okolností bezpečnější než http+c_r+plaintext.
V tom se shodneme.
To v žádném případě. To je ověření toho, že A disponuje stejným tajemstvím jako B, tj. autentizace. Žádný zabezpečený kanál tam rozhodně není.
Ok. Takže je to vlastně to samé jako když B pošle A tajemství X jenom tak po drátě, že?
Nebo je tam nějaký zabezpečený kanál?
Toto bohužel nechápu. V challenge response se přece žádné tajemství nikam neposílá.
-
No nic, přestává mě to bavit, takže se omezím na konstatování, že https+hash je za běžných okolností bezpečnější než http+c_r+plaintext.
V tom se shodneme.
Tímpádem je kauza skončena, protože jelikož https používají všichni, plaintext hesla prostě bezpečnější NEJSOU.
Toto bohužel nechápu. V challenge response se přece žádné tajemství nikam neposílá.
To je slovíčkaření.
Jestliže posílám text X, zašifrovaný klíčem Y, posílám tím klíč Y nebo ne?
Důležité je, že informaci "znám Y" prokážu tak, že mi Y nikdo při tom nemůže po cestě ukrást. To je V PODSTATĚ "zabezpečený kanál".
Jestli tomu tak ale říkat nechceš, tak neříkej, mně kvůli tomu prsa nenarostou :)
-
Teď je otázka, proč se omlouváte mně. Přesně takto to tvrdím já. Mirek k tomu přidal ještě zabezpečený kanál :-)
Nic jsem k ničemu nepřidal. Otázka je, jestli součástí systému X je zabezpečený kanál k uživateli.
Já tvrdím, že:
1. pokud ne, je to nerealistická situace
Proč? Jsou situace, kdy nepotřebujete zabezpečený kanál. Představte si, že automat má v zásobníku vajíčka. Pokud znáte tajemství, tak vám ho vydá. Počítačovější příklad bohužel teď nevymyslím.
U hashovaného hesla to tajemství musíte před automatem říct/naťukat, u plaintext hesla ne.
2. pokud ano, hashovaná hesla jsou bezpečnější
To jistě.
-
Hodnotím bezpečnost systému X, kde se hesla ukládají hashovaně a úplně stejného systému s jediným rozdílem: hesla jsou ukládána v plaintextu.
Áno, vlákno bolo myslené takto. Pánovi DgBd sa ospravedlňujem, že som to nepovedal dosť jasne.
Teď je otázka, proč se omlouváte mně. Přesně takto to tvrdím já. Mirek k tomu přidal ještě zabezpečený kanál :-)
Tak to sa ospravedlňujem ešte raz. V pôvodnom vlákne išlo o systémy registrátorov domien, kde je pre mňa viditeľným rozhraním web a HTTPS bežnou vecou, v kt. sa mnou skúšaní poskytovatelia našťastie nelíšia.
-
No nic, přestává mě to bavit, takže se omezím na konstatování, že https+hash je za běžných okolností bezpečnější než http+c_r+plaintext.
V tom se shodneme.
Tímpádem je kauza skončena, protože jelikož https používají všichni, plaintext hesla prostě bezpečnější NEJSOU.
Hmm, tvůj svět se podivuhodně smrknul pouze na HTTPS :-)
Toto bohužel nechápu. V challenge response se přece žádné tajemství nikam neposílá.
To je slovíčkaření.
Jestliže posílám text X, zašifrovaný klíčem Y, posílám tím klíč Y nebo ne?
Důležité je, že informaci "znám Y" prokážu tak, že mi Y nikdo při tom nemůže po cestě ukrást. To je V PODSTATĚ "zabezpečený kanál".
Tento přístup ke kryptografii ovšem dost znesnadňuje kryptoanalýzu komplexnějších systémů. Řekneš "mám zabezpečený kanál". Kryptoanalytik se zeptá - co se stane, když bude tento kanál narušen? Musím si heslo změnit? Tato odpověď se liší podle způsobu autentizace.
-
Jsou situace, kdy nepotřebujete zabezpečený kanál
Ano. A jsou i situace, kdy neexistuje na světě jiná osoba než já. V takovém případě je "nejbezpečnější" si heslo nalepit na monitor.
Předpokládám ale, že normální admin, který dělá dobře svou práci se zeptá: "Jak nejlíp systém zabezpečím?" A odpoví si: "Pomocí https a hashovaných hesel". Všechno ostatní je zbytečná chytristika.
-
Hodnotím bezpečnost systému X, kde se hesla ukládají hashovaně a úplně stejného systému s jediným rozdílem: hesla jsou ukládána v plaintextu.
Áno, vlákno bolo myslené takto. Pánovi DgBd sa ospravedlňujem, že som to nepovedal dosť jasne.
Teď je otázka, proč se omlouváte mně. Přesně takto to tvrdím já. Mirek k tomu přidal ještě zabezpečený kanál :-)
Tak to sa ospravedlňujem ešte raz. V pôvodnom vlákne išlo o systémy registrátorov domien, kde je pre mňa viditeľným rozhraním web a HTTPS bežnou vecou, v kt. sa mnou skúšaní poskytovatelia našťastie nelíšia.
Ok, v tom případě je hashované heslo patrně bezpečnější.
-
Tento přístup ke kryptografii ovšem dost znesnadňuje kryptoanalýzu komplexnějších systémů. Řekneš "mám zabezpečený kanál". Kryptoanalytik se zeptá - co se stane, když bude tento kanál narušen? Musím si heslo změnit? Tato odpověď se liší podle způsobu autentizace.
Dobře. Netrvám na tom, že tomu musíme říkat zabezpečený kanál. Můžeme tomu tedy říkat "bezpečný způsob prokázání znalosti".
-
Ok, v tom případě je hashované heslo patrně bezpečnější.
Nestačilo rovnou na začátku říct "plaintext heslo je bezpečnější, pokud jediné, co mám k dispozici, je nebezpečný komunikační kanál a nechci nad ním stavět kanál bezpečný"?
To bysme pak asi byli všichni hned doma.
-
Ok, v tom případě je hashované heslo patrně bezpečnější.
Nestačilo rovnou na začátku říct "plaintext heslo je bezpečnější, pokud jediné, co mám k dispozici, je nebezpečný komunikační kanál a nechci nad ním stavět kanál bezpečný"?
To bysme pak asi byli všichni hned doma.
A nestačilo by rovnou na začátku říct "hashované heslo je bezpečnější, pokud mám k dispozici zabezpečený kanál"?
:-)
A stejně si myslím, že nejdřív bylo vejce a pak slepice
-
A nestačilo by rovnou na začátku říct "hashované heslo je bezpečnější, pokud mám k dispozici zabezpečený kanál"?
Https je standard. Bral jsem jako samozřejmost, že ho máme k dispozici.
Stejně tak jsem bral jako samozřejmost, že máme počítač, a nezmínil jsem se o tom.
-
A nestačilo by rovnou na začátku říct "hashované heslo je bezpečnější, pokud mám k dispozici zabezpečený kanál"?
Https je standard. Bral jsem jako samozřejmost, že ho máme k dispozici.
Jo, stejně tak jako máme k dispozici certifikační autority, bezpečnost jejichž certifikátů byla narušena. Jaký rozdíl to bude znamenat pro firmu, která používá nad HTTPS klasickou basic autentizaci a která používá digest autentizaci? Já bych řekl že poměrně zásadní.
-
Promiňte, ale pořád to ne úplně chápu. Nějak nevidím, proč při nezabezpečeném kanále je bezpečnější plaintextové heslo. Přece mi nic nebrání v tom, abych měl v db hashované heslo a C/R jel s ním. Například mohu mít response danou jako hash(challenge:hash(heslo+salt)) a v db hash(heslo+salt).
Pak útočník s opsanou databází snadno prolomí toto zabezpečení v obou případech (zná údaj v db i challenge), ale pokud je v db hash, nepomůže mu to pro útok na jiné servery, protože nedá heslo na tom jiném serveru (předpokládám normálního uživatele, který sice ví, že nesmí opakovat hesla, ale stejně je opakuje).
-
No nevim nevim, ta diskuze je zajimava ... ale byt admin roota, zvazoval bych, jestli ji nesmazat (nebo aspon nezamknout), precijen, pokud sem prijde nekdo novy ... precte si ji ... a uz se nikdy nevrati :)
Abych taky rekl neco k tematu, sice starosti o bezpecnost nejsou muj hlavni obor, ale vzdycky sem si myslel, ze se hesla do databazi hashuji proto, aby admin ziskal cas na zablokovani uctu v pripade kompromitace databaze. Treba shadow baze se drive hashovala alg MD5, coz presne plnilo ucel, dnes je to tusim SHA512. Ale kazdopadne, hashovani prispiva k vetsi "bezpecnosti", i kdyz ne primo ... co se tyce debat o dalsich vrstvach zabezpeceni, nejlepsi je drzet se dnesniho standardu, sice sou naznaky jeho kompromitace ale silnejsi reseni ma vetsinou vice nevyhod (napriklad pouziti standardniho SSL v aplikacich v USA musite jenom ohlasit na BIS, kdezto na silnejsi sifrovani maji pripraveny proces, na ktery potrebujete armadu pravniku ... pak se o bezpecnosti teoretizuje o neco hure)
-
Jo, stejně tak jako máme k dispozici certifikační autority, bezpečnost jejichž certifikátů byla narušena.
Zatímco bezpečnost databáze plaintextových hesel nebyla nerušena nikdy...
-
Asi je zbytečné se bavit o bezpečnosti s lidmi, kteří nejsou schopni rozlišit bezpečnost věcí, které mám plně pod svou kontrolou (soubor s hesly) od věcí, které pod svojí plnou kontrolou nemám (komunikační trasu, bezpečnost vydavatele certifikátů).
Je pěkné, že lidé žijí ve světě, kde je veškerý provoz šifrovaný přes HTTPS a kde se nepotřebují autentizovat přes PPP nebo 802.1X.
-
Asi je zbytečné se bavit o bezpečnosti s lidmi, kteří nejsou schopni rozlišit bezpečnost věcí, které mám plně pod svou kontrolou (soubor s hesly) od věcí, které pod svojí plnou kontrolou nemám (komunikační trasu, bezpečnost vydavatele certifikátů).
Ale jo, to samozřejmě rozlišuju a klidně se o tom můžeme bavit.
Můj názor ja takovýhle: průměrnou úroveň zabezpečení serveru s hesly u kdejakého hostingu, webu, i registrátora odhaduju na řádově nižší než zabezpečení typické certifikační autority.
Ovšem jestli se někdo cítí na to (a má k tomu potřebné prostředky), že na svých serverech dosáhne vyšší úrovně bezpečnosti, než mají CAs, tak v tom případě je samozřejmě lepší, když na ně spoléhat nebude.
Ovšem ta úvaha má drobnou chybku: i kdybych se rozkrájel, nemám pod svou kontrolou klientské stroje... což tu úvahu trochu degraduje, ne?
-
Asi je zbytečné se bavit o bezpečnosti s lidmi, kteří nejsou schopni rozlišit bezpečnost věcí, které mám plně pod svou kontrolou (soubor s hesly) od věcí, které pod svojí plnou kontrolou nemám (komunikační trasu, bezpečnost vydavatele certifikátů).
Ale jo, to samozřejmě rozlišuju a klidně se o tom můžeme bavit.
Můj názor ja takovýhle: průměrnou úroveň zabezpečení serveru s hesly u kdejakého hostingu, webu, i registrátora odhaduju na řádově nižší než zabezpečení typické certifikační autority.
Ovšem jestli se někdo cítí na to (a má k tomu potřebné prostředky), že na svých serverech dosáhne vyšší úrovně bezpečnosti, než mají CAs, tak v tom případě je samozřejmě lepší, když na ně spoléhat nebude.
Tak toto můžu na 100 % podepsat. Beru to tak, že teorie říká jednu věc, na co si kdo troufne, je na rozhodnutí každého soudruha. Teorie pouze stanovuje pevné rámce.
Ovšem ta úvaha má drobnou chybku: i kdybych se rozkrájel, nemám pod svou kontrolou klientské stroje... což tu úvahu trochu degraduje, ne?
To už je závislé na situaci. V obecné situaci je možné třeba nepřipojit k síti klientskou stanici, která nemá všechny patche OS a nainstalovaný antivirus a přihlašují se do windowsové domény. Ale to už je o něčem jiném. V každém případě je v ohrožení pouze jedno heslo.
-
V obecné situaci je možné třeba nepřipojit k síti klientskou stanici, která nemá všechny patche OS a nainstalovaný antivirus a přihlašují se do windowsové domény. Ale to už je o něčem jiném.
Ano. Vzhledem k tomu, že řeč byla celou dobu o autentizaci vůči webové aplikaci, je tohle trochu o něčem jiném.