sql >> Database teknologi >  >> RDS >> Sqlserver

Hvordan dekrypteres en adgangskode fra SQL-serveren?

SQL Server-adgangskode-hash-algoritmen:

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

For eksempel at hash kodeordet "korrekt hestebatterihæftning" . Først genererer vi noget tilfældigt salt:

fourByteSalt = 0x9A664D79;

Og hash derefter adgangskoden (kodet i UTF-16) sammen med saltet:

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

Værdien gemt i syslogins tabel er sammenkædningen af:

[header] + [salt] + [hash]
0x0100 9A664D79 6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3

Som du kan se i SQL Server:

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

name  PasswordHash
====  ======================================================
sa    0x01009A664D796EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3
  • Versionshoved:0100
  • Salt (fire bytes):9A664D79
  • Hash:6EDB2FA35E3B8FAB4DBA2FFB62F5426B67FE54A3 (SHA-1 er 20 bytes; 160 bits)

Validering

Du validerer en adgangskode ved at udføre den samme hash:

  • få fat i saltet fra den gemte PasswordHash :0x9A664D79

og udfør hashen igen:

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

som vil komme ud til den samme hash, og du ved, at adgangskoden er korrekt.

Hvad der engang var godt, men nu er svagt

Hashing-algoritmen, der blev introduceret med SQL Server 7 i 1999, var god til 1999.

  • Det er godt, at adgangskoden hash saltet.
  • Det er godt at tilføje saltet til adgangskoden, i stedet for at forsætte det.

Men i dag er det forældet. Den kører kun hashen én gang, hvor den burde køre den et par tusinde gange for at forhindre brute-force-angreb.

Faktisk vil Microsofts Baseline Security Analyzer, som en del af sine kontroller, forsøge at bruteforce adgangskoder. Hvis den gætter nogen, rapporterer den adgangskoden som svag. Og det får nogle.

Brute Forcering

For at hjælpe dig med at teste nogle adgangskoder:

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 og SHA-512

Fra og med SQL Server 2012 skiftede Microsoft til at bruge SHA-2 512-bit:

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

Ændring af versionspræfikset til 0x0200 :

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

name  PasswordHash
----  --------------------------------
xkcd  0x02006A80BA229556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A9ABD2A006B33DEC99FCF1A822393FC66226B7D38
  • Version:0200 (SHA-2 256-bit)
  • Salt:6A80BA22
  • Hash (64 bytes):9556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A92BFC2A9A92BFC1A9A92BFC2A9A92B2D3A9A92B23D6A92BFC1A9A92B2D3A9A92B2D3A9A92B2Dkode

Det betyder, at vi hash den UTF-16-kodede adgangskode med salt-suffikset:

  • SHA512("korrekt hestebatterihæfteklammer" +6A80BA22 )
  • SHA512(63006f0072007200650063007400200068006f0072007300650020006200610074007400650072007900601kode6A80BA22 )
  • 9556EB280AA7818FAF63A0DA8D6B7B120C6760F0EB0CB5BB320A961B04BD0836 0C0E8CC4C326220501147D6A9ABD2A006B232Acode


  1. Sådan tjekker du datoformatet for din Oracle-session

  2. Kan der opstå dødvande med samme adgangsmetode?

  3. PostgreSQL belastningsbalancering ved hjælp af HAProxy &Keepalved

  4. Når autovakuum ikke støvsuger