Otázka:
Co je bezpečnější? Pevně ​​kódujete přihlašovací údaje nebo je ukládáte do databáze?
user3421
2015-06-26 17:39:11 UTC
view on stackexchange narkive permalink

Zajímalo by mě, která z těchto věcí je bezpečnější.

Představte si pevně zakódovaná pověření, podobná tomuto:

  if user.Equals ("registereduser") && (password.Equals (encryptedpassword)) {Poskytnout přístup uživateli 

Vím, že tato metoda má velké nedostatky, jako je třeba upravit kód pokaždé, když chcete přidat nového uživatele, a že je použitelná pouze pro několik lidí, kteří aplikaci používají. Ale pokud víte, že k tomu budete mít jen spoustu lidí, a to se stěží změní, není to tak hrozné.

Předpokládám, že kompilovaný kód není možné v rozumném čase dekompilovat a útočník nejdříve nebude hledat pevně zakódovaná hesla.

Je bezpečnější takto používat přihlašovací údaje k pevnému kódu? Nebo je bezpečnější použít běžnou metodu šifrování hesla v databázi?

Možná si myslíte, že útočník by nevěřil, že heslo je uloženo v kódu, ale přesto se podívá na tento kód a najde databázovou tabulku, kde jsou uloženy hashe hesla, takže ho stále najde. Toto je další případ zabezpečení prostřednictvím neznáma - nespoléhejte na to, že jste „jiní“, kteří vás chrání, je tu spousta kódu s pevně zakódovanými hesly, takže žádný útočník nebude překvapen, když ho najde ve vašem kódu.
Pověření musí být snadno vyměnitelné. Pokud používáte přihlašovací údaje, které nelze snadno změnit, jedná se o chybu zabezpečení. Zabezpečení můžete mírně zlepšit kombinací jedné soli společné pro všechny uživatele uložené v kódu s jedinečnou solí na heslo uložené v databázi. Ale jakmile se co nejméně odchýlíte od standardních postupů, riskujete zavedení chyby zabezpečení. Toto riziko je ještě vyšší, pokud plně nerozumíte bezpečnostním důvodům standardních postupů.
Pověření k čemu?
čtyři odpovědi:
deviantfan
2015-06-26 17:53:17 UTC
view on stackexchange narkive permalink

Několik bodů:

Šifrování hesel v databázi má na mysli hašování. To je velký velký rozdíl.

Prvním důvodem, proč jsou DB používány namísto pevného kódování uživatelských dat, není bezpečnost, ale jednoduchost
(přidávat / upravovat / mazat uživatele bez překompilování atd.)

Ukládání hesel ve formátu prostého textu je problém, bez ohledu na to, zda jsou ve vašem programu nebo v databázi. Ukládejte je hashované a solené (na DB a / nebo programu nezáleží. Hashujte je).

Spoléhání se na to, že útočník nebude očekávat, že vaše uživatelská data jsou ve vašem programu, je „zabezpečeno neznámo“ a obecně není zabezpečeno.

Získání řetězců z kompilovaného programu je mnohem jednodušší, než si myslíte. Bez jakéhokoli zmatku jako ve vašem příkladu to netrvá ani minutu (a to zahrnuje spuštění editoru a ruční vyhledávání řetězců). A kdo říká, že je váš program vůbec sestaven? Např. PHP ...

Nepokoušejte se měnit zavedené postupy, pokud nerozumíte důvodům.

Omlouvám se, myslím, že jsem nevysvětlil správně jednu věc, dával jsem jako fakt, že kompilovaný kód by byl ofuscated, ve skutečnosti jsem například zkontroloval kompilaci jazyků ASP.NET do dll a zdá se být příliš těžké se dostat jakákoli data odtamtud (nejsem odborník, ale dává mi to pocit).
Jazyky .NET je velmi snadné dekompilovat, takhle jsou. K dispozici je několik programů. * Bez * obfuscatingu, si člověk poté může přečíst hesla ze zdroje. * Normální * obfuscator nebude míchat všechny řetězce, takže to nic nezmění. A „extrémní“ obfuscator, kromě pomalejšího programu, způsobí, že bude kód těžší číst, ale nic to nezmění na skutečnosti, že uživatel může hesla z vašeho programu dostat. => Jen ne.
... dnešní bezpečnostní věci byly vynalezeny a kontrolovány po celá desetiletí spoustou inteligentních lidí. Nehrajte svá vlastní řešení, nebude to lepší.
`$ strings [váš soubor]`. Nyní mám ve vašem souboru všechny řetězce. Ani zmatek tomu nezabrání.
@Tyler Nerozumím tomu, co chcete říct. Obfuskátory mohou kódovat řetězce a / nebo je nahradit kódem a generovat je z jiných dat. Jak potom váš návrh pomůže? (mnoho obfuskátorů to neudělá, ale je to možné)
Je to Unixový příkaz, který vytiskne řetězce do souboru. Dělám příklad zaměřený na plakát s otázkami, jak snadné by bylo získat jejich nezašifrovaná hesla z popleteného spustitelného souboru.
Dobře, ale já říkám, že „Zmatek tomu nezabrání“ není vždy pravda :) (ale většinou ano)
r00t
2015-06-26 17:51:52 UTC
view on stackexchange narkive permalink

Neprovádějte přihlašovací údaje ani hašování pevného kódu.

Pevně ​​zakódovaná hesla mohou ohrozit zabezpečení systému způsobem, který nelze snadno napravit. [...] také to extrémně ztěžuje řešení problému.

Viz stránka OWASP o heslech s pevným kódem

[ ...] mnoho hashů je reverzibilních (nebo alespoň citlivých na útoky hrubou silou) - a dále mnoho autentizačních protokolů jednoduše požaduje samotný hash [...]

Zobrazit Stránka OWASP o pevně kódovaném krypto

Do zdrojového kódu nezahrnujte žádná pověření, včetně (ale bez omezení) uživatelských jmen, hesel, certifikátů, ID tokenů nebo telefonních čísel.

A jejich průvodce ověřováním

taswyn
2015-06-27 02:24:33 UTC
view on stackexchange narkive permalink

To je ve skutečnosti mnohem méně bezpečné.

V ideálním světě, kde vaše databáze nesedí v DMZ, ale je přístupná pouze přímo z vašeho webového serveru, a pak s omezenými právy na účet, abych prolomil vaši databázi a získal vaši hašovanou tabulku hesel, musím:

  1. Odhalit vaše proměnné připojení k softwarové databázi (účet / heslo)
    • Porušení vašeho webového serveru za účelem získání přístupu shellu k němu nebo
    • využití slabosti vaší aplikace k přímému vystavení jeho proměnných připojení DB
  2. připojení do vaší databáze. Možná budu muset být schopen to provést z SSH na váš webový server nebo prostřednictvím hostování napadeného kódu na něm, pokud se mi nepodaří použít nějakou formu spoofingu IP, která je úspěšná v obcházení jakéhokoli směrování / firewallu, za kterým máte svou databázi (nepravděpodobné ).
  3. Načíst tabulku. To nemusí být možné na účtu, který jsem prolomil prostřednictvím kroku 1, pokud ve skutečnosti nesrovnává samotné hodnoty, ale místo toho předává hash aktuálního pokusu o přihlášení uloženému proc v DB na účtu který je omezen na přístup k uložené proceduře.

Pokud nemohu použít účet vašeho programu k přímému čtení tabulky, jsem v zásadě hotový, pokud nebudu moci kompromitovat účet administrátora na db server nebo jinak úplně ohrozit virtuální počítač db serveru.

A to je vše, než se dostaneme k otázce, zda je vaše vlastní hashovací schéma vůbec zabezpečené .

Pokud jde o „skrytá“ uživatelská jména a hashe, jednoduše to není, i když používáte kompilovaný kód. Věci jako uživatelská jména budou okamžitě patrná i při rychlém průchodu hexadecimálním editorem.


Zabezpečení funguje nejlépe s vrstvami, které slouží skutečným účelům a oddělují nezpracovaná data do nejmenších oddílů potřebných k tomu, aby bylo možné je využívat jako použitelné informace, přičemž předává pouze požadované související informace ve své minimální podobě, a ne samotná data, kdykoli je to možné


Váš přístup dává všechna vejce do jednoho košíku

Moje nezbytné kroky, které procházejí sítí, jsou:

  1. Najděte způsob, jak vystavit svůj kód ke stažení.

To je vše. Pokud váš webový server přiměje kašlat špatně a vaše soubory kódu na pozadí lze přímo stáhnout, máte hotovo. Nepotřebuji ani hlubší kompromis webového serveru, než cokoli, co by k tomu mohlo vést (což se může lišit podle toho, zda je máte v jinak webově čitelném adresáři nebo ne). Alternativně, pokud ve vašem kódu zjistím chybu zabezpečení, mohl bych ji potenciálně přimět k tomu, aby přímo chrlila uložená uživatelská jména a hashe. A samozřejmě stále existuje stejná možnost jednoduše plně kompromitovat váš webový server.

Neexistuje žádný způsob, jak zpomalit vektor útoku, jako je tento, za předpokladu, že detekujete narušení na dané úrovni dříve, než dosáhne jiné úrovně úrovně: jediné porušení okamžitě odhalí vše. I když mluvíme o kompilovaném softwaru, zkušený útočník bude nyní znát nejen váš hashovací algoritmus, ale také váš pepř, pokud jej používáte, a také efektivní přístup k vaší hašované a solené tabulce hesel.

Pro zjednodušení druhého principu váš software sám nikdy ve skutečnosti nepotřebuje znát uložené heslo daného uživatele přímo, aby jej mohl ověřit. Potřebuje jen vědět, zda je heslo, které bylo zadáno, stejné jako uložené heslo, což pro něj může databáze určit, a to způsobem, který zabrání tomu, aby pověření, která váš software používá, ze škodlivého přístupu k databázi ( kromě pokusu o bruteforce z uložené procedury zpřístupněné softwaru, což byste pravděpodobně zjistili na základě počtu pokusů a rychlosti a vypnutí).


Neprovádějte vlastní ověřování, pokud neexistuje žádná jiná alternativa, nebo jste si jisti, že skutečně znáte všechny důvody všeho, co se snažíte udělat, a jste ochotni duplikovat úsilí, které pravděpodobně vidělo více a lepší hodnocení, než jaké vám kdy projde. Nestojí to za váš čas a téměř vždy vyústí v něco méně bezpečného než zavedená knihovna nebo balíček.

Pokud si myslíte, že jste chytří tím, že děláte něco jiného, ​​než jsou standardní průmyslové postupy, přemýšlejte velmi dlouho a tvrdě o tom, zda za těmito praktikami skutečně mohou být velmi dobré důvody.

Jakmile jsou pověření uživatele v rukou někoho jiného, ​​i když jste je hashovali - i když jste věděli, co děláte a hashovali dobře , což se málokdy stane, když se lidé pokusí zavést vlastní bezpečnost - musíte předpokládat, že jsou ohroženi. Je to opravdu jen otázka času. Vaše nejlepší hashovací úsilí je pouze zpoždění, ve kterém máte okno, které informuje uživatele a zamkne účty, dokud nebudou hesla resetována.

Nzall
2015-06-27 03:16:09 UTC
view on stackexchange narkive permalink

Další problém, který zde vidím, souvisí také se zabezpečením: Předpokládejme, že jeden z vašich uživatelů musí změnit své heslo, protože byli infikováni keyloggerem nebo phishingovým útokem. Jak to zvládnete? Jediným způsobem, jak můžete, je požádat je o heslo, toto heslo znovu proměnit, poté je v kódu nahradit, znovu zkompilovat a znovu publikovat. To je spousta věcí, které musíte udělat. Pokud používáte databázi, musíte pouze vytvořit 1 stránku „změnit heslo“ a připojit ji do své databáze. Hotovo.



Tyto otázky a odpovědi byly automaticky přeloženy z anglického jazyka.Původní obsah je k dispozici na webu stackexchange, za který děkujeme za licenci cc by-sa 3.0, pod kterou je distribuován.
Loading...