it-swarm-eu.dev

Standardy pro šifrování hesel v konfiguračních souborech?

Moje pracoviště má standard, který v konfiguračních souborech aplikace nepovoluje hesla prostého textu. To dává dostatečný smysl pro jeho tvář, v případě, že někdo získá přístup ke konfiguračním souborům, nemá automaticky přístup ke všem oprávněním této aplikace. V některých případech je možné a samozřejmě lepší mít přístup spojený s přihlášením nebo se jinak vyhnout nutnosti mít heslo, například v systému Windows Security pro ověřování serveru SQL, nebo jej nechat nakonfigurovat v umístění třetí strany, například v konfiguraci JDBC v prostředí J2EE. , ale to není vždy možné.

  • Když musím mít v konfiguračním souboru heslo, jakou úroveň šifrování by měl nést?
  • Jak se vypořádáte se skutečností, že šifrovací klíč pro heslo musí být pevně zakódován nebo uložen do jiného konfiguračního souboru?
  • Měly by být šifrovací klíče pro heslo čitelné člověkem?
57
C. Ross

Takže následující bylo příliš dlouhé na komentář ...

Možná by mohl pomoci krok zpět a porovnání výhod preventivních a detektivních kontrol. Preventivní ovládací prvky zahrnují šifrování, ale můžete také kódovat heslo, aby bylo méně zřejmé. Účelem tohoto přístupu je chránit heslo před náhodným sdílením (kódování b32 by produkovalo méně smysluplné znaky (b32 produkuje delší řetězec než b64). Takový přístup jen zvyšuje obtížnost zapamatování náhodné posloupnosti čísel i metody, která by měla Kódování Base32/64 je jednoduchý způsob ochrany hesel, která nevyžadují další logiku, která by měla být vytvořena/udržována.

Jiné přístupy k preventivním kontrolám by pravděpodobně používaly šifrování. Klíč lze chránit mnoha různými způsoby. Aniž bychom se dostali do podrobností nebo zopakovali, co D.W. již zveřejněné, můžete vrstvit detektivní ovládací prvky pro zlepšení pozice zabezpečení. Můžete například auditovat přístup k souboru, který obsahuje klíč. Události (například restartování serveru/služby) můžete korelovat s přístupem k souboru klíče. Jakákoli jiná žádost o přístup (úspěšná nebo ne) do souboru klíče může znamenat neobvyklou aktivitu.

Chcete-li se dostat na vaše otázky, zde je můj názor:

pokud musíte uložit heslo do konfiguračního souboru, doporučuji alespoň kódování hesla, pokud je to možné. Zakódováním hesla by se snížila pravděpodobnost, že dojde k úniku v případě, že někdo prochází souborem, řekněme při sledování podpory prodejce. Šifrování hesla je mnohem bezpečnější, ale vyžaduje to další složitost.

Jak se vypořádat s tím, že klíč musí být pevně zakódován nebo uložen v jiném souboru. Oddělením šifrovacího klíče od jiného souboru je pro někoho obtížné zobrazit klíč. Například můžete použít řízení přístupu k omezení přístupu k souboru klíče, ale stále udržovat otevřenější ACL pro konfigurační soubor. Podobně můžete implementovat auditování pro přístup k souboru klíče, který můžete použít ke korelaci zpět k událostem, které vyžadují použití klíče. Tvrdé kódování klíče může být v pořádku, pokud omezíte přístup k binárnímu kódu. Pečlivé kódování hesla lze snadno zjistit spuštěním „řetězců“ proti binárnímu kódu. Při dekódování hesla můžete zakódovat/zašifrovat pevně kódované heslo (tj. Vyžadovat samostatnou funkci (snad s auditováním), ale to zvyšuje složitost pro vývojáře a administrátora (tj. Jak lze změnit klíč, aniž by došlo k novému sestavení nebo překompilaci binárního kódu). ?).

Měly by být šifrovací klíče pro heslo čitelné člověkem? Záleží. Existuje pouze omezený počet způsobů, jak chránit klíč. Šifrovací klíč je obvykle považován za alfanumerický řetězec, který je těžké zavázat k paměti. Vždy můžete kódovat/šifrovat klíč, ale takové metody neodradí někoho, kdo je dostatečně chytrý, aby pořídil snímek obrazovky. Můžete však použít jednoduché „klíče“ (spíše jako hesla) jako vstup do funkce rozšíření klíčů. V těchto případech možná další opatření, jako je kódování, přidají nějakou další hodnotu vzhledem k nákladům na složitost.

Pokud jde o něco, dobrým přístupem je implementace více vrstev ovládacích prvků. Preventivní kontroly jsou obtížnější, zatímco detektivní kontroly se obecně snáze implementují. Oddělení klíčových souborů by mohlo zjednodušit celkovou architekturu a implementaci ovládacích prvků. Bez ohledu na to, zda jsou použity preventivní nebo detektivní kontroly, je nutné spolu s kontrolou protokolů auditu umožnit některé kontrolní funkce. Tímto způsobem, pokud dojde k nepravděpodobné (přístup ke klíči), můžete podniknout nápravná opatření.

25
bangdang

Pokud provozujete server, který pro přístup k nějaké vzdálené službě potřebuje heslo, pak neexistuje dobré řešení. Uložení hesla do konfiguračního souboru uloženého na vhodném místě pravděpodobně zlepší výběr špatných možností.

Možnosti jsou: nechat uživatele zadat heslo v době spuštění (je to špatné, protože pokud se váš server restartuje, nyní je server nedostupný, dokud osoba nemůže fyzicky přistoupit k serveru a zadat heslo); zakódovat heslo do zdrojového kódu serverového kódu (to je mnohem horší než jeho vložení do konfiguračního souboru); nebo uložit heslo do konfiguračního souboru (nejméně špatné ze všech možností). Hlavní věcí, na kterou si musíte dávat pozor s konfiguračním souborem, je zajistit, aby byl uložen mimo webový kořenový adresář a aby jeho oprávnění k souborům byla náležitě uzamčena.

Šifrování hesla uloženého v konfiguračním souboru nepomůže, protože kam nyní dešifrovací klíč uložíte? Právě jste problém posunuli. „Je to celé želvy“ není přijatelná odpověď.

V systému Windows je další možností, na kterou byste se mohli podívat, uložení hesla do DPAPI. Trochu to pomůže pro stolní aplikace, ale není to užitečné pro bezobslužné servery.

Pro více informací si přečtěte následující otázky na tomto webu: ložte heslo, abyste se vyhnuli interakci uživatele , kam uložit klíč pro šifrování , Jak projekty otevřeného zdroje zpracovávat zabezpečené artefakty? , Jak mohu dešifrovat data pomocí Java, bez pevného kódování klíče? , Heslo v souboru .php , Kde mám Klíč bezpečně uložím pro systém, kde je zdroj viditelný? .

P.S. V zásadě byste mohli použít TPM k uložení hesla - ale v praxi se tím dostanete k problémům s krvácením-Edge, takže pro většinu lidí to pravděpodobně není životaschopné.

37
D.W.

Uložte heslo do proměnné uživatelského prostředí O/S (bez relace) a spusťte program jako tento uživatel.

Výhody:

  1. Nikdy náhodně nekontrolujete heslo do řízení zdroje, protože není k dispozici žádný soubor pro kontrolu.

  2. Pokud uděláte oprávnění ke svému konfiguračnímu souboru (což se nikdy nestane správně?), Vaše hesla nebudou ohrožena

  3. Lze číst pouze uživatelem nebo rootem (stejný jako konfigurační soubor, stejně jako soukromý klíč chránící šifrovaný soubor)

  4. Pokud šifrujete soubor, jak zabezpečujete svůj klíč?

  5. Před zahájením nových procesů však vyčistěte své envvary, protože mohou projít

Jednou výhodou HSM je to, že zatímco uživatel nebo root může použít HSM k dešifrování hodnoty, nikdy v něm nemůže dostat klíč.

5
Neil McGuigan

Místní úložiště hesel je dlouhý problém, se kterým jsem se zabýval. protože šifrování nemusí být neprůstřelné, ale může pomoci, existuje několik dalších možností:

  1. ukládat hesla na lokálním počítači do nového souboru (který bude také lépe šifrován) a omezit přístup k souboru
  2. ukládat hesla na jiném serveru, který se bude autentizovat prostřednictvím OAUTH nebo jiné autentizační služby - podívejte se na tahoe-lafs: https://tahoe-lafs.org/trac/tahoe- lafs
  3. pomocí šifrované místní služby, která ukládá hesla, a přistupuje k ní pomocí certifikátu
  4. některé organizace ukládají svá hesla jako klíče registru nebo s DPAPI - http://msdn.Microsoft.com/en-us/library/ms995355.aspx
  5. pomocí OTP pomocí služby správy účtu
  6. použití proxy serveru pro přístup k důvěrným datům a omezení přístupu k proxy

.

a pro vaše dotazy:

Když musím mít v konfiguračním souboru heslo, jakou úroveň šifrování by měl nést?

nikdy nemusíte mít v kódu hesla, ale je to nejjednodušší a nejbezpečnější způsob.

Jak se vypořádáte se skutečností, že šifrovací klíč pro heslo musí být pevně zakódován nebo uložen do jiného konfiguračního souboru?

pomocí omezení přístupu a sledování souboru

Měly by být šifrovací klíče pro heslo čitelné člověkem? pokud máte na mysli silná a lidská čitelná hesla, není problém vůbec

4
Sergey Malych

Moje 2 centy zde jsou, že pro dokonalou bezpečnost byste chtěli, aby aplikace mohla udělat něco (číst heslo), které by útočník na fyzickém stroji se stejnými oprávněními neměl být schopen dělat, což se zdá být v rozporu .

V nejlepším případě můžete zatemnit heslo v konfiguraci ( Base64 , klíč někde v počítači atd.)

0
Nicolas C