Crypt und DES sind alte Chiffren und sollten nicht verwendet werden
Plain old DES ist ein veralteter Algorithmus. Sie können es nicht wirklich sinnvoll mit AES128 vergleichen; Es ist, als würde man sich darüber beschweren, dass ein SHA256-Hash größer ist als ein MD5-Hash - ja, das ist es, aber nur einer von ihnen könnte den Angreifer für eine Weile verlangsamen. DES wurde selbst 1999 weithin als schwach angesehen und sollte niemals in neuen Anwendungen verwendet werden. Nicht verwenden.
Ich halte es nicht für eine gute Idee, nach einer Verschlüsselungsmethode zu suchen, die "die kleinstmögliche Datengröße bietet" - denn es ist im Grunde Zeitverschwendung, Daten mit DES zu verschlüsseln. Warum nicht ROT13 (Caesar-Chiffre) verwenden? Das "verschlüsselte" Ergebnis hat die gleiche Größe wie die Eingabe, schade, dass die Verschlüsselung von einem 3-Jährigen geknackt werden kann.
Krypta ist von ähnlichem Jahrgang. Der alte UNIX-Crypt-Hashing-Algorithmus ist ... betagt ... und für eine neue Anwendung völlig ungeeignet. Hashes sollten wirklich mindestens SHA256 sein.
Crypt ist ein Einweg-Hash
Wenn Sie nicht herausfinden können, wie verschlüsselte Daten entschlüsselt werden:crypt ist kein Verschlüsselungsalgorithmus, sondern eine kryptografische Hash-Funktion oder "Einweg-Hash". Einweg-Hashes eignen sich zur Überprüfung, ob Daten unverändert sind, im Vergleich zu einem gespeicherten gesalzenen Hash für die Passwortauthentifizierung, zur Verwendung in der Challenge-Response-Authentifizierung usw. Sie können verschlüsselte Daten nicht entschlüsseln.
Kümmern Sie sich um die Größe
Verwenden Sie eine anständige kryptografische Funktion und leben Sie mit der Größenzunahme. bf oder aes128 sind ungefähr die schwächsten, die Sie vernünftigerweise verwenden können.
Persönlich bevorzuge ich meine Verschlüsselung/Entschlüsselung in der App, nicht in der DB. Wenn es in der DB gemacht wird, können die Schlüssel durch pg_stat_statements aufgedeckt werden , in den Protokollen durch log_statement oder Fehler usw. Besser, dass der Schlüssel nie an der gleichen Stelle wie die gespeicherten Daten ist.
Die meisten Programmiersprachen haben gute kryptografische Routinen, die Sie verwenden können.
Es ist schwer, weitere Ratschläge zu geben, da Sie nicht wirklich erklärt haben, was Sie verschlüsseln, warum, was Ihre Anforderungen sind, was die Bedrohung(en) sind usw.
Passwörter?
Wenn Sie Passwörter speichern, machen Sie es wahrscheinlich falsch.
-
Wenn möglich, lassen Sie die Authentifizierung von jemand anderem durchführen:
-
OAuth oder OpenID für Internet
-
SSPI, Kerberos/GSSAPI, Active Directory, LDAP-Bindung, SASL, HTTP DIGEST usw. für das Intranet
-
-
Wenn Sie die Authentifizierung wirklich selbst durchführen müssen, fügen Sie den Passwörtern ein Salz hinzu und hashen Sie das Ergebnis. Bewahre das Haschisch und das Salz auf. Wenn Sie Passwörter vergleichen müssen, salzen Sie den neuen Klartext des Benutzers mit demselben Salt, das Sie für den gespeicherten Hash verwendet haben, hashen Sie das neue Passwort + Salt und prüfen Sie, ob der Hash mit dem übereinstimmt, was Sie gespeichert haben. Wenn ja, haben sie das richtige Passwort angegeben.
-
Sie müssen mit ziemlicher Sicherheit keine Klartext-Passwörter wiederherstellen. Implementieren Sie stattdessen ein sicheres Zurücksetzen des Passworts. Wenn Sie wirklich, wirklich müssen, verwenden Sie einen anständig sicheren Algorithmus wie aes, um sie zu verschlüsseln, und denken Sie sorgfältig über die Speicherung und Verwaltung von Schlüsseln nach. Siehe andere Beiträge auf SO über Schlüsselspeicherung/-verwaltung mit pgcrypto.
Siehe auch:
