Crypt og DES er gamle cypher og bør ikke bruges
Almindelig gammel DES er en forældet algoritme. Du kan ikke rigtig sammenligne det med AES128; det er som at klage over, at en SHA256-hash er større end en MD5-hash - ja, det er den, men kun én af dem vil muligvis bremse angriberen i et stykke tid. DES blev alment betragtet som svag selv i 1999 og bør aldrig bruges i nye applikationer. Brug det ikke.
Jeg tror ikke, det er en god idé at søge en krypteringsmetode, der "giver den mindst mulige datastørrelse" - for det er i bund og grund spild af tid at kryptere data ved hjælp af DES. Hvorfor ikke bruge ROT13 (caesar cypher)? Det "krypterede" resultat har samme størrelse som inputtet, skam at krypteringen kan brydes af en 3-årig.
krypt er af lignende årgang. Den gamle UNIX-krypt-hashing-algoritme er ... ældre ... og totalt uegnet til enhver ny anvendelse. Hashes bør være SHA256 som minimum, virkelig.
Crypt er en envejs-hash
Med hensyn til ikke at være i stand til at finde ud af, hvordan man dekrypterer krypterede data:krypt er ikke en krypteringsalgoritme, det er en kryptografisk hash-funktion eller "one way hash". One way hashes er velegnede til at verificere, at data er umodificerede, sammenlignet med en lagret saltet hash til adgangskodegodkendelse, til brug i udfordring-svar-godkendelse , osv. Du kan ikke dekryptere krypterede data.
Hør med størrelsen
Brug en anstændig kryptografisk funktion og lev med størrelsesforøgelsen. bf eller aes128 er omtrent de svageste, du med rimelighed kan bruge.
Personligt foretrækker jeg at lave min kryptering/dekryptering i appen, ikke i DB. Hvis det er gjort i DB, kan nøglerne afsløres af pg_stat_statements , i logfilerne ved log_statement eller fejl osv. Bedre at nøglen aldrig er på samme sted som de lagrede data overhovedet.
De fleste programmeringssprog har gode kryptografiske rutiner, du kan bruge.
Det er svært at give flere råd, da du ikke rigtig har forklaret, hvad du krypterer, hvorfor, hvad dine krav er, hvad truslen/truslerne er osv.
Adgangskoder?
Hvis du gemmer adgangskoder, gør du det sandsynligvis forkert.
-
Hvis det er muligt, så lad en anden udføre godkendelsen:
-
OAuth eller OpenID til internettet
-
SSPI, Kerberos/GSSAPI, Active Directory, LDAP bind, SASL, HTTP DIGEST osv. til intranet
-
-
Hvis du virkelig skal udføre godkendelsen selv, skal du tilføje et salt til adgangskoderne og hash resultatet. Gem hashen og saltet. Når du skal sammenligne adgangskoder, skal du salte den nye klartekst fra brugeren med det samme salt, du brugte til den gemte hash, hash den nye adgangskode+salt, og se om hashen er den samme, som du har gemt. Hvis det er, gav de den rigtige adgangskode.
-
Du behøver næsten helt sikkert ikke at gendanne cleartext-adgangskoder. Implementer en sikker nulstilling af adgangskode i stedet. Hvis du virkelig, virkelig skal, så brug en anstændigt sikker algoritme som aes til at kryptere dem og tænk grundigt over nøglelagring og -styring. Se andre indlæg på SO om nøgleopbevaring/-styring med pgcrypto.
Se også: