web-dev-qa-db-fra.com

Comment savoir quel algorithme de hachage SQL Server a utilisé pour déchiffrer les données chiffrées lors de l'utilisation de la fonction DECRYPTBYPASSPHRASE?

Ma question est liée à l'expérience suivante avec deux instances:

Instance SQL Server 2017 Express (Microsoft SQL Server 2017 (RTM-CU16))
Instance SQL Server 2014 Express (Microsoft SQL Server 2014 (SP2-CU18))

J'ai utilisé la fonction ENCRYPTBYPASSPHRASE pour crypter un texte et utilisé le résultat comme @ciphertext pour DECRYPTBYPASSPHRASE . Les résultats de mes tests étaient les suivants:

Table of results

Selon cela correctif Microsoft ,

[...] SQL Server 2017 utilise l'algorithme de hachage SHA2 pour hacher la phrase secrète. SQL Server 2016 et les versions antérieures de SQL Server utilisent l'algorithme SHA1 qui n'est plus considéré comme sécurisé.

Mais comment sait-il quel a été l'algorithme utilisé pour chiffrer les données s'il n'y a aucun argument lié à celui-ci sur la fonction DECRYPTBYPASSPHRASE? Fait-il partie des données chiffrées?

D'après les résultats de mes tests, je suppose que SQL Server utilise toujours la version la plus récente de l'algorithme disponible sur l'instance pour chiffrer les données, mais essaie tous les algorithmes pour déchiffrer les données jusqu'à ce qu'il en trouve un qui corresponde ou renvoie NULL quand aucun algorithme correspondant n'est trouvé . C'est juste une supposition, car je n'ai trouvé aucun moyen de vérifier quel algorithme de hachage SQL Server a utilisé pour déchiffrer les données chiffrées.

sql-serverencryption
12
Ronaldo

Mais comment sait-il quel a été l'algorithme utilisé pour chiffrer les données s'il n'y a aucun argument lié à celui-ci sur la fonction DECRYPTBYPASSPHRASE? Fait-il partie des données chiffrées?

Oui, juste sur le point.

Je vais utiliser ce qui suit pour la sortie:

DECLARE @Data VARBINARY(MAX)
DECLARE @Text NVARCHAR(MAX) = N'I''ll get you, and your little dog too!'
DECLARE @Phrase NVARCHAR(100) = N'Fly My Pretties!'

SELECT @Data = ENCRYPTBYPASSPHRASE(@Phrase, @Text)

SELECT @Data AS [Encrypted_Data]

SELECT CAST(DECRYPTBYPASSPHRASE(@Phrase, @Data) AS NVARCHAR(MAX))

Si j'exécute cela sur mon instance 2014, j'obtiendrai ce qui suit pour Encrypted_Data: 0x01000000E565142762F62...

Si j'exécute cela sur mon instance 2017, j'obtiendrai ce qui suit pour Encrypted_Data: 0x020000004D261C666204F...

Ce qui devrait sortir est le préambule, où vous pouvez voir l'instance 2014 commence par 0x01 et l'instance 2017 commence par 0x02. Il s'agit du versioning du type de cryptage utilisé. Notez qu'il y a plus que cela, mais il n'est pas nécessaire d'entrer dans les détails pour les besoins de cette réponse, ni d'être public.

SQL Server 2017 comprend 0x01 et 0x02 parce que c'est nouveau et connaît les nouvelles choses. SQL Server 2014 comprend uniquement 0x01 parce qu'il est plus ancien et ne connaît aucune des nouvelles choses car les nouvelles choses n'ont pas été rétroportées.

[...] SQL Server 2017 utilise l'algorithme de hachage SHA2 pour hacher la phrase secrète. SQL Server 2016 et les versions antérieures de SQL Server utilisent l'algorithme SHA1 qui n'est plus considéré comme sécurisé.

Ce n'est pas la même chose, mais cela concerne généralement la création de clés symétriques avec le même vecteur d'initialisation sur les deux versions. J'ai blogué à ce sujet lorsque 2017 est sorti et il a été corrigé un peu plus tard avec l'indicateur de trace qui doit être utilisé alors que dans votre question, aucun indicateur de trace n'est nécessaire pour 2017 pour lire les données de 2014 comme indiqué.

14
Sean Gallardy