Posílání hesla nešifrovaným spojením

[question]

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

[Reklama]

[BLEK.]

nie je problem ten cool js kod odfiltrovat

[tdvorak]

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?

[sfsdfasf]

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.

[Jenda]

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.

[Reklama]

[Sten]

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

[Ondřej Caletka]

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.

[adsads]

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.

[Jenda]

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ář.

[Jenda]

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

[Tomaskom]

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.

[Sten]

Pokud bys pokazdy solil necim jinym -> na serveru musis mit heslo v otevrene podobe, jinak to nemuzes overit.

Nemusí, pokud použije SCRAM

[Jenda]

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.

[Tomaskom]

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

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.

[Tomaskom]

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