sql >> Databáze >  >> RDS >> PostgreSQL

Bezpečná metoda pro ukládání/načítání soukromého klíče PGP a přístupové fráze?

(Poznámka:Nejsem žádný bezpečnostní expert. Mám o tuto oblast zájem, ale to je vše. Mějte to na paměti.)

Pokud je to možné, hesla vůbec neukládejte

Hodně záleží na tom, jaké máte potřeby. Nejlepší možností ze všech je nepoužívat obousměrné šifrování vůbec; pokud můžete uložit pouze solené a jednosměrně hašované hesel digesty, to je ideální. Stále je můžete otestovat, abyste zjistili, zda odpovídají heslu dodanému uživatelem, ale nikdy je neukládáte.

Ještě lépe, pokud vaši klienti používají nějaký rozumný protokol (tj. ne HTTP, jak je běžně implementováno), můžete použít mechanismus ověřování reakce na výzvu to znamená, že vaše aplikace nikdy nikdy potřebuje vidět heslo uživatele, a to ani při jeho ověřování. To je bohužel jen zřídka možné na veřejném webu, který má zabezpečení, které by zahanbilo programátory z 80. let.

Pokud musíte heslo uložit, izolujte klíče z aplikace

Pokud musíte být schopni dešifrovat hesla, v ideálním případě byste neměli mít všechny podrobnosti k tomu na jednom místě a už vůbec ne na jednom kopírovatelném a snadno dostupném místě.

Z toho důvodu bych osobně raději nepoužil PgCrypto (jak to děláte vy) pro tento účel, protože vás to nutí odhalit soukromý klíč a (pokud ho má) přístupovou frázi na server, kde by to mohlo být odhaleno v PostgreSQL log soubory nebo jinak potenciálně sniffed. Chtěl bych udělat svou krypto klientskou stranu, kde bych mohl použít PKCS#11, agenta klíče nebo jiné nástroje, které mi umožňují dešifrovat data, aniž bych měl můj kód přístup ke klíči.

Problém bezpečného úložiště klíčů je součástí toho, co PKCS#11 byl vynalezen pro. Poskytuje obecné rozhraní pro aplikace a poskytovatele kryptoměn, aby mohli komunikovat s čímkoli, co může poskytovat určité služby podepisování a dešifrování aniž by kdy prozradil svůj klíč . Obvyklé, ale nejen, použití je s hardwarovými kryptoměnami, jako jsou čipové karty a hardwarové kryptomoduly. Takovým zařízením lze říci, aby podepsala nebo dešifrovala data, která jim byla předána, a mohou tak učinit, aniž by kdy prozradili klíč. Pokud je to možné, zvažte použití čipové karty nebo HSM. Pokud vím, PgCrypto nemůže používat PKCS#11 nebo jiné HSM/smart karty.

Pokud to nemůžete udělat, stále můžete pravděpodobně použít agenta správy klíčů, kde svůj klíč načtete do programu pro správu klíčů ručně při spuštění serveru a program pro správu klíčů poskytuje rozhraní PKCS#11 (nebo nějaké jiné) pro podepisování a dešifrování přes soket. Vaše webová aplikace tak nikdy nemusí znát klíč. gpg-agent se může pro tento účel kvalifikovat. Opět, pokud vím, PgCrypto nemůže používat agenta správy klíčů, i když by to byla skvělá funkce, kterou by bylo možné přidat.

I malé zlepšení může pomoci. Nejlepší je, když přístupová fráze pro váš klíč není uložena na disku, takže můžete vyžadovat její zadání při spuštění aplikace, aby bylo možné klíč dešifrovat. Dešifrovaný klíč stále ukládáte do paměti, ale všechny podrobnosti k jeho dešifrování již nejsou na disku a lze je snadno získat. Pro útočníka je mnohem těžší ukrást dešifrovaný klíč z paměti, než získat „password.txt“ z disku.

Co se rozhodnete udělat, závisí hodně na podrobnostech vašich potřeb zabezpečení a datech, se kterými pracujete. Na vašem místě bych si hesla prostě neukládal, pokud by to bylo možné, a kdybych musel, chtěl bych použít hardwarové zařízení kompatibilní s PKCS#11.



  1. JQUERY &php post error 500 (interní chyba serveru)

  2. Jak nahrát dlouhý blob (obrázek) do databáze mysql pomocí javy a načíst v php?

  3. Zkontrolujte rovnost v poli MySQL Float

  4. Práce na Postgres-XL 9.5