Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - DgBd

Stran: 1 ... 14 15 [16] 17 18 19
226
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

227
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ší.

228
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 :-)

Citace
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.

229
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.

Citace
2. pokud ano, hashovaná hesla jsou bezpečnější

To jistě.

230
Š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á.

231
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 :-)

232
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í.

233
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.

234
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.

235
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.

236

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.

237
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.

238
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í.

239
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é.

240
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.

Stran: 1 ... 14 15 [16] 17 18 19