ABCLinuxu a bezpečnost hesla? (diskuse)

[Heron]

Chjo. Webový magazín není banka.

[Tom.š Ze.le.in]

Což neznamená, že 87% uživatelů nemá pro oboje stejné heslo. Ok. Budu optimista. Na tomhle serveru jen 54%.

[Ritchie]

Tak si na přihlašovací stránce ručně změňte protokol na https, přihlašovací informace jsou pak odesílány rovněž přes https.

[Christof]

ostatně jako na každém webu, kde se přihlašuješ a není to přes https

[Tom.š Ze.le.in]

Ne nutně, viděl jsem případy kdy se heslo hashuje v javascriptu (a třeba i s nonce které poslal server). Vhodnost nekomentuju, všechno má svá pro a proti (ale https je zřejmě nejlepší ochranná čára).

[Käyttäjä 11133]

A k čemu to to je, že se to hashuje v javascriptu, když potom logicky je samotným heslem ve skutečnosti ten hash a pokud ho zachytíš, tak se s ním autorizuješ?

[happy barney]

var prefix = 'unikatny-identifikator-session';

hash = make_hash (prefix + heslo);

[Tom.š Ze.le.in]

Myslím, že jsem nonce zmínil. Takže ten hash je k něčemu jen pro to jedno navázání spojení. (ale zase musí být na serveru heslo víceméně v plain formátu).

[Käyttäjä 11133]

Tak dobře lidi, man-in-the-middle ok? Nonce prostě není řešení!!

[Tom.š Ze.le.in]

Je to řešení jednoho z problémů, toho asi nejpravděpodobnějšího. MITM to nezabrání, zrovna tak mnoha dalším věcem - konče třeba podvrženým browserem - ale reagoval jsem na určitý příspěvek.

[xkucf03]

Co se týče podvržených prohlížečů, tak metoda výzva-odpověď je super. Viděl jsem SSL proxy servery, které dešifrují komunikaci proudící přes HTTPS. Není to realizování prolomením SSL, ale tím, že klientům (obvykle ve firmách) se do prohlížečů nainstaluje nová certifikační autorita a tou je posvěcena veškerá komunikace mezi klientem a proxy. Klient (zaměstnanec) pak nemusí vůbec nic zpozorovat (žádné bezpečnostní varování prohlížeče, u adresy má "zámeček"). Klidně si takhle komunikuje třeba s bankou a mezitím zlý správce sítě čte jeho komunikaci. Výzva-odpověď tohle částečně řeší, protože útočník se aspoň nedostane k heslu (pokud se na tuto situaci předem nepřipravil)

BTW: Kontrolujete si pravidelně CA nainstalované ve vašem firemním počítači? Nosíte s sebou otisky klíčů používaných serverů a autorit?

[azurIt]

to akoze ked nejake riesenie neriesi uplne vsetky mozne problemy, tak je na nic ?

[Käyttäjä 11133]

Neexistuje takové řešení, které by řešilo všechny možné problémy, existují jen částečná řešení. Nicméně nonce má příliš vysokou cenu vzhledem k tomu, jak málo nabízí.

[xkucf03]

Nemusí, nemusí. Jestli chcete vědět, jak na to, tak zdrojáky jsou tady: http://sorry.vse.cz/~xkucf03/skola/4IZ228-bg.tar.bz2 a ukázka tady: http://sorry.vse.cz/~xkucf03/bg/prihlaseni.php

[Tom.š Ze.le.in]

Podívám se. Jsem lehce skeptický - už jsem v reálu toto viděl dvakrát tvrzeno, ani jednou to nebyla pravda :)

[xkucf03]

Stručně pro ty, kteří nechtějí číst zdrojáky:

• Server má uložený hash hesla v SHA1
• Server vygeneruje náhodný řetězec (výzvu) a pošle ho klientovi (a zapamatuje si ji)
• Klient (JavaScript) zahešuje heslo od uživatele a přilepí k němu výzvu -- tohle celé ještě jednou zahešuje.
• Server zná první hash hesla a výzvu, takže udělá totéž, co klient a hodnoty porovná -- tím ověří uživatele.

Tento postup je podle mě neprůstřelný (za předpokladu, že věříme SHA1). Pokud mne přesvědčíte o opaku, budu rád, protože budu moci vylepšit svůj program

Co jsem zatím nevyřešil:

• přihlašování funguje uspokojivě jen ve Firefoxu: Konqueror 3.5.6 padá!, Opera se nepřihlásí a IE snad ani správně nezobrazí formulář. XHTML mám validní, takže je tam asi něco v JavaScriptu, na co jsem zatím nepřišel. Jakékoli rady a konstruktivní tipy uvítám.
• Neřešil jsem jak dostat heslo bezpečně na server při registraci uživatele -- tohle asi bez SSL nejde, snad leda si v JS napsat vlastní asymetrické šifrování, což je samozřejmě nesmysl (když máme HTTPS)

[miso]

alias CHAP

[xkucf03]

CHAP requires that both the client and server know the plaintext of the secret

Kdežto v mém případě na serveru heslo není v čisté podobě A až to trochu přisolím, tak i ukradené hashe ze serveru budou útočníkovi k ničemu.

[happy barney]

^plaintext^SHA1 hash^ princíp je jednoduchý, aj SHA1 hash, ak sa nemení, je vlastne plaintext. na útok postačuje vedieť ten hash, nemusí byť známy zdroj hash-u (heslo).

[Franta]

To jsou jenom prázdné kecy. Jestli máš lepší řešení, tak ho sem napsiš.

Dalo by se ověřovat pomocí certifikátů (GPG/SSL/SSH...) a asymetrického šifrování -- pak by na serveru byl jen veřejný klíč uživatele a ten soukromý by byl v bezpečí u klientů. Vykradení serveru by pak nebylo rizikem z toho hlediska, že pomocí veřejných klíčů se nikdo nikam nepřihlásí.

Ale pokud se přihlašujeme pomocí hesla, tak nic lepšího než posolený hash nemáme.

[Tom.š Ze.le.in]

Nemám u sebe bz2 :( takže jen odhad dle prihlaseni.js:

• serveru se posílá hash(hash(heslo),nonce)
• předpokládám: na serveru je uloženo hash(heslo), aby bylo možné ověřit
• hash(heslo) mi ale, pokud je získám, postačí k autorizaci - což jsem myslel výrazem "heslo víceméně v plain formátu"

Pochopil jsem něco špatně?

[Tom.š Ze.le.in]

s/autorizaci/autentizaci/

[xkucf03]

• Máš bod za "reverzní inženýrství" pochopil jsi to správně, výše jsem to teď i trochu polopaticky rozepsal.
• S tím "heslo víceméně v plain formátu" máš i nemáš pravdu:

Proč jsou špatná hesla na serveru v čistém textu:

• Útočník* se může přihlásit k dané (naší) službě
• Útočník může použít dané heslo i u jiných služeb, za předpokladu, že uživatel má všude stejné heslo.

První bod nás nemusí trápit, protože když se nám někdo hrabe v serveru, tak je už asi jedno, že se přihlásí. Druhý bod je chyba v případě uživatel používá stejná hesla a jiné služby přijímají hesla od uživatele v SHA1. Tohle by se dalo řešit solí (--> TODO)

*) po získání hesel ze serveru, případně správce serveru hned

[Tom.š Ze.le.in]

V podstatě souhlas. Jde jen o to, zda jak moc nás netrápí bod 1. Jsou situace kdy trápí - případy souborů dostupných zvenku pro čtení už se staly, že se někdo dostal k zálohám databáze taky.

Sůl je rozumný nápad.

[xkucf03]

Po čase jsem k tomu napsal něco jako dokumentaci - můžete kouknout tady: Ověřování uživatelů na webu

[Tom.š Ze.le.in]

BTW, hezký a celkem bezpečný způsob ověřování je ten, kdy má server uloženo třeba 100x zahashované heslo, a při přihlašování klientu řekne, kolikrát má klient provést hashování - vždy o jedno méně než už server viděl. Jen je omezen počet přihlášení s jedním heslem. Nepamatuje se někdo jak se tenhle způsob jmenuje?

[xm]

Platí známá poučka - security through obscurity je _ŠPATNÝ_ přístup a nefunguje.

[michich]

To jo, ale popsaný způsob není obscurity.

[xkucf03]

1) Omezený počet přihlášení je vlastnost, ale ve většině případů to bude chyba (uživatel pochopí, když si musí měnit heslo jednou za měsíc, ale asi si nebude chtít hlídat kolikrát se přihlásil).

2) Když milionkrát zahešuji heslo, neohrožuje to bezpočnost? Není hash hashe snáze odhadnutelný než hash náhodného vstupu (hesla)?

3) Jsou tu lepší metody: výzva-odpověď -- viz můj příspevek výše.

[Tom.š Ze.le.in]

1. To záleží na použití, co nastane dřív - zda povinná změna nebo počet. V praxi jsem s tím neviděl problém pokud se přihlašoval člověk (ne jiná aplikace).

2. Pokud se to neošetří tak asi o něco snáze odhadnutelný je - podle třeba Handbook of Applied Cryptography, 2.34 by "po nekonečnu iterací" měl být počet dostupných hashů cca $\sqrt{\pi n/2}$. Pořád to je pro běžné účely řádově víc než prostor běžných hesel. A ošetřit to myslím jde.

[jnc]

no a?

[maleprase]

a co projde internetem kdyz se prihlasis z ne wifi?

[pasmen]

To same. S tim rozdilem ze u Wi-fi to zachytne kazdy kdo bude chtit, u kabelu jen ten kdo ma pristup na router.

[Käyttäjä 11133]

Když tě to štve, proč nepoužíváš nějaký šifrovaný tunel k celkovému připojení k netu? (TorK||Tor) Nebo proč prostě nepřepíšeš to http:// na https:// a neužíváš si šifrovaného spojení?

[David Heidelberg]

Super! A co takhle, aby se to automaticky přeplo na https při přihlášení a potom už to používalo http? přijde mně zbytečný u každý stránky otravovat s dialogem:

Opouštíte zabezpečený mód. Přenosy již nebudou šifrované.

Samozřejmě, že se to dá vypnout, ale pro jiné stránky to chci nechat povolené...

0K!AS

[Käyttäjä 11133]

A proč rovnou nepoužíváš šifrování na celý web?

[azurIt]

a naco ? okrem hesla sa tam ziadne ine citlive informacie neprenasaju. absolutne nechapem kritiku tohto prispevku. vlastne hovorite, ze okias si je sam na vine, ze server/portal jeho heslo dostatocne dobre a pohodlne sam nezabezpeci ? a este sa aj opovazuje na to upozornovat a stazovat sa, to je ale drzost!.. co je toto za radoby logiku ??

[Käyttäjä 11133]

Vždyť server to zabezpečuje!!!! Je tu možnost šifrovat!!!!

[azurIt]

"vlastne hovorite, ze okias si je sam na vine, ze server/portal jeho heslo dostatocne dobre a pohodlne sam nezabezpeci ?"

sifrovanie (https) hesla by malo automaticke, nezavisle na sifrovani celeho webu

..!!!!!!!!! ;) to aby som ti odpovedal v tvojej reci.

[David Heidelberg]

sifrovanie (https) hesla by malo automaticke, nezavisle na sifrovani celeho webu

+1

[trekker.dk]

Akorát to funguje dost blbě, "Dokončit" a některé další funkce přesměrovávají na nezabezpečenou verzi a ta hláška, kterou u toho vyhazuje prohlížeč, je dost otravná

[David Heidelberg]

+1

[Leoš Literák]

Nevidim duvod. Vsechny odkazy a formulare maji relativni url, nikde nezacinaji jmenem serveru. Schvalne si to vyzkousim, zde je POST na /blog/EditDiscussion.

[Leoš Literák]

Presto jsem ted na http, coz moc nechapu. Na druhou stranu me to tesi, viz prispevek

[Leoš Literák]

Podporu https jsem nechal zavest na to, abychom ji mohli nasadit pro sifrovani prihlasovaciho formulare. Takze heslo by slo pres https a vzapeti byste byli presmerovani zpatky na http. Nicmene jsem se k tomu jeste nedostal, nemel jsem cas si s tim pohrat a zjistit, zda to bude fungovat spravne.

Brouzdani ostatnich stranek pod https nechci, prijde mi to jako zbytecne plytvani vykonem serveru. Nelibi se mi a kdyby se rozmohlo (ze bych jej zaznamenal na zatezi serveru), tak bych https na abicku zakazal.

[Jiří (BoodOk) Kadeřávek]

No, on ten formulář může být klidně v http, s odesláním do https://... a následným redirectem na serveru zpět do http. Teď si jen nejsem jistý, jak a u kterého browseru povyskakují varovné hlášky. Takže bych na celém webu dal redirect z https do http s jedinou výjimkou, tedy URL v action formuláře. V zásadě to znamená změnu na dvou místech v kódu a lehká úprava v konfiguraci Apache.

[xkucf03]

Nemůže. Přihlašovací formulář už musí být v HTTPS, protože jinak by místo něj mohl útočník podstrčit svůj formulář, který by na HTTPS nesměřoval, nebo by na něj směřoval až po přesměrováním na útočníkovu stránku, kde by se heslo odchytilo. Takový útok by nebyl na první pohled vidět. Toto je také důvod, proč banky (alespoň ty seriózní) nemají na veřejném (tzn. nešifrovaném) webu přihlašovací formuláře.

[Jiří (BoodOk) Kadeřávek]

To je pravda, ale na druhou stranu ábíčko není banka.

[xkucf03]

To sice ne, ale když už tak už. Ono by pak celé to snažení bylo na nic a naopak by to v lidech vzbuzovalo falešný pocit bezpečí a přitom by jejich heslo mohl odposlechnout kde kdo.

[Leoš Literák]

Pak vubec. Kazde url, kde muze byt formular, muze obsahovat i login formular, pokud uzivatel neni prihlasen.

[xkucf03]

A co přidělat k těm formulářům mechanismus výzva-odpověď (svoji implementaci jsem tu odkazoval). Bylo by to bezpečné a obešli bychom se bez HTTPS, akorát to vyžaduje javascript u klienta (počítá se jím SHA1 hash).

[Luboš Doležel (Doli)]

Nikdy by mě nenapadlo lézt na nějaká přihlašovací místa v nějaké veřejné WiFi síti jen tak. SSHčkem domů/na server a protunelovat.

[trekker.dk]

Nikdy by mě nenapadlo lézt na nějaká přihlašovací místa v nějaké veřejné WiFi síti jen tak. SSHčkem domů/na server a protunelovat.

Problém 1: Ne všichni to umí.

Problém 2: Ne všichni mají doma server, na který by se dalo připojit.

[Franta Gajdůšek]

Problém 3: Ne vsichni maji doma jine pripojeni nez nezabezpecene wifi.

[trekker.dk]

To není problém, protože SSH je zašifrované samo o sobě.

[Käyttäjä 11133]

Tak si to za trest přečti ještě jednou

[trekker.dk]

Co?

[Käyttäjä 11133]

Doli hocoří o tom, že se protuneluje přes SSH domů a veškerou komunikaci směřuje přes tento tunel. Což má nějaký smysl, pokud komunikace z domova pokračuje šifrovaně, nebo po metalickém/optickém vedení, ale pokud z domu komunikace opět půjde nešifrovaně vzduchem tak je jedno jestli si na připojení domů použil SSH, nebo ne. Protože z tvého domu ta komunikace stejně půjde dále nešifrovaně vzduchem.

[trekker.dk]

Aha. Tak daleko jsem to nedomýšlel.

[Hynek (Pichi) Vychodil]

Aha. Tak daleko jsem to nedomýšlel.

To děláš často co jsem si všiml.

[AltOS]

Asi tak nejak...