Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: question 19. 01. 2015, 11:13:46
-
Hi,
Jednoducha otazka a neviem prist na to kde je problem. Scenario: niekto je na verejnej nesifrovanej wifi a prihlasuje sa k sluzbe bez sifrovania (kaviaren plus nejaky free mail).
Bezpecnostne riziko lebo posiela plaintextovo heslo, a ked ho odchytim mozem to v sekunde zneuzit.
Sluzba si ale (dufam) hesla v plaintexte neuklada, dajme tomu ze pouziva ich hashe. Ok. A dajme tomu ze maju viac urovni hashovania.. Niekde nakonci mozno aj so solou..
A teraz ta otazka/scenario: co keby to prihlasovanie (web interface) mal v sebe nejaky pekny JS kod a ten by hesla urobil rovno lvl1 hash a ten by odoslal? (Server by s tym mohol pracovat dalej)...
ALE: odchytena info by sa nedala uz tak lahko zneuzit lebo utocnik by stale nevedel co ten hash generuje. Podla mna by to minimalnr polovicu podobnych utocnikov odradilo a nesnazili by sa simulovat webku, odosielanie vlastnou cestou atd... Proste by to login/pass napisali co odchytili a neslo by tak by sa na to vysrali...
Kde je problem? Viem ze to ma daleko od dokonalosti ale niekoho by to odradilo + implementacia musi byt bezproblemova nie?
Dik
-
nie je problem ten cool js kod odfiltrovat
-
Ptali už se i jiní před tebou: Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse? (https://programmers.stackexchange.com/questions/76939/why-almost-no-webpages-hash-passwords-in-the-client-before-submitting-and-hashi)
-
Je to dobre cvicenie, pomaha to proti zisteniu hesla pri pasivnom odposluchu a nicomu dalsiemu. Typicky sa potom nastavi nejaka cookie a tu si staci ulozit - hned sa mozeme vydavat za uzivatela.
Ovela jednoduchsie riesenie bez zlozitej implementacie je prevadzkovat stranky pod https.
-
A teraz ta otazka/scenario: co keby to prihlasovanie (web interface) mal v sebe nejaky pekny JS kod a ten by hesla urobil rovno lvl1 hash a ten by odoslal?
Pak by se útočník příště přihlásil tím hashem. Takže potřebuješ, aby hash byl jednorázový - třeba tak, že mu server pošle challenge platnou jedno použití pět minut. A tím máš challenge-response protokol, což je způsob, jakým by se to mělo řešit. Bohužel to prohlížeče nepodporují (hledej např. protokol SCRAM). JS není řešení, protože útočník ho v neautentizované stránce může pozměnit.
Kde je problem? Viem ze to ma daleko od dokonalosti ale niekoho by to odradilo + implementacia musi byt bezproblemova nie?
Problém je v tom, že autoři webových prohlížečů si vyšší bezpečnost na internetu nepřejí. Tohle není jediný případ, viz např. self-signed certifikáty.
-
Self-signed certifikáty jsou odmítané kvůli bezpečnosti, protože si je může vygenerovat a podepsat kdokoliv. Challenge-response autorizaci umí WWW autentifikace Digest. Obecně je ale o dost bezpečnější poslat heslo v plaintextu přes ověřený šifrovaný kanál než poslat hash přes nešifrované spojení.
-
A teraz ta otazka/scenario: co keby to prihlasovanie (web interface) mal v sebe nejaky pekny JS kod a ten by hesla urobil rovno lvl1 hash a ten by odoslal? (Server by s tym mohol pracovat dalej)...
Takhle třeba funguje přihlašování na servery Internet Info, včetně Roota. Je tam Challenge-Response protokol, aby se nedal dělat Replay útok. Lepší než nic, ale stále nepříliš bezpečné.
Otázka by měla znít, proč tak málo stránek používá přihlášení pomocí HTTP Digest, které podporuje snad každý WWW prohlížeč a které je i na nešifrovaném spojení velmi bezpečné a velmi těžko napadnutelné. Asi to bude proto, že dialog pro zadání hesla nevypadá dostatečně hezky a nedá se frikulínsky stajlovat.
-
JS není řešení, protože útočník ho v neautentizované stránce může pozměnit.
Nic nie je riesenie, ked ide o HTTP. Neda sa overit protistrana = MITM proxy si kludne zmeni poziadavku servera z hustodemonsky krutoprisnej auth na basic auth a u seba to upravi tak, aby bol server spokojny.
-
Self-signed certifikáty jsou odmítané kvůli bezpečnosti, protože si je může vygenerovat a podepsat kdokoliv.
Nešifrované HTTP je na tom ještě hůř, protože tam není potřeba ani to generování certifikátu + MITM, a přesto by se ti nejspíš nelíbilo, kdyby ti Firefox/Chrome dělal při každé návštěvě HTTP stránky to, co ti dělá u self-signed certifikátu.
Otázka by měla znít, proč tak málo stránek používá přihlášení pomocí HTTP Digest, které podporuje snad každý WWW prohlížeč a které je i na nešifrovaném spojení velmi bezpečné a velmi těžko napadnutelné. Asi to bude proto, že dialog pro zadání hesla nevypadá dostatečně hezky a nedá se frikulínsky stajlovat.
Protože tam nefunguje UTF-8. Protože to GUI je otřesné. Protože prohlížeče neimplementují per-server odhlášení. Protože odhlášení je alespoň ve Firefoxu na mašli. Protože pro registraci stejně musíš použít custom formulář.
-
JS není řešení, protože útočník ho v neautentizované stránce může pozměnit.
Nic nie je riesenie, ked ide o HTTP. Neda sa overit protistrana = MITM proxy si kludne zmeni poziadavku servera z hustodemonsky krutoprisnej auth na basic auth a u seba to upravi tak, aby bol server spokojny.
To je ale problém browseru, že na to neupozorní.
-
A teraz ta otazka/scenario: co keby to prihlasovanie (web interface) mal v sebe nejaky pekny JS kod a ten by hesla urobil rovno lvl1 hash a ten by odoslal? (Server by s tym mohol pracovat dalej)...
ALE: odchytena info by sa nedala uz tak lahko zneuzit lebo utocnik by stale nevedel co ten hash generuje. Podla mna by to minimalnr polovicu podobnych utocnikov odradilo a nesnazili by sa simulovat webku, odosielanie vlastnou cestou atd... Proste by to login/pass napisali co odchytili a neslo by tak by sa na to vysrali...
Pokud by ten "lvl1 hash" nebyl soleny (nebo pokazdy stejnou soli) -> utocnik nemusi znat nic krome hotoveho hashe a tim se prokaze serveru.
Pokud bys pokazdy solil necim jinym -> na serveru musis mit heslo v otevrene podobe, jinak to nemuzes overit.
-
Pokud bys pokazdy solil necim jinym -> na serveru musis mit heslo v otevrene podobe, jinak to nemuzes overit.
Nemusí, pokud použije SCRAM
-
Pokud bys pokazdy solil necim jinym -> na serveru musis mit heslo v otevrene podobe, jinak to nemuzes overit.
Můžeš mít uložený (osolený) hash a počítat osolený hash osoleného hashe (sůl uvedená jako druhá bude konstantní).
A nebo použiješ ten SCRAM, které by měl mít ještě nějaké další zajímavé vlastnosti, ale zase je složitější na implementaci.
-
Nemusí, pokud použije SCRAM
Můžeš mít uložený (osolený) hash a počítat osolený hash osoleného hashe (sůl uvedená jako druhá bude konstantní).
A nebo použiješ ten SCRAM, které by měl mít ještě nějaké další zajímavé vlastnosti, ale zase je složitější na implementaci.
Jo, SCRAM je spravna cesta.
Ja ten dotaz pochopil tak, ze si provozovatel dane sluzby to hashovani ubastli sam a SCRAM me vubec nenapadlo uvazovat, hlavne proto, ze byla rec o nesifrovanym spojeni :P
K tomu samozrejme musim dodat 100x opakovane: Je blbost vymyslet vlastni reseni, misto toho by mel clovek pouzit neco, co vymysleli skutecni odbornici a je to dobre otestovano.
To, jak je to navrzeno v uvodnim prispevku, chrani uzivatele jen pokud by byla napadena databaze serveru a on mel stejne heslo jinde, dalsi prinosy v tom nevidim, jako nahradu sifrovanyho spojeni ani nahodou.
-
To, jak je to navrzeno v uvodnim prispevku, chrani uzivatele jen pokud by byla napadena databaze serveru a on mel stejne heslo jinde, dalsi prinosy v tom nevidim, jako nahradu sifrovanyho spojeni ani nahodou.
Pro tohle to samozrejme neni potreba, zacinam placat blbosti, uz radsi mlcim ::)
-
Dotaz laika: Zaujalo mě téma diskuse, tak jsem se trošku začetl. Zajímalo by mě ale, co je to konkrétně ten SCRAM. (Předpokládám, že není myšleno tohle - http://cs.wikipedia.org/wiki/SCRAM :D ) Můžete mi to tady někdo trošku vysvětlit? Odkaz bohatě postačí. Díky.
-
https://www.abclinuxu.cz/clanky/plaintextova-hesla-uzivatele-a-scram
-
Díky za rychlou odpověď v tuhle noční hodinu.
-
Protože tam nefunguje UTF-8. Protože to GUI je otřesné. Protože prohlížeče neimplementují per-server odhlášení. Protože odhlášení je alespoň ve Firefoxu na mašli. Protože pro registraci stejně musíš použít custom formulář.
Ale zas to má tu výhodu, že kontroluje přístup ke kompletně celému webu, takže se nemůže stát, že někde v kódu aplikace je nějaká chyba, kvůli které se dá na nějakou stránku nebo s nějakým zvláštním požadavkem dostat někam, kam by se člověk dostat neměl. Chyba v autentizačním kódu v prohlížeči mi přijde jako daleko míň pravděpodobná než různé chyby v různých aplikacích napsaných kdovíkým.
Pokud jde o nějaký interní web, kde se dá nehezký přihlašovací dialog zkousnout, tak je to imho dobrá cesta.
-
Chyba v autentizačním kódu v prohlížeči
Resp. ve webserveru, žejo :)
-
Protože tam nefunguje UTF-8. Protože to GUI je otřesné. Protože prohlížeče neimplementují per-server odhlášení. Protože odhlášení je alespoň ve Firefoxu na mašli. Protože pro registraci stejně musíš použít custom formulář.
Ale zas to má tu výhodu, že kontroluje přístup ke kompletně celému webu…
Já vím jaké to má výhody (a četl jsem několik CVEček zejména embedded zařízení, které právě způsobilo nekontrolování cookies na nějaké podmnožině URL). Ale bohužel také vím, kam mě uživatel/zákazník poslal, když jsem mu dodal aplikaci, která to používala.
(a taky si můžeš tipnout, kam tě uživatelé pošlou, když jim zařídíš autentizaci klientským certifikátem…)
-
Ale bohužel také vím, kam mě uživatel/zákazník poslal, když jsem mu dodal aplikaci, která to používala.
Jasně, no, vypadá to předpotopně, proto jsem psal pro interní použití. Zákazníkovi bych to nedal.
-
Protože tam nefunguje UTF-8. Protože to GUI je otřesné. Protože prohlížeče neimplementují per-server odhlášení. Protože odhlášení je alespoň ve Firefoxu na mašli. Protože pro registraci stejně musíš použít custom formulář.
Ale zas to má tu výhodu, že kontroluje přístup ke kompletně celému webu, takže se nemůže stát, že někde v kódu aplikace je nějaká chyba, kvůli které se dá na nějakou stránku nebo s nějakým zvláštním požadavkem dostat někam, kam by se člověk dostat neměl. Chyba v autentizačním kódu v prohlížeči mi přijde jako daleko míň pravděpodobná než různé chyby v různých aplikacích napsaných kdovíkým.
Pokud jde o nějaký interní web, kde se dá nehezký přihlašovací dialog zkousnout, tak je to imho dobrá cesta.
Tahle výhoda má i některé nevýhody (http://www.soom.cz/clanky/1161--Kradez-prihlasovacich-udaju-obrazkem-WWW-Authenticate-exploit)
-
Ale zas to má tu výhodu, že kontroluje přístup ke kompletně celému webu, takže se nemůže stát, že někde v kódu aplikace je nějaká chyba, kvůli které se dá na nějakou stránku nebo s nějakým zvláštním požadavkem dostat někam, kam by se člověk dostat neměl.
Pokud je žádoucí mít zaheslovaný celý web, tak si přístup nekontroluje každá stránka extra, ale konfigurace práv je nastavená v konfiguraci webu.
-
Pokud je žádoucí mít zaheslovaný celý web, tak si přístup nekontroluje každá stránka extra, ale konfigurace práv je nastavená v konfiguraci webu.
Jde o to, že když provozuju x webových aplikací, tak mám x implementací autentizace, které můžou mít různé zranitelnosti. Pokud mám jednu bariéru, přes kterou se script kiddies nedostanou, je to podle mýho názoru podstatně jednodušší a pro správu příjemnější situace.
Jak psal Jedna, těch CVEček na různý chyby v různých CMSkách apod. jsou mraky a útoky na ně jsou časté, navíc u různých systémů můžou být různé zapomenuté defaultní loginy atd. atd.
2015/01/20 02:07:15 [error] 6850#0: *1175 open() "/usr/local/www/data/phpMyAdmin-3.1.2.0-english/scripts/setup.php" failed (2: No such file or directory), client: 94.102.49.168, server: ..., request: "GET //phpMyAdmin-3.1.2.0-english/scripts/setup.php HTTP/1.1", host: "..."
2015/01/20 02:07:15 [error] 6850#0: *1176 open() "/usr/local/www/data/phpMyAdmin-3.1.2.0/scripts/setup.php" failed (2: No such file or directory), client: 94.102.49.168, server: ..., request: "GET //phpMyAdmin-3.1.2.0/scripts/setup.php HTTP/1.1", host: "..."
2015/01/20 02:07:15 [error] 6850#0: *1177 open() "/usr/local/www/data/phpMyAdmin-3.4.3.1/scripts/setup.php" failed (2: No such file or directory), client: 94.102.49.168, server: ..., request: "GET //phpMyAdmin-3.4.3.1/scripts/setup.php HTTP/1.1", host: "..."
2015/01/20 02:07:15 [error] 6850#0: *1178 open() "/usr/local/www/data/phpMyAdmin2/scripts/setup.php" failed (2: No such file or directory), client: 94.102.49.168, server: ..., request: "GET //phpMyAdmin2/scripts/setup.php HTTP/1.1", host: "..."
-
Tahle výhoda má i některé nevýhody (http://www.soom.cz/clanky/1161--Kradez-prihlasovacich-udaju-obrazkem-WWW-Authenticate-exploit)
To je problém otřesného GUI v browseru. Příčetný člověk to okno udělá integrované třeba do toolbaru, aby nevypadalo jako že je v obsahu stránky.