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:
- 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
- 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é ).
- 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:
- 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.