Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Comment déchiffrer un mot de passe du serveur SQL ?

L'algorithme de hachage de mot de passe SQL Server :

hashBytes = 0x0100 | fourByteSalt | SHA1(utf16EncodedPassword+fourByteSalt)

Par exemple, pour hacher le mot de passe "bonne agrafe de batterie de cheval" . Nous générons d'abord du sel aléatoire :

fourByteSalt = 0x9A664D79;

Et hachez ensuite le mot de passe (encodé en UTF-16) avec le sel :

 SHA1("correct horse battery staple" + 0x9A66D79);
=SHA1(0x63006F007200720065006300740020006200610074007400650072007900200068006F00720073006500200073007400610070006C006500 0x9A66D79)
=0x6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3

La valeur stockée dans syslogins table est la concaténation de :

[en-tête] + [sel] + [hachage]
0x0100 9A664D79 6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3

Que vous pouvez voir dans SQL Server :

SELECT 
   name, CAST(password AS varbinary(max)) AS PasswordHash
FROM sys.syslogins
WHERE name = 'sa'

name  PasswordHash
====  ======================================================
sa    0x01009A664D796EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3
  • En-tête de version :0100
  • Sel (quatre octets) :9A664D79
  • Hash :6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3 (SHA-1 est de 20 octets ; 160 bits)

Validation

Vous validez un mot de passe en effectuant le même hachage :

  • récupérez le sel du PasswordHash enregistré :0x9A664D79

et effectuez à nouveau le hachage :

SHA1("correct horse battery staple" + 0x9A66D79);

qui sortira avec le même hachage, et vous savez que le mot de passe est correct.

Ce qui était autrefois bon, mais maintenant est faible

L'algorithme de hachage introduit avec SQL Server 7, en 1999, était bon pour 1999.

  • Il est bon que le hachage du mot de passe soit salé.
  • Il est bon d'ajouter le sel au mot de passe, plutôt que de précéder ce.

Mais aujourd'hui, il est dépassé. Il n'exécute le hachage qu'une seule fois, alors qu'il devrait l'exécuter plusieurs milliers de fois, afin de contrecarrer les attaques par force brute.

En fait, l'analyseur de sécurité de base de Microsoft tentera, dans le cadre de ses vérifications, de forcer brutalement les mots de passe. S'il en devine, il signale que les mots de passe sont faibles. Et ça en rapporte.

Forçage brutal

Pour vous aider à tester certains mots de passe :

DECLARE @hash varbinary(max)
SET @hash = 0x01009A664D796EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3
--Header: 0x0100
--Salt:   0x9A664D79
--Hash:   0x6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3

DECLARE @password nvarchar(max)
SET @password = 'password'

SELECT
    @password AS CandidatePassword,
    @hash AS PasswordHash,

    --Header
    0x0100
    +
    --Salt
    CONVERT(VARBINARY(4), SUBSTRING(CONVERT(NVARCHAR(MAX), @hash), 2, 2))
    +
    --SHA1 of Password + Salt
    HASHBYTES('SHA1', @password + SUBSTRING(CONVERT(NVARCHAR(MAX), @hash), 2, 2))

SQL Server 2012 et SHA-512

À partir de SQL Server 2012, Microsoft est passé à l'utilisation de SHA-2 512 bits :

hashBytes = 0x0200 | fourByteSalt | SHA512(utf16EncodedPassword+fourByteSalt)

Changer le préfixe de version en 0x0200 :

SELECT 
   name, CAST(password AS varbinary(max)) AS PasswordHash
FROM sys.syslogins

name  PasswordHash
----  --------------------------------
xkcd  0x02006A80BA229556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A9ABD2A006B33DEC99FCF1A822393FC66226B7D38
  • Version :0200 (SHA-2 256 bits)
  • Sel :6A80BA22
  • Hasage (64 octets) :9556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A9ABD2A006B33DEC99FCF1A822393FC6626Dcode>

Cela signifie que nous hachons le mot de passe encodé en UTF-16, avec le suffixe salt :

  • SHA512("bonne agrafe de batterie cheval" +6A80BA22 )
  • SHA512(63006f0072007200650063007400200068006f0072007300650020006200610074007400650072007900200073007400610070006c006500 + 6A80BA22 )
  • 9556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A9ABD2A006B33DEC99FCF1A822393FC66226B7D38