Discussion :

[new_wave]

Bonjour,

Je viens de lire le tutoriel de Mr Brouard sur le cryptage des données.

J'utilise une base de données Ms Sql serveur et souhaiterais uniquement crypter le mot de passe.

Je lis que le cryptage est préférable au hashage.
Si je choisis le cryptage du mot de passe, plutôt que le hashage, je lis dans ce tutoriel que dans Ms Sql serveur
le chiffrement est intégré dans toutes les versions.

Cel signifie-t-il qu'il est possible de crypter les données ou, que si le type de données est password(dans une application asp.net) alors elles le sont automatiquement?

Si ce n'est pas le cas, et que je doive crypter les données manuellement, alors la création d' une clef de cryptage se fait-elle ainsi ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
-- création d'une clef de cryptage de niveau base de données 
-- permettant la génération de clefs de cryptage interne
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Le petit chat est mort.';
GO
 
-- création d'une clef de cryptage avec algorithme AES- clef à 256 bits
CREATE SYMMETRIC KEY MA_CLEF
WITH ALGORITHM = AES_256 
    ENCRYPTION BY PASSWORD = 'P@ssw0rd !';
 
-- ouverture de la clef pour la session
-- peut être fait côté serveur dans un déclencheur FOR LOGON et dans ce cas
-- le mot de passe ne sera pas codé dans les applis ni transmis dans le réseau
OPEN SYMMETRIC KEY MA_CLEF
DECRYPTION BY PASSWORD = 'P@ssw0rd !';

Ces deux instructions me permettront elles de crypter uniquement le mot de passe?

Maintenant , au niveau du code de mon application, qui est en C#, faut il également que je fasse appel à une fonction de cryptage?
J"avoue que je suis un peu perdue .

Je vous remercie vraiment beaucoup de bien vouloir m'aider sur ce point.
Bien cordialement.

new_wave

[SQLpro]

Pour chiffrer une information, il faut : ouvrir la clef (OPEN SYMETRIC KEY), transformer la donnée claire en données chiffrée à l'aide de la fonction de chiffrement adaptée (dans votre cas ENCRYPTBYKEY) puis refermer la clef.

Pour contrôler la validité d'un mot de passe envoyé par un utlisateur, vous devez faire l'inverse en déchiffrant la valeur stockée et en la comparant avec la valeur passée. par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE PROCEDURE dbo.P_VERIFY_PASS @USER VARCHAR(32), @PASSWORD VARCHAR(32)
AS
OPEN SYMMETRIC KEY MA_CLEF
DECRYPTION BY PASSWORD = 'P@ssw0rd !';
 
SELECT CASE WHEN @PASSWORD = DECRYPTBYKEY(KEY_GUID('MA_CLEF'), @PASSWORD) THEN 1 ELSE O END AS PASS_OK
FROM   dbo.T_USER
WHERE  USR_NAME = @USER;
 
CLOSE SYMMETRIC KEY MA_CLEF;
 
GO
 
 
CREATE PROCEDURE P_VERIFY_PASS @USER VARCHAR(32°, @PASSWORD VARCHAR(32)
AS
SELECT CASE WHEN @PASSWORD

A +

Et pour compléter votre savoir :

[new_wave]

Bonjour et Merci de votre réponse.

Si je procède ainsi, je peux donc me dispenser d'écrire du code C# pour hasher un mot de passe avec une fonction de type ComputeHash(qui fait appelle au hashage avec SHA256) et une autre pour comparer le mot de passe saisi avec celui en base de données?

Vous remerciant encore de votre réponse,

Bien cordialement,

new_wave

[SQLpro]

Oui et il vaut mieux car votre cryptage ne serait pas salé et donc ne résisterait pas aux attaques de type "force brute", alors que SQL Server le sale automatiquement afin que deux motifs identiques ne donne pas le même code chiffré (c'est essentiellement à cause de cela que les allemands ont perdu la guerre de 39-45 !)

A +

[new_wave]

Bonjour et merci beaucoup de votre réponse.

Je voudrais juste vous informer qu'il existe une fonction de salage en C# qui ajoute du salage à votre hashage( non, vous n'êtes pas à un cours de cuisine...).

Mais je vais procéder comme vous me l'avez conseilé, çà a l'air juste plus facile...

Bien cordialement.

new_wave

[new_wave]

Bonjour,

Je reviens vers vous concernant la clé de cryptage.


1-Concernant les instructions suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
-- création d'une clef de cryptage de niveau base de données 
-- permettant la génération de clefs de cryptage interne
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Le petit chat est mort.';
GO
 
-- création d'une clef de cryptage avec algorithme AES- clef à 256 bits
CREATE SYMMETRIC KEY MA_CLEF
WITH ALGORITHM = AES_256 
    ENCRYPTION BY PASSWORD = 'P@ssw0rd !';

est-il nécessaire de les insérer dans la procédure dbo.P_VERIFY_PASS ou , comme je le pense , il n'est pas nécessaire de recréer la clé à chaque appel de la procédure dbo.P_VERIFY_PASS

si c'est le cas, je créerais donc une procédure qui crée la clé de cryptage et que j'appelle une seule fois, puis ensuite, j'appelle la procédure dbo.P_VERIFY_PASS à chaque fois que j'ai besoin de crypter /décrypter un mot de passe.

Je vous remercie beaucoup de bien vouloir confirmer ou infirmer cette démarche à suivre,

2- l'algorithme AES_256 est il assez "costaud" ou existe -il un algorithme plus puissant, qu'il est préférable d'utiliser ?

Bien cordialement.

new_wave

[elsuket]

Pour revenir sur le salage, il est avantageux de crypter, si effectivement le cryptage se fait par salage, dans l'application.
De ce fait, les valeurs sont cryptées dans tout l’échange de données entre l'application et la base de données.

Petit aparté : Avec la fonctionnalité Always Encrypted de SQL Server 2016, le pilote qui implémente Always Encrypted permet à une application de se connecter à une base de données de détecter que la colonne cible est encryptée.
De ce fait, les valeurs sont automatiquement encryptées avant d'être soumises au moteur de base de données.

est-il nécessaire de les insérer dans la procédure dbo.P_VERIFY_PASS ou , comme je le pense , il n'est pas nécessaire de recréer la clé à chaque appel de la procédure dbo.P_VERIFY_PASS

Effectivement il n'est pas nécessaire de recréer la clé de cryptage à chaque fois.
D'ailleurs les spécifier dans le code de la procédure stockée représenterait en soi un trou de sécurité

si c'est le cas, je créerais donc une procédure qui crée la clé de cryptage et que j'appelle une seule fois, puis ensuite, j'appelle la procédure dbo.P_VERIFY_PASS à chaque fois que j'ai besoin de crypter /décrypter un mot de passe.

C'est bon, mais attention à l'utilisateur auquel vous octroierez le droit d'exécution de la première procédure stockée

l'algorithme AES_256 est il assez "costaud" ou existe -il un algorithme plus puissant, qu'il est préférable d'utiliser ?

C'est le plus costaud que propose SQL Server pour le moment
Notez que vous pouvez protéger la clé symétrique par un certificat, qui contient une clé asymétrique.
Si vous décidez de partir sur cette solution, il vous faudra sauvegarder le certificat, et potentiellement sa clé privée en lieur sûr (cf. instruction BACKUP CERTIFICATE).
Pour "bétonner" un cran encore au-dessous, vous pouvez utiliser un module matériel de sécurité (voir SQL Server Extensible Key Management et Hardware Security Module), qui gère les clés pour vous ... mais là ce n'est pas le même prix

@++

[new_wave]

Bonjour et merci beaucoup de tous ces conseils précieux.

J'exécuterai la première procédure moi-même .

Pour ce qui est de la création de la clé de cryptage , vous proposez deux possibilités : création d'une clé de cryptage de niveau base de données permettant la génération de clefs de cryptage interne et création d'une clef de cryptage avec algorithme AES- clef à 256 bits

Faut il les créer toutes les deux , ou seulement l'une des deux et si seulement l'une des deux, laquelle est la plus adaptée à mon besoin (crypter le password pour un forum)?

Autre question : pour ce qui est de l'ouverture de la clé, vous proposez de l'insérer dans le code d'un trigger de type logon.

Or la syntaxe de création d'un tel trigger utilise l'option on all server.Est il possible de faire en sorte que cela ne concerne qu'une table d'une base de données précise et pas tout ce qui existe sur le serveur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
CREATE TRIGGER TR_audit_ouverture_key
ON ALL SERVER

Vous remerciant encore de votre aide sur ces deux points,

Bien cordialement.

new_wave