it-swarm-eu.dev

Zabezpečení https - mělo by být heslo hashované na straně serveru nebo klienta?

Vytvářím webovou aplikaci, která vyžaduje přihlášení uživatelů. Veškerá komunikace probíhá přes https. Používám bcrypt k hašování hesel.

Stojím před dilematou - dříve jsem si myslel, že je bezpečnější vytvořit na straně klienta hash s heslem (pomocí JavaScriptu) a poté jej porovnat s hashem na straně serveru DB. Ale nejsem si jistý, že je to o nic lepší, než poslat heslo prostého textu přes https a poté ho hashovat na straně serveru.

Mým důvodem je to, že pokud útočník dokáže zachytit provoz https (= číst heslo pro prostý text), může například změnit také JavaScript, aby odeslal heslo pro prostý text spolu s hashovaným heslem - kam ho může zachytit.

Důvod proti hashování na straně klienta je prostě snadné použití. Pokud mám hash na straně klienta, musím pro hašování použít dvě oddělené knihovny. To není nepřekonatelný problém, ale je to nepříjemnost.

Existuje bezpečnost při používání hashování na straně klienta? Proč?

Měl bych také používat výzvu-odpověď?

PDATE: Co mě nejvíce zajímá, je to - přidávají tyto techniky (klientské hashování, požadavek-odpověď) nějaké významné zvýšení bezpečnosti v případě, že se používá https? Pokud ano, proč?

116
johndodo

Máte-li hash na straně klienta, hashed heslo se stane skutečným heslem (s hashovacím algoritmem, který není ničím jiným než prostředkem k převodu drženého uživatelem mnemonic na skutečné heslo).

To znamená, že budete ukládat celé "prostý text" heslo (hash) do databáze a na prvním místě ztratíte veškerou výhodu hashování.

Pokud se rozhodnete jít touto cestou, můžete se také vzdát jakéhokoli hašování a jednoduše přenést a uložit surové heslo uživatele (což, mimochodem, zvlášť bych to nedoporučoval).

124
Nicole Calinoiu

Hašování na klientovi má smysl pouze v případě, že serveru nějak nedůvěřujete a nechcete mu ukázat „skutečné“ heslo (heslo, které si lidský uživatel pamatuje). Proč byste nechtěli ukázat heslo na tom samém webu, na kterém dané heslo používá? Protože máte znovu jste použili heslo jinde ! Teď je to obvykle špatné, ale existuje relativně bezpečná verze, která je inkarnaována v nesčetných rozšířeních prohlížečů nebo bookmarkletech, jako je tento nebo ten (Nezaručuji za jejich kvalitu). Jedná se o nástroje, kde si lidský uživatel pamatuje „hlavní heslo“, ze kterého je vygenerováno heslo pro konkrétní web, pomocí názvu domény webu jako druhu soli, takže dva odlišné weby získají různá hesla.

I když tento scénář dává smysl, nedělá to s Javascriptem zaslaným samotným serverem. Bodem hašování klienta s heslem je skutečně to, že server je potenciálně nepřátelský (např. Podvracený útočníkem), a proto je kód Javascript odeslaný tímto serverem přinejmenším podezřelý. Nechcete zadávat své cenné heslo v nějakém nepřátelském Javascriptu ...


Další případ hašování na straně klienta je o pomalé hašování. Protože hesla jsou podle definice slabá, chcete zmařit útoky na slovník . Předpokládáte, že ten špatný dostal kopii databáze serveru a „vyzkouší hesla“ na svých vlastních počítačích (viz tento blogový příspěvek , kde se o tom diskutuje). Ke zpomalení protivníka použijete přirozeně pomalý hashovací proces (například bcrypt ), ale to zpomalí zpracování pro všechny, včetně serveru. Chcete-li pomoci serveru, možná budete chtít odložit část práce na klientovi, a proto alespoň část z toho udělat v nějakém kódu Javascript spuštěném v klientském prohlížeči ...

Javascript je bohužel v této práci strašně pomalý (obvykle 20 až 100krát pomalejší než slušný kód C) a klientský systém nebude schopen přispět podstatnou částí k úsilí o hašení. Myšlenka je zdravá, ale bude muset počkat na lepší technologii (to by fungovalo s klientem Java, i když: s slušným JVM, optimalizovaný Java kód je asi 2 až 4krát pomalejší než optimalizovaný kód C pro hashovací úlohu).


Abych to shrnul, neexistuje žádný opravdu dobrý důvod pro provádění hašování hesel na straně klienta, z kódu Javascript odeslaného samotným serverem. Stačí poslat heslo „tak, jak je“ na server přes tunel HTTPS (přihlašovací stránka, cílová adresa URL formuláře a jakákoli stránka jsou chráněny heslem, musí být doručeny všechny přes SSL, jinak máte naléhavější bezpečnostní problémy než použití hesel).

32
Thomas Pornin

Považuji všechny vaše obavy za zvuk, ale moje doporučení by bylo udělat to na straně serveru.

Vždy existuje velká šance, že uživatel opustí svůj terminál odemčený, což umožňuje manipulaci. A také; pokud je vaše hashovací logika na straně klienta, vystavujete ji.

Další možností by bylo vygenerování hesel na straně serveru; pak neposíláte heslo s čistým textem. Stále však musíte uživateli sdělit heslo. A protože většina uživatelů stále nepoužívá šifrovaný e-mail, považuji to za méně bezpečné.

Viděl jsem řešení, jak posílat hesla přes šifrovaný tunel na mobilní telefon; ale pochybuji, že zabezpečení je lepší než SSL. Možná by to někdo mohl dokázat/vyvrátit?

11
rmorero

Hashing na straně serveru je důležitý, jak naznačily všechny ostatní odpovědi, ale rád bych dodal, že hašování na straně klienta by bylo pěknou bezpečnostní funkcí navíc na hašování na straně serveru.

Hašování na straně klienta má výhody v následujících scénářích:

  1. Chrání heslo uživatele při napadení serveru. Tj. pokud klient není ohrožen, ale server je, pokud klient hashe heslo, server by stále mohl získat přístup k jednomu systému, ale chránili jste heslo uživatele, což je důležité, pokud toto heslo používá jinde.
  2. Chrání heslo uživatele, když si uživatel myslí, že se přihlašuje na jeden server, ale ve skutečnosti se přihlašuje na jiný (chyba uživatele). Například, pokud mám dva bankovní účty a omylem zadám jedno ze svých hesel na nesprávné webové stránky banky, pokud by banka hashovala heslo na straně klienta, tato banka by neznala heslo své druhé banky. Myslím, že by bylo „zdvořilé“ dělat hashování na straně klienta, aby jejich prosté textové heslo nebylo nikdy přenášeno přes drát.

Většinou to ukazuje úctu k uživatelskému heslu. Uživatel sdílí tajemství, které se nemusí exkluzivně vztahovat k vašemu softwaru, takže pokud toto tajemství respektujete, měli byste udělat vše, co je v jeho silách, abyste jej chránili.

10
Samuel

Pokud se nacházíte v tunelu HTTPS, mělo by být heslo nebo hash zabezpečeno pomocí dohledu Ethernetu.

Na straně klienta možná můžete solit hash pomocí ID relace.
To by mohlo být pro simulaci škodlivého Javascriptu obtížnější.

2
bua

Mohli byste udělat obojí, hash to u klienta, takže pokud se útočník může dostat přes zabezpečení https, nebudou moci vidět heslo prostého textu. Pak to hash znovu na serveru, takže pokud útočník dostane hesla uložená na serveru, nemůže to pouze odeslat na server a získat přístup k heslu.

1
nat that

Skrytí hesla na straně klienta vyžaduje Javascript. Někteří lidé ve svém prohlížeči deaktivují Javascript. Tento scénář musíte zvládnout.

Viděl jsem fóra software, který provádí hashování hesla na straně klienta, a pošle hash při přihlášení pokud je to možné, jinak je heslo odesláno jako prostý text. Takže to funguje v každé situaci.

Pokud budete používat https, není jasné zaslání hesla jasným problémem. V ideálním případě by váš server měl odmítnout zobrazovat stránky v http, aby se zabránilo útoku člověka uprostřed útoku. Důvodem je to, že útočník mohl násilně 'downgradovat' vaše připojení z https na http a zahájit sniffing provoz (například pomocí nástroje, jako je SSL Strip).

1
Anonymous

Přijatá odpověď @ Nicole Calinoiu je samozřejmě správná, ale možná na začátku těžko pochopitelná.

Jde o to, že by heslo mělo být na serveru hashováno, aby se zlovolná osoba nemohla pomocí hashů, které hacknul z databáze ze serveru, získat přístup k vašemu účtu nebo datům.

Jak již bylo řečeno, pokud hash na straně klienta a back-end to podporuje, hash se stane vaším heslem a pokud je hash ukraden hackerem, hacker má heslo.

@ Thomas Pornin odpověď také přišla s velmi dobrým bodem, proč byste chtěli hash heslo na klienta, ale věc, kterou popisuje ve svém prvním příběhu, lze provést pouze v případě, že back-end serveru podporuje manipulaci s hashovacími hesly (tj. nemají hash heslo, pokud již hashed, ale že někdo se snaží něco takového podpořit, je velmi nepravděpodobné) ), což podle všeho pravděpodobně nebude. Druhý příběh o něm je velmi dobrý.

0
Ini