Crypt et DES sont d'anciens chiffrements et ne doivent pas être utilisés
Le DES ancien est un algorithme obsolète. Vous ne pouvez pas vraiment le comparer utilement à AES128; c'est comme se plaindre qu'un hachage SHA256 est plus gros qu'un hachage MD5 - oui, c'est vrai, mais un seul d'entre eux pourrait ralentir l'attaquant pendant un certain temps. DES était largement considéré comme faible même en 1999 et ne doit jamais être utilisé dans de nouvelles applications. Ne l'utilisez pas.
Je ne pense pas que ce soit une bonne idée de rechercher une méthode de chiffrement qui "fournit la plus petite taille de données possible" - car c'est essentiellement une perte de temps de chiffrer des données à l'aide de DES. Pourquoi ne pas utiliser ROT13 (chiffre César) ? Le résultat "crypté" est de la même taille que l'entrée, dommage que le cryptage puisse être cassé par un enfant de 3 ans.
crypte est d'un millésime similaire. L'ancien algorithme de hachage de chiffrement UNIX est... âgé... et totalement inadapté à toute nouvelle application. Les hachages doivent être SHA256 au minimum, vraiment.
Crypt est un hachage unidirectionnel
Quant à ne pas être en mesure de comprendre comment décrypter les données cryptées :crypt n'est pas un algorithme de chiffrement, c'est une fonction de hachage cryptographique ou "hachage à sens unique". Les hachages à sens unique conviennent pour vérifier que les données ne sont pas modifiées, en les comparant à un salé hachage pour l'authentification par mot de passe, à utiliser dans authentification challenge-response , etc. Vous ne pouvez pas décrypter les données cryptées.
Traiter avec la taille
Utilisez une fonction cryptographique décente et vivez avec l'augmentation de la taille. bf ou aes128 sont à peu près les plus faibles que vous pouvez raisonnablement utiliser.
Personnellement je préfère faire mon chiffrement/déchiffrement dans l'application, pas dans la BD. Si c'est fait dans la base de données, les clés peuvent être révélées par pg_stat_statements , dans les logs par log_statement ou des erreurs, etc. Mieux vaut que la clé ne soit jamais au même endroit que les données stockées.
La plupart des langages de programmation ont de bonnes routines cryptographiques que vous pouvez utiliser.
Il est difficile de donner plus de conseils car vous n'avez pas vraiment expliqué ce que vous chiffrez, pourquoi, quelles sont vos exigences, quelles sont les menaces, etc.
Mot de passe ?
Si vous stockez des mots de passe, vous vous trompez probablement.
-
Si possible, laissez quelqu'un d'autre faire l'authentification :
-
OAuth ou OpenID pour Internet
-
SSPI, Kerberos/GSSAPI, Active Directory, liaison LDAP, SASL, HTTP DIGEST, etc. pour intranet
-
-
Si vous devez vraiment faire l'authentification vous-même, ajoutez un sel aux mots de passe et hachez le résultat. Conservez le hasch et le sel. Lorsque vous devez comparer des mots de passe, salez le nouveau texte en clair de l'utilisateur avec le même sel que vous avez utilisé pour le hachage stocké, hachez le nouveau mot de passe + sel et voyez si le hachage est le même que celui que vous avez stocké. Si c'est le cas, ils ont donné le bon mot de passe.
-
Vous n'avez presque certainement pas besoin de récupérer les mots de passe en clair. Implémentez plutôt une réinitialisation sécurisée du mot de passe. Si vous le devez vraiment, utilisez un algorithme sécurisé comme aes pour les chiffrer et réfléchissez bien au stockage et à la gestion des clés. Voir d'autres articles sur SO à propos du stockage/de la gestion des clés avec pgcrypto.
Voir aussi :
