Je sais, à partir de SQL 2005, il existe des fonctionnalistes intégrés pour ces exigences. Mais je suis concerné pour SQL 2000. P>
S'il vous plaît suggérer Merci. P>
4 Réponses :
Les mots de passe sont généralement stockés avec un hachage d'une manière (par exemple SHA1), ce qui signifie qu'ils sont cryptés et n'ont jamais besoin d'être déchiffrés. Lorsque l'utilisateur entre le mot de passe, votre code hachait et vérifiez si la valeur hachée correspondait à la valeur hachée dans la base de données. P>
Cependant, il semble que vous ayez besoin d'être en mesure de décrypter le mot de passe. Pour cela, il existe plusieurs algorithmes asymétriques (RSA, PGP, etc.) où vous auriez une paire de clés privée et publique. La clé privée est gardée secrète, tandis que la clé publique pouvait être partagée pour que d'autres puissent crypter leurs propres informations avant de vous l'envoyer. On dirait que cela est surchargé, car seul votre code VB6 doit crypter les données et non les 3e parties. Par conséquent, vous pouvez simplement utiliser un algorithme symétrique (comme Blowfish ou tripledes) où vous utilisez la même phrasePhrase (au lieu d'une paire de clés) pour chiffrer et déchiffrer les données. Cette phrase secrète pourrait être stockée dans un fichier de configuration sur le serveur. Assurez-vous de le garder protégé d'utilisateurs non autorisés. P>
Avez-vous vu cet article? Il utilise des triples avec une phrase secrète qui ressemble exactement à ce dont vous avez besoin. http://msdn.microsoft.com/fr- US / Bibliothèque / MS172831 (v = vs.80) .aspx P>
De nos jours, il est considéré comme une mauvaise pratique juste pour chiffrer les mots de passe par eux-mêmes. Souvent une chaîne arbitraire (appelée "sel") est ajoutée à chaque mot de passe, puis de cryptage appliqué. En principe, cela n'a pas d'importance dans quelle séquence vous ajoutez "sel" et chiffrer. Toutes ces combinaisons sont égales dans la force de codage: p>
Le sel est conservé dans une table séparée comme texte brut.
Une autre chose que vous pouvez faire est de chiffrer la même valeur plusieurs fois de suite. Un petit délai pour un utilisateur ne sera pas perceptible, mais cela augmentera les efforts nécessaires à la force brute le mot de passe. P>
C'est aussi une bonne pratique pour nommer des tables afin que les noms de table ne puissent pas être devinés. Il rend les attaques aveugles plus difficiles quand ils ne peuvent pas obtenir de table avec des mots de passe immédiatement. P>
sur un moyen de chiffrer la chaîne. P>
SQL Server 2000 Strong>
Il n'y a pas de fonctions symétriques intégrées.
Il y a 2 fonctions intégrées asymétriques: hachage (Pass & sel) ou hachage (hachage (Pass) + sel) ou hachage (hachage (Pass) + hachage (sel)) code> p> p>
binaire_checksum code> et
checksum code>. P>
Vous pouvez utiliser non documenté pwdencrypt code> et
PWDCompare code> Fonctions disponibles dans SQL Server 2000 -
CREATE TABLE #USER
(
LOGIN_ID varchar(20),
UserPassword nvarchar(256)
)
-- Encrypt & Insert Password
-- Note: You will have to write UPDATE on existing records
INSERT #USER VALUES ( 'my_loginid', PWDENCRYPT('MyPassword1'))
DECLARE @InputPassword VARCHAR(100)
DECLARE @IsValid INT = 0
-- Test for Correct Password
SET @InputPassword = 'MyPassword1'
SET @IsValid = (SELECT PWDCOMPARE(@InputPassword, UserPassword, 0)
FROM #USER
WHERE LOGIN_ID = 'my_loginid')
SELECT @IsValid AS 'Test1';
-- Test for Wrong Password
SET @InputPassword = 'WrongPassword'
SET @IsValid = (SELECT PWDCOMPARE(@InputPassword, UserPassword, 0)
FROM #USER
WHERE LOGIN_ID = 'my_loginid')
SELECT @IsValid AS 'Test2'
DROP TABLE #USER
Permettez-moi de commencer en soulignant que vous avez mentionné que c'était pour un mot de passe. Une protection appropriée des mots de passe est un sujet complexe, mais au minimum, je suggérerais de les saluer et de les hacher. SQL Server inclut une fonction de hachage (PWDENCRYPTIT-il dans SQL Server 2000 mais n'a pas été documentée tant que des versions ultérieures. Les dernières versions incluent des hashbytes qui ont plus d'options), mais cette fonction de hachage n'est pas la plus sécurisée et vous devriez regarder d'autres Options. P>
L'utilisation d'un hachage au lieu d'un cryptage enfreint l'une de vos exigences énoncées pour pouvoir déchiffrer ces champs cryptés, mais avec des mots de passe, il est normalement considéré comme mieux considéré comme pour ne pas pouvoir les déchiffrer. (Vous pouvez comparer une valeur hachée à un mot de passe saisi par l'utilisateur en hachage également le mot de passe, vous ne pouvez tout simplement pas le déchiffrer facilement pour récupérer la version du texte brut.) P>
Si vous voulez vraiment les chiffrer, consultez System.Security.Cryptography Namespace et la classe Simple3Des en particulier pour VB. Il y a une documentation ici et une procédure pas à pas sur les chaînes de cryptage dans un programme ici . p>
VB6 code> ou
vb.net code>? De toute façon, je suis sûr que Google aura beaucoup de résultats pour cela. Pourquoi le cryptage doit-il être réversible de toute façon? Il est habituel de simplement utiliser un hasch à sens unique.
Vb6. Les valeurs de chaîne doivent être d'abord cryptées. Mais, si nécessaire à l'avenir, il faut pouvoir déchiffrer la même valeur cryptée à la valeur de chaîne d'origine.