Crypt en DES zijn oude codes en mogen niet worden gebruikt
Gewoon oude DES is een verouderd algoritme. Je kunt het niet echt nuttig vergelijken met AES128; het is hetzelfde als klagen dat een SHA256-hash groter is dan een MD5-hash - ja, dat is het ook, maar slechts één ervan kan de aanvaller een tijdje vertragen. DES werd al in 1999 als zwak beschouwd en mag nooit worden gebruikt in nieuwe toepassingen. Gebruik het niet.
Ik denk niet dat het een goed idee is om een versleutelingsmethode te zoeken die "de kleinst mogelijke gegevensomvang biedt" - omdat het in feite tijdverspilling is om gegevens te versleutelen met DES. Waarom niet ROT13 (caesar cypher) gebruiken? Het "gecodeerde" resultaat is even groot als de invoer, jammer dat de codering door een 3-jarige kan worden verbroken.
crypt is van een vergelijkbaar oogstjaar. Het oude UNIX-crypthash-algoritme is ... bejaard ... en totaal ongeschikt voor een nieuwe toepassing. Hashes moeten eigenlijk minimaal SHA256 zijn.
Crypt is een one-way hash
Wat betreft het niet kunnen achterhalen hoe versleutelde gegevens moeten worden ontsleuteld:versleutelen is geen versleutelingsalgoritme, het is een cryptografische hashfunctie of "one-way hash". Unidirectionele hashes zijn geschikt om te controleren of gegevens ongewijzigd zijn, in vergelijking met een opgeslagen gezouten hash voor wachtwoordverificatie, voor gebruik in challenge-response authenticatie , enz. U kunt versleutelde gegevens niet decoderen.
Behandel de maat
Gebruik een behoorlijke cryptografische functie en leef met de toename van de grootte. bf of aes128 zijn ongeveer de zwakste die je redelijkerwijs kunt gebruiken.
Persoonlijk geef ik er de voorkeur aan mijn codering / decodering in de app te doen, niet in de DB. Als het in de DB is gedaan, kunnen de sleutels worden onthuld door pg_stat_statements , in de logs door log_statement of fouten, enz. Het is beter dat de sleutel nooit op dezelfde plaats staat als de opgeslagen gegevens.
De meeste programmeertalen hebben goede cryptografische routines die je kunt gebruiken.
Het is moeilijk om nog meer advies te geven, omdat je niet echt hebt uitgelegd wat je versleutelt, waarom, wat je vereisten zijn, wat de dreiging(en) zijn, enz.
Wachtwoorden?
Als je wachtwoorden opslaat, doe je het waarschijnlijk verkeerd.
-
Laat indien mogelijk iemand anders de authenticatie doen:
-
OAuth of OpenID voor internet
-
SSPI, Kerberos/GSSAPI, Active Directory, LDAP-bind, SASL, HTTP DIGEST, enz. voor intranet
-
-
Als je de auth echt zelf moet doen, voeg dan een zout toe aan de wachtwoorden en hash het resultaat. Bewaar de hasj en het zout. Wanneer u wachtwoorden moet vergelijken, zout dan de nieuwe leesbare tekst van de gebruiker met hetzelfde zout dat u voor de opgeslagen hash hebt gebruikt, hash het nieuwe wachtwoord + zout en kijk of de hash hetzelfde is als wat u hebt opgeslagen. Als dat zo is, hebben ze het juiste wachtwoord gegeven.
-
U hoeft vrijwel zeker geen leesbare wachtwoorden te herstellen. Implementeer in plaats daarvan een veilige wachtwoordreset. Als het echt, echt moet, gebruik dan een behoorlijk veilig algoritme zoals aes om ze te versleutelen en denk goed na over sleutelopslag en -beheer. Zie andere berichten op SO over sleutelopslag/-beheer met pgcrypto.
Zie ook: