Fundamental weakness in xp_*crypt implementation

Question

Post reply

Fundamental weakness in xp_*crypt implementation

karlmdv

Newbie

Points: 9
More actions
February 5, 2007 at 9:38 pm

#171325

Hi All,

I think I've found a fundamental weakness in the way that the encryption/decryption procedures have been created. Unfortunately I can't make a simple suggestion of how to address the issue.

The following TSQL demonstrates my point:

CREATE PROCEDURE spPM_WaitAWhile (@CanYouReadThis varchar(20))
AS WAITFOR DELAY '00:00:30'
GO

Find your SPID & run the new proc:

SELECT @@SPID
EXEC spPM_WaitAWhile 'This is a secret'

Open another query window and run this (replacing XX with your spid from above):

DBCC INPUTBUFFER(XX)

I believe that this method reduces the effective security of our encryption regime to the strength of the sa / admin users password since the decryption key can actually be viewed while the process is running by any user with sufficient DB privileges. If the period of time where decryption occurs is too small for the above method to be practical, logging could be enabled. Either way the key's there for the taking.

I'm trying to protect data within the database from users on the local network while considering the username / password authentication offered by MS SQL server weak. The only suggestion I can make to try and mitigate the above considerations is that the xp which performs the decryption could source it's key from somewhere other than a parameter (ala ssh-agent / pageant utilities used for key caching for use with ssh clients).

Any thoughts?

-Karl.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply

Mike C SSC-Insane Points: 23224 More actions · Answer 1

If you're using the DBA Toolkit, the key being passed into the XP is passed in as an encrypted key. So the plaintext key should not be visible at any time. The keys passed in are not decrypted until *after* they have been passed into, and are under the control of, the XPs. The keys are being stored in encrypted form in a database table. So being able to view the keys via DBCC INPUTBUFFER should, at best, give the same result as SELECTing the encrypted keys from the table in the database.