Secure the Authentication Process

SQL Server supports two authentication mechanisms: Windows authentication and SQL Server (SQL) authentication.  With Windows authentication, SQL Server simply validates a user’s Windows identity with an identity management solution such as Active Directory.  With SQL authentication, SQL Server generates, stores, and manages instance-specific user name and password information.  While SQL Server can be configured to employ SQL authentication in addition to the Windows authentication default, it is strongly discouraged as SQL authentication is vulnerable to brute-force attacks. That’s not to say that Windows authentication is invulnerable to attack. In fact a new feature, Extended Protection, was introduced with SQL Server 2008 R2 to thwart one such attack.

Extended Protection

The man-in-the-middle (MITM) attack is executed by a malicious application which impersonates the SQL Server service to a client and the client to the service.  In doing so, the malicious application places itself in the middle of the communications channel between the client and server and from this vantage point can intercept messages transmitted between the two. (This attack is also referred to as authentication relay.)

To thwart this attack, SQL Server registers its identity as a Service Principle Name (SPN) with Active Directory (typically at the time of installation).  The client obtains the SPN as part of the connection process and validates this against the SPN held by SQL Server.  If the malicious application does not have access to the SPN, the connection is not completed.

This process is referred to as service binding and it protects against scenarios where the malicious application lures the client to it.  If the client voluntarily connects to the malicious application (usually due to spoofing), then channel binding can be employed to block the MITM attack.

With channel binding, the SQL Server service sends the connecting client the public key associated with a private key it maintains.  The client generates a value known as the Client Binding Token (CBT), encrypts it with the service’s public key, and transmits the encrypted CBT to SQL Server. Using its private key, SQL Server decrypts the CBT and then uses the CBT to encrypt the channel between it and the client.  Without the private key, the malicious application cannot decrypt the CBT and therefore cannot access the data passed between the client and server.

Read more: Data Otaku

Posted via email from Jasper-net