Crypt a DES jsou staré šifry a neměly by se používat
Obyčejný starý DES je zastaralý algoritmus. S AES128 to opravdu užitečně srovnávat nelze; je to jako stěžovat si, že hash SHA256 je větší než hash MD5 – ano, je, ale pouze jeden z nich může útočníka na chvíli zpomalit. DES byl široce považován za slabý dokonce i v roce 1999 a nikdy by se neměl používat v nových aplikacích. Nepoužívejte jej.
Nemyslím si, že je dobrý nápad hledat způsob šifrování, který „poskytne co nejmenší velikost dat“ – protože šifrovat data pomocí DES je v podstatě ztráta času. Proč nepoužít ROT13 (caesar cypher)? "Zašifrovaný" výsledek má stejnou velikost jako vstup, škoda, že šifrování může prolomit i 3leté dítě.
šifrovat je podobného ročníku. Starý algoritmus šifrování UNIX je ... starší ... a zcela nevhodný pro jakoukoli novou aplikaci. Hashe by měly být minimálně SHA256, opravdu.
Krypt je jednosměrný hash
Co se týče neschopnosti přijít na to, jak dešifrovat zašifrovaná data:šifrovat není šifrovací algoritmus, je to kryptografická hašovací funkce nebo "jednosměrný hash". Jednosměrné hashe jsou vhodné pro ověření, že data jsou nemodifikovaná, ve srovnání s uloženým salt hash pro ověření hesla, pro použití při ověření odpovědi na výzvu atd. Zašifrovaná data nelze dešifrovat.
Řeďte se velikostí
Použijte slušnou kryptografickou funkci a žijte s nárůstem velikosti. bf nebo aes128 jsou asi nejslabší, které můžete rozumně použít.
Osobně preferuji šifrování/dešifrování v aplikaci, ne v DB. Pokud je to provedeno v DB, klíče mohou být odhaleny pomocí pg_stat_statements , v protokolech pomocí log_statement nebo chyby atd. Je lepší, aby klíč nikdy nebyl na stejném místě jako uložená data.
Většina programovacích jazyků má dobré kryptografické rutiny, které můžete použít.
Je těžké nabídnout další rady, protože jste ve skutečnosti nevysvětlili, co šifrujete, proč, jaké jsou vaše požadavky, jaké jsou hrozby atd.
Hesla?
Pokud ukládáte hesla, pravděpodobně to děláte špatně.
-
Pokud je to možné, svěřte ověření někomu jinému:
-
OAuth nebo OpenID pro Internet
-
SSPI, Kerberos/GSSAPI, Active Directory, vazba LDAP, SASL, HTTP DIGEST atd. pro intranet
-
-
Pokud opravdu musíte provést ověření sami, přidejte do hesel sůl a výsledek hashujte. Uchovávejte hash a sůl. Když musíte porovnat hesla, osolte nový prostý text od uživatele stejnou solí, jakou jste použili pro uložený hash, hashujte nové heslo + sůl a zjistěte, zda je hash stejný jako to, co jste uložili. Pokud ano, dali správné heslo.
-
Téměř jistě nepotřebujete obnovit hesla s čistým textem. Místo toho implementujte bezpečné obnovení hesla. Pokud opravdu, opravdu musíte, použijte k jejich zašifrování slušně bezpečný algoritmus, jako je aes, a pečlivě si promyslete ukládání a správu klíčů. Viz další příspěvky na SO o ukládání/správě klíčů pomocí pgcrypto.
Viz také: