Alternative appropriée à CryptEncrypt
https://stackoverflow.com/questions/17670
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Nous avons une situation dans notre produit où pendant longtemps certaines données ont été stockées dans la base de données de l'application sous forme de chaîne SQL (au choix du serveur MS SQL ou de sybase SQL n'importe où) qui a été cryptée via la fonction API Windows. CryptEncrypt. (direct et décryptable)
Le problème est que CryptEncrypt peut produire des NULL dans la sortie, ce qui signifie que lorsqu'il est stocké dans la base de données, les manipulations de chaîne tronqueront à un moment donné le CipherText.
Idéalement, nous aimerions utiliser un algorithme qui produira un texte chiffré qui ne contient pas de valeurs NULL, car cela entraînera le moins de modifications possible dans les bases de données existantes (changement d'une colonne de chaîne en binaire et code pour traiter le binaire au lieu des chaînes). et décryptez simplement les données existantes et chiffrez-les à nouveau avec le nouvel algorithme au moment de la mise à niveau de la base de données.
L'algorithme n'a pas besoin d'être le plus sécurisé, car la base de données est déjà dans un environnement raisonnablement sécurisé (pas un réseau ouvert / les inter-webs) mais doit être meilleur que ROT13 (que je peux presque décrypter dans ma tête maintenant!)
modifier:au fait, une raison particulière pour changer le texte chiffré en texte chiffré ?Le texte chiffré semble plus largement utilisé...
La solution
Tout algorithme semi-décent aura de fortes chances de générer une valeur NULL quelque part dans le texte chiffré résultant.
Pourquoi ne pas faire quelque chose comme encodage en base 64 votre blob binaire résultant avant de persister dans la base de données ?(exemple d'implémentation en C++).
Autres conseils
Stocker un hachage est une bonne idée.Cependant, veuillez absolument lire celui de Jeff Vous stockez probablement les mots de passe de manière incorrecte.
C'est un itinéraire intéressant JO.Nous étudions la faisabilité d'une méthode non réversible (tout en veillant à ne pas récupérer explicitement les données à déchiffrer), par ex.stockez simplement un hachage pour comparer sur une soumission
Il semble que le développeur qui gère cela va envelopper le cryptage existant avec yEnc pour préserver l'intégrité de la table car les données doivent être récupérables, ce qui évite tout ce désordre avec infinite-improbab....euhhh changer les types de colonnes sur les installations retranchées.Acclamations gars
