|
WebApp Sec
mailing list archives
RE: Database Encryption -- Sql Injection
From: "Brass, Phil (ISS Atlanta)" <PBrass () iss net>
Date: Thu, 24 Apr 2003 22:05:12 -0400
I'm not a cryptographer, but I believe I read in Schneier that combining
stream ciphers haphazardly can provide weaker crypto strength than
either cipher standing alone. Why wouldn't you use one of the standard
stream or block cipher methods?
Phil
-----Original Message-----
From: Dave Bergert [mailto:dbergert () nobel-net com]
Sent: Thursday, April 24, 2003 9:13 PM
To: 'Kevin Spett'; 'Logan F.D. Greenlee'; webappsec () securityfocus com
Subject: RE: Database Encryption -- Sql Injection
Any valid reason (other then performance) why I couldn't do both?
For Selects:
At Sql Level
Select DecryptRSA(AccountNumber) as AcctNo from
someTable where user = '12345'
At Application Level
AcctNo = DecryptAES(RecordSet("AcctNo"))
For DDL -- Inserts/Updates
Acctno = EncryptAES(AccountNumber)
Insert into someTable AccountNumber Values EncryptRSA(Acctno)
Comments?
Regards,
Dave Bergert
-----Original Message-----
From: Kevin Spett [mailto:kspett () spidynamics com]
Sent: Thursday, April 24, 2003 9:53 AM
To: Logan F.D. Greenlee; Dave Bergert; webappsec () securityfocus com
Subject: Re: Database Encryption -- Sql Injection
I do agree that keeping it in the application is the best
choice. However, it should be noted that if the crypto is
being used correctly, ultimately, it doesn't matter too much.
The security should rely on the secrecy of the key. In a
well-implemented system, an attacker should be able to have
the algorithm and still not have a chance at deciphering the
data. You should be using an industry standard cipher and
not rolling your own.
Kevin Spett
SPI Labs
http://www.spidynamics.com/
----- Original Message -----
From: "Logan F.D. Greenlee" <lgreenlee () ciretose net>
To: "Dave Bergert" <dbergert () nobel-net com>;
<webappsec () securityfocus com>
Sent: Monday, April 21, 2003 10:12 PM
Subject: RE: Database Encryption -- Sql Injection
Dave,
Your best bet will be to do unencryption in the application.
The rationale behind this is that if your database is
compromised by a SQL injection attack, all of the functions,
sprocs, views and tables will be accessible by the attacker.
Thus, the decrypt function in the database can be utilized by
the attacker in compromising your data. If a successful
injection attack is executed against your database, the data
returned by the DB will be useless to the attacker unless
they also have access to the decrypt function in your
application. By separating the two, the attacker must
succesfully compromise your application and your database in
order to compromise your data.
Logan
-----Original Message-----
From: Dave Bergert [mailto:dbergert () nobel-net com]
Sent: Monday, April 21, 2003 9:32 PM
To: webappsec () securityfocus com
Subject: Database Encryption -- Sql Injection
Does any one have any comments on where best to incorporate
Column level encryption in a Database field? At the Database
Server level (via a User Defined Function) or at the
Application Level. Which would be less impervious to SQL Injection?
I am on a MS-SQL 2000 and IIS Platform.
If I had a User Defined Function for example:
Select decrypt(AccountNumber, "key") from tblTable where
User = 'someuser'
If SQL Injection occurs:
Select decrypt(AccountNumber, "key") from tblTable where
User = 'someuser' or 1=1
In this case if SQL injection occurs the encrypted field will
be automatically decrypted by the UDF... Showing all accountNumbers...
If I had the Decryption handled at the Application:
Select encryptedAccountNumber from tblTable where User = 'someuser'
And had the application call:
AccountNumber = DecryptFunction (ResultSet
("encryptedAccountNumber" ),
"key")
If SQL Injection occurs, the only way data could be seen if
through whatever mechanism the application displays the AccountNumber
(Are these scenarios identical ?)
I know that encryption is not a substitution for good input
sanity validation. Which method would be better to implement?
Thanks for comments.
Regards,
Dave Bergert
By Date
By Thread
Current thread:
|