Laurentiu Cristofor's blog @microsoft.com : computer security

New attack on AES-256

lcris — Thu, 15 Oct 2009 00:05:00 GMT

A new attack improves significantly on previous attacks against AES-256, see: http://schneier.com/crypto-gram-0908.html#8. This doesn't mean that AES-256 is broken yet, but the surprising bit here is that AES-128 is not susceptible to this particular attack. Don't panic if you are using AES-256 and read Bruce Schneier's commentary carefully - for example, note that the attack is against a 10 round AES-256, while standard implementations use 14 rounds.

It's interesting to see that the strength of AES-256 is eroded by new attacks, but AES-128 doesn't suffer from them yet. It's another example that larger (or more expensive) isn't necessarily also better.

SQL Injection watch blog

lcris — Sat, 15 Aug 2009 00:34:00 GMT

I was looking for information on a new SQL injection attack when I stumbled upon this very useful blog: http://s3cwatch.wordpress.com/. It's worth a look from time to time, to get an idea of what attacks are going on in the wild.

Basic SQL Server Security concepts: ownership, CONTROL, TAKE OWNERSHIP

lcris — Wed, 12 Aug 2009 01:39:00 GMT

I realized today that while I have discussed earlier object permissions, I have not gone into the details of object ownership. I want to cover the following here: ownership of objects, how it can be changed, and the relatively new permission CONTROL (introduced in SQL Server 2005).

Ownership: This should be pretty clear - the owner of an object is usually its creator, but a different owner can be specified at creation time using the AUTHORIZATION clause. The owner of an object has all possible permissions on that object and, most importantly, cannot be denied those permissions while he continues to be an owner.

CONTROL permission: The CONTROL permission can be used to easily grant all permissions on an entity to some principal. It's the next best thing after ownership of the entity, but it's not quite as powerful as ownership. The main difference is that a grantee of CONTROL can still be denied some other permissions on the entity. For example, I can be granted CONTROL on a table, while at the same time I can be denied SELECT on that table, preventing me from selecting from it - this can never happen to the owner, because the owner cannot be granted or denied permissions.

Changing ownership: To change the owner of an entity, we can use the ALTER AUTHORIZATION statement. Changing ownership of an object creates some interesting scenarios in terms of what should be allowed and what should not be. Basically, owners should not be able to "dump" their objects to other users who may not want them and users should not be able to "steal" objects from those that own them. To accomplish this, two checks are needed: one controls to whom ownership can be given to - we verify that the performer of the change has some right on the new owner (we check for IMPERSONATE for users and logins, ALTER or membership for roles, etc); the other check controls from whom ownership can be taken away: we require the performer of the change to have TAKE OWNERSHIP permission on the object.

Note as a corollary that a grantee of CONTROL permission on an object has the ability to take ownership of the object because CONTROL implies the TAKE OWNERSHIP permission as well - the way to prevent this would be to grant CONTROL and deny TAKE OWNERSHIP.

TAKE OWNERSHIP is thus used to selectively grant someone the ability to willingly become the owner of an object or to facilitate the change of ownership of that object.

Side effect of ownership change: A potentially surprising side effect of changing ownership of an object is that all permissions granted on that object will be lost. As always, it's a good idea to script all permissions granted on an entity before changing its ownership, so that the grants can be re-executed by the new owner, if appropriate.

TechCrunch anatomy of the Twitter attack

lcris — Fri, 24 Jul 2009 02:38:00 GMT

http://www.techcrunch.com/2009/07/19/the-anatomy-of-the-twitter-attack/

The first step of registering an old email account to receive the password from a current account was a nice and easy way to break into an email acount. After that, things pretty much fell like dominoes, but it's nice to see how inconspicuous a smart attacker can be. This story also reminds us the painful fact that the only way you can know about some security breach is if the attacker is destructive, or less skilled, or wants you to know. The victims of this attack could have spent the rest of their lives without knowing that their information is being monitored.

A SQL Injection attack and search engines

lcris — Tue, 05 Aug 2008 22:07:00 GMT

A few weeks after my previous posting of a SQL Injection Advisory link, a new SQL Injection attack came up. Here's a post describing it; it also includes other useful links:

http://www.rtraction.com/blog/devit/sql-injection-hack-using-cast.html

A search for the query string "http://1.verynx.cn/w.js" (the quotes are part of the search string) shows that there are still sites infected today.

So, SQL Injection is alive and kicking - no big surprise here. But what may come as a surprise to you, if you're not aware of it yet, is that there is a further vulnerability here: vulnerable sites are discoverable using a search engine - it happens when the SQL Injection results in some link getting inserted in web pages, as is the case in this recent attack. This means another attacker can use a search engine to get a list of vulnerable sites and hack them a second time, for a more devastating effect. This is an instance of Search Engine Hacking - Google Hacking is currently the popular term, but any search engine can be used, not just google. Note that this is not really about hacking the search engine, but about using the search engine for hacking.

Here is more in-depth information on this techique of search engine hacking:

Google Hacking for Penetration Testers
Google Hacking page on Wikipedia
Google Hacking Database

Also note that search engine hacking goes beyond SQL Injection attacks - the sources mentioned above contain more examples of searching for different vulnerabilities. If you're the administrator of a Web site, you cannot afford to ignore this technique.

New Microsoft Security Advisory on SQL Injection

lcris — Wed, 25 Jun 2008 21:56:00 GMT

This came up yesterday: http://www.microsoft.com/technet/security/advisory/954462.mspx. It has good information and links.

A discussion of password authentication schemes

lcris — Fri, 09 May 2008 23:45:00 GMT

I have talked in the past about how passwords for SQL logins are protected in SQL Server (see this post). I would like to describe this scheme in a more generic way and compare it with the alternative of encrypting the passwords, because I have seen people wondering which method they should use.

First, what is authentication? Authentication is the process we go through to verify the identity of a user. It should not be confused with authorization, which is about what actions we allow an already identified user to do. Authorization happens after authentication and relies on its result.

Authentication schemes are based on information falling in three large categories: what the user knows (passwords, PINs, birth date, mother's maiden name), what the user has (id card, badge, debit card, credit card, smartcard), and what the user is (photograph, retina scan, fingerprint, voice recognition). Sometimes combinations are used - a debit card requires knowing its PIN and an identification card will have some biometrics information like a photograph and maybe height and weight information as well.

The goal of password authentication is therefore to verify a user's identity based on a password associated with him that only he should know. If more people know the password, then we cannot really authenticate the user - we're authenticating the group of people that know the password. The good thing about a password is that we can commit it to memory and we can later recall it when we need it - the fact that it resides only in memory is appealing from a security point of view because others can't yet read our minds reliably. The bad thing about a password is that we have to commit it to memory and we may fail to recall it later when we need it - this is an inconvenience that may not have any security impact by itself, but it usually leads to one because, to avoid the situation, we'll usually pick something easy to remember which might also be easy to guess. Writing it down on a piece of paper is not that bad as long as we keep that piece of paper secure. A password is also vulnerable during the moment it leaves our mind to be presented for authentication - by typing it on a keyboard or by saying it on the telephone. Note that all these observations apply to any authentication method based on what the user knows - in fact, the other ones I listed have more problems than passwords - PINs are shorter, and the birth date and the mother's maiden name are not only known to one person.

So let's look at how we can perform password authentication.

Method 1 - Store: Store the user password somewhere in the system. Whenever the user provides his password, we compare it with the stored one and, if they match, we have successfully authenticated him.

Problems: One, but big: the password is stored in clear, meaning that whoever has access to the storage place can learn the passwords stored there. This is a big problem because it means the password can be accessed by bypassing the application and just examining the disk; it will be there if the disk breaks down and gets replaced, for example. How can we improve this? A particularly bad direction would be to try to come up with our own obfuscation scheme for not storing the passwords in clear. We'll not go there, so let's look at proven technologies. We can use an encryption algorithm that has already proved its usefulness in the field.

Method 2 - Store encrypted: Have some encryption key created for the purpose of encrypting passwords. We store the user password encrypted with this key and whenever the user will provide us with his password, we'll decrypt the stored one and compare them.

Problems: A couple smaller ones: the first problem is about finding a way to protect the encryption key, the second problem is that anybody with access to the encryption key will still have access to all the passwords. Finding a way to protect the encryption key is tricky - as I mentioned in other posts, encryption doesn't really solve the problem of protecting information - it just changes the problem of protecting a lot of information into a problem of protecting a tiny bit of information - the encryption key. Whether we address this issue or not, there is no denying that it adds some complexity to the solution. I also don't like the idea that administrators of the system could know my password - yes they could send it back to me if I forget it, but they could also leak it or just use it to find out more about how I choose my passwords. So, I am not happy with this solution - how can we improve it? Well, here comes hashing! Hashing works one-way - you can get a hash from some information, but you cannot retrieve that information from the hash.

Method 3 - Store hash: Choose a hashing algorithm and store the hash of the user password. When the user provides his password, hash it and compare the result against the stored hash.

Problems: One tiny one: Hash collisions - it is possible for two different passwords to have the same hash value, but cryptographic hash algorithms make this very unlikely. Also, there's no way we can find out a password if the user forgets it - we'll have to instead change his password and provide him with the new password and a method of changing it. Of course, before doing this we have to figure out another way of authenticating him - Web applications usually solve this problem by sending the password to the email account associated with the user.

What did we gain with this method? The password is not stored in clear, we don't have any encryption keys to manage, and we have better guarantees that the system and its administrators are not able to retrieve the passwords from the stored hashes. The administrators can still monitor the system when you are providing the password, but that is more difficult than just decrypting the encrypted passwords and is an issue that all these password authentication methods have anyway.

But it's not over yet! We can make this better. To understand why, let's look at how we can attack this method and whether we can thwart some attacks.

A simple way to attempt to retrieve passwords from hashes would be to build a large collection of possible passwords - we won't be able to have all possible passwords in it, but we can collect a lot of likely passwords and we can grow this collection over time. Once we have this collection, we can hash all these passwords using the same algorithm that the application uses (we can reverse engineer it by examining the application or we can simply use the application itself to generate the hashes by creating accounts for all those potential passwords). Whatever the method, we can end up with a collection of hashes and corresponding passwords - we now have a dictionary that we can use to attempt to break other hashes by simply looking them up in it. Of course, we won't be able to break any password, but if we break one and it happens to be an administrator account, it's enough.

This sounds bad, right? You're bound to have some users with poor passwords, maybe even administrators (sa with empty password was a bane of many SQL Server installations) and this attack will break those passwords. It's important to remember that a prerequisite for this attack is to have access to the password hashes in the first place, which is not trivial to get except for the administrators. But this is still not very nice and there is actually a little trick we can do that will make a dictionary attack much more costly.

Method 4 - Store salted hash: The trick we'll use is to add some randomness to the hash generation process - this is called "salting" the hash. What we're going to do is to randomly generate a piece of information called the "salt" for each password that is set for a user. This salt will be combined with the password and we'll store both the salt and the hash in the system. Whenever the user will submit a password, we'll lookup the salt and hash, we'll combine the salt with the submitted password, we'll hash the result and we'll compare it against the stored hash.

How can we combine the salt with the password? One simple way is to prepend the salt to the password - this will work well with most hashing algorithms. Appending the salt may not be as good - it may end up affecting only part of the hash, depending on how the hash algorithm works. If you want to get creative here, look for more information about the hashing algorithm in a cryptography book.

How does this help with the dictionary attack? Well, because for each hash we have a salt value, a single dictionary won't cut it anymore - the attacker would have to build a dictionary for each salt value - and that is expensive because hashing is not a cheap operation.

How large should a salt be? If you make it too small, 1 byte, for example, it is still feasible to build 256 dictionaries to cover all possible values of that salt. So salts should be picked up to be larger values. For example, a 4 byte salt would require more than 4 billion dictionaries - this is the value used in SQL Server 2005.

Security in a nutshell

lcris — Wed, 23 Apr 2008 23:48:00 GMT

Here's an attempt to succintly describe why achieving security is difficult:

The engineer wants to implement a program P that allows users to perform action A.
The hacker looks at program P and wonders how can he use it to perform actions other than A.
The security guy wants to implement a program P that allows users to perform action A and only action A.

Some observations based on this description:

- defining A precisely is harder than it may sound
- it can be non-trivial to implement P so that it performs A
- if P fails to accomplish A, it will likely accomplish something else than A
- there is a cascading effect that increases the probability of not being able to achieve the security guy's goal

SQL Server: Password policy FAQ

lcris — Thu, 21 Feb 2008 03:18:00 GMT

I am starting this post to collect frequent Q&A related to password policy. I plan to keep updating the post if anything new is worth adding to it. Note that this FAQ does not cover SQL Server Compact Edition. Also note that BOL stands for Books OnLine.

Q: What is the SQL Server password policy feature?

A: Password policy is a feature introduced in SQL Server 2005 for the purpose of strengthening SQL Authentication by having it enforce the same password policies that Windows is set to enforce. This means password policy is specific to SQL logins. A password policy determines what passwords are acceptable and also when they expire or whether the account should be locked out after a number of unsuccessful login attempts due to the use of incorrect passwords.

While the primary use of password policy is to strengthen SQL Authentication, password policy is also enforced whenever setting a new password with the encryption features introduced in SQL Server 2005 - this enforcement only refers to password strength; there is no expiration/lock out enforcement for these passwords. This enforcement cannot be disabled.

Q: On what versions of SQL Server is the password policy available?

A: The password policy enforcement is done using a new API introduced in Windows 2003: the NetValidatePasswordPolicy API. Thus, password policy is only available on versions of the Microsoft Windows OS starting with the 2003 version. Note that if this API ever gets backported to older OSs, then SQL Server should automatically start using it. The best way to determine if something changed about the availability of this feature on older OSs is to check the API page for any updates.

Note that on older OSs, SQL Server does perform a few basic password complexity checks, as described at the end of this password policy BOL article. However, this is all that is available on older OSs - there are no lock out or expiration features.

Password policy is not restricted based on SQL Server edition.

Q: How do I use the password policy feature?

A: If you are creating a new login using CREATE LOGIN, you can use two clauses related to password policy: CHECK_POLICY and CHECK_EXPIRATION. If they are not specified, the default for CHECK_POLICY is ON and for CHECK_EXPIRATION is OFF. These options can be changed at a later time using ALTER LOGIN. CHECK_POLICY governs the bulk of password policy enforcement related to password strength and lock out. CHECK_EXPIRATION separately covers the enforcement of password expiration, which was considered too disruptive for the rolling out of this feature, to be enabled by default. CHECK_EXPIRATION is also required when using the MUST_CHANGE option, to force a password change on the first login through that account. CHECK EXPIRATION depends on CHECK_POLICY; other dependencies are covered in BOL.

Q: How do I manage this feature using Management Studio?

A: There should be checkboxes in a login properties dialog corresponding to the T-SQL options. A GUI can change more often than T-SQL syntax, so I prefer to describe features using the T-SQL interface. Also, I prefer to use only T-SQL for SQL Server management operations.

Q: How do I check the password policy settings on my system?

A: Execute secpol.msc, then look at Account Policies. If you are on a standalone machine and you are an administrator, you can change these settings. If your machine is joined to a domain, these settings are controlled by the domain administrator.

Q: Why can't I set the policy options for Windows logins in SQL Server?

A: Because Windows logins already benefit from password policy enforcement at the OS level.

Q: I keep getting messages about my password not being acceptable when creating a new login. How do I fix this?

A: The error message will usually indicate what the problem is; for example, it will tell you if the password is too short. To find more details about what restrictions are in place for passwords, you can check the policy settings using the secpol.msc tool, as described in a previous answer. You can also disable the policy enforcement for the login, but this is not recommended as it can make that login more vulnerable to a bruce force attack.

Q: I am running SQL Server on Windows XP/2000, etc. Does this mean I cannot benefit from password policy enforcement?

A: Pretty much, yes. On OSs that don't support the password policy API, SQL Server only performs a tiny number of checks on the password strength - to prevent you, for example, from using an empty password. The actual checks are described in the last part of this password policy BOL article. These checks are governed by the CHECK_POLICY settings, so they can be turned off or on. If you ever hit a password policy error on older OSs than Windows 2003, then you really need to revisit the method you are using to pick passwords.

Q: I am getting a password policy error even though I run on Windows XP/2000. I thought there is no password policy enforcement for these systems. What's going on?

A: You are using really weak passwords. See above answer.

Can encryption make you more vulnerable?

lcris — Tue, 12 Feb 2008 03:57:00 GMT

A recent article brings up this question and argues that encrypting data at rest can open the door to a new range of security and usability problems. Speaking only of the security aspects, I both agree and disagree, so I'd like to add a few comments on this topic.

I think that the article makes a very good point that represents a great truth about security: the features you build to protect against attackers could end up being used by the attackers against you - this is the double-edged aspect of security. Once a system is compromised and the attacker gets to control it, he can use its defenses against the lawful users. This is not a new idea, but it is one that can be easily forgotten when adding new security features.

That being said, I don't think that the scenario presented in the article about ransoming data is a new or very interesting scenario. Here are the reasons why:

- An attacker can use his own encryption routines to encrypt the data - it doesn't matter if the compromised system had any encryption capabilities. Malware with the capability to encrypt data has existed for years and cyber-criminals are known to be proficient at using encryption to protect their data. Thus, ransoming is not really a new threat - it just appears new to those that also see encryption as a new technology.
- Ransoming could only work in a database system that lacks a disaster recovery procedure. Data loss is an ever-present threat for databases - even if ransoming would be new, it would be addressed by the same measures that address an old threat - data/key backups.
- The weakest link in ransoming is the ransom collection - that's where the attacker exposes himself - this makes ransoming not very tempting.
- Ransoming is also a bad idea because it tells the system owner that his system has been breached and gives him a chance to close that breach.
- If an attacker can get access to data worth ransoming, it is more easy for him to make money from selling it and keeping his access secret than by attempting to ransom it.

However, I do think that encryption can make you more vulnerable - it can do that by giving people a false sense of security if they think that just by having data encrypted, it becomes secure. I went in a bit more detail about this idea here, but the point is that deploying encryption is not only about encrypting data but about carefully considering how the data will be accessed and about securing that access - sadly, the latter part is where the security of most applications fails. Encryption addresses well certain scenarios such as stealing data at rest, but those scenarios do not necessarily represent how most data is getting compromised today.

SQL Server undocumented password hashing builtins: pwdcompare and pwdencrypt

lcris — Wed, 31 Oct 2007 21:08:00 GMT

First, I must say that I don't know why these exist in an undocumented form. They have been around for a long time and a search on their names gets me back pages of hits. Being undocumented means that their actual implementation may change slightly from one version of SQL Server to another, mainly because the password hash format could change - and it has changed for the last three major versions of SQL Server. They could also disappear entirely in a future release. So, you shouldn't write applications relying on these functions, but they may come in handy for ad-hoc queries, when you know they're available.

So here's a short description of the two functions:

pwdencrypt: takes a varchar value as parameter and returns a varbin value that is the SQL Server password hash of the input value. I have seen people talking about the use of this function for hashing passwords when implementing custom application authentication. Do not use this! Starting with SQL Server 2005, you can use instead the HashBytes function, to implement any custom hashing scheme that you want. HashBytes provides you with direct access to several hashing algorithms, so there is no point in using pwdencrypt. In fact, I can't come up with any useful need for pwdencrypt and the only reason I included it here is to warn you against using it.

pwdcompare: takes two arguments - a varchar value that is a cleartext password and a varbin value that is a SQL Server password hash, and returns 1 if they match and 0 if they don't. There is a third optional parameter that can be set to 1 if the second parameter represents a pre-SQL Server 2000 password hash value. This third parameter will most likely be dropped in a future SQL Server version.

pwdcompare is useful if you are an administrator looking for accounts that have weak passwords. For example, to query for logins that have an empty password, the following queries can be used (first one will work on SQL Server 2000 and the second one uses the SQL Server 2005 new catalogs):

select name from sys.syslogins where pwdcompare('', password) = 1
select name from sys.sql_logins where pwdcompare('', password_hash) = 1

Obviously, these queries can be used to search for other weak passwords than empty ones. Does this constitute a threat against the strength of password hashes by allowing a TSQL brute-force attack? Not really, because such an approach would be very slow - it would be much more efficient to attempt such an attack using a compiled program, and even such approach would only have a good chance of success against a short or weak password. So, the pwdcompare function doesn't make an attacker's job easier. Other than helping administrators with checking for weak passwords, I can't think of another use for this function.

Basic SQL Server Security concepts: SIDs, orphaned users, and loginless users

lcris — Fri, 26 Oct 2007 03:42:00 GMT

I am grouping here two topics (orphaned users and loginless users) that are actually very different, but I have often seen confusion between them, so I am covering them together in an attempt to dispel that confusion.

In a previous discussion of logins and users, I pointed out that the way a login gets mapped to users in databases is via its SID value. This mapping is a one to many mapping - a login maps to several users (each one in a different database), but a user maps back to a single login. When a Windows login is created, its SID value is taken to be the SID of the corresponding Windows principal, but for SQL Server specific logins the SID values are generated at creation time, unless they are explicitly provided via the SID clause of CREATE LOGIN. The SID value represents the identity of the login and is invariant for the life of the login - this is why the SID clause is not available for ALTER LOGIN.

The SID link between a login and a user can be severed when databases are moved from one server to another - this is because on the new server, there may be no login having the same SID as that user. When such a situation happens, we say that the user was orphaned - it becomes an orphan user. Orphan users can also result from the deletion of a login - in previous versions, SQL Server attempted to warn about the existence of corresponding users, but even that check would fail to detect users in databases that were offline, so SQL Server 2005 no longer performs it (it was also an expensive check, as it required accessing each database). The bottom line is that orphaned users can appear in various ways and we have to either fix them when they occur or we have to prevent them from occurring at all. The classic method for restoring the SID link was to use the sp_change_users_login procedure, but starting with SQL Server 2005 SP2, a new LOGIN clause of ALTER USER has also been made available, which helps fix Windows users in addition to SQL users - a feature that sp_change_users_login was lacking. These methods will fix the SID of a user to match that of a login, effectively remapping the user to match the login. For the preventive approach, the main tool we have available is to create logins with an explicit SID value - this will help when moving a database between two or more servers, by allowing us to create in advance SQL Server logins that not only have the same name, but the same SID value as well. This will also help with recreating a login that was inadvertently dropped.

Some people seem to think that having the possibility to change a login's SID to match that of a user would be a great feature. That is not true. Changing a login's SID would be wrong because it would attack the problem on the wrong side of the login-user relationship. When fixing the user SID, only that SID needs to be changed and this would be a database scoped operation, but when fixing a login SID, all corresponding user SIDs would have to be changed as well, otherwise we would generate more orphaned users instead of fixing them - and fixing all users mapped to a login isn't a task that can be easily performed, because it would require the availability of all databases in which the login is mapped - something that cannot be guaranteed. There is a good reason why this issue is referred to as orphaned users and not as childless logins.

So, orphaned users are an issue that normally requires some fixing, when it occurs. Loginless users, on the other hand, are an intentional construct. They are created using the WITHOUT LOGIN clause of CREATE USER and they represent standalone users that cannot map to a login (they have special SID values preventing this), so you cannot connect to a database as a loginless user, although you can impersonate one via EXECUTE AS. A loginless user is valuable in many situations where an application needs to have users that don't necessarily correspond to a human user. For example, an application may be in need to create objects from time to time and to designate an owner for them - it could do this in the caller's context, but that would mean the caller would end up owning objects he may not be aware of - it is better for the application to designate a loginless user as the owner of those objects. One of my favorite uses of loginless users is to break ownership chains (see previous discussion) by assigning different loginless users as owners. Raul has a lengthier post on the topic of loginless users that offers further examples of use, including some TSQL sample code.

SQL Server 2005: A note about the use of certificates

lcris — Fri, 05 Oct 2007 06:59:00 GMT

To avoid any confusion, this post is not about the use of certificates for securing the communication between a client machine and the server; instead, this refers to the use of certificates created via the CREATE CERTIFICATE DDL.

I am prompted in writing this post by a recent question I just saw, which I know I answered many times before, but I now realized I never wrote about it here. The question is simply around the differences between how certificates are used elsewhere and how certificates are used in SQL Server. I'll answer this question here and I'll add some additional information and references, which I hope you will find useful.

The main use of certificates that we are familiar with from daily browsing activities is about the signing of code on the Internet. This signing is done as a way to prove the authenticity of a piece of software, because a signature can help validate the manufacturer of a piece of software. I say "can help", because not everyone checks carefully the details of a digital signature to ensure it is indeed trustworthy. For more details around this type of use scenario, you can look into PKI - Public Key Infrastructure.

Certificates can be used in many ways, because asymmetric key encryption is a very powerful tool, so, when certificates were introduced in SQL Server, one of the design goals was to build a generic store for encryption keys, without putting any unnecessary restrictions on their use. Because of this, expiry settings or certificate revocation are not enforced. SQL Server just regards the certificate as a key container and keeps track of all of its settings, but it doesn't restrict its use - it is up to you to decide what to do with it. The main use scenarios within SQL Server do not require any restrictions, so the only thing that is done is to give some warnings at the time the certificate is imported - if it was expired, for example. I should also note that features within SQL Server may do additional checks on a certificates's settings: for example, the Service Broker feature does check for expiration of its certificates. If your intent is to plug into PKI, that is also possible through CLR.

So, what are the main use scenarios for having certificates in SQL Server? Here they are:

1. You can use certificates to sign T-SQL code.
2. You can use certificates to encrypt symmetric encryption keys or small pieces of data.

Let's discuss these a little. Signing T-SQL code is the most powerful security feature shipped with SQL Server 2005 (my opinion, of course, as is any other subjective evaluation you may read on this blog). But, really, think about it: signing allows you to grant permissions to code instead of granting them to principals calling the code - this opens a world of possibilities in terms of how you can manage permissions and how you can restrict access to objects. So that you don't get any wrong idea at my enthusiasm for this feature, I will add that I made no significant contributions to it, so I am not trying to push forward my work ;) For a simple example of the things you can do with signing, you can have a look at this example. Raul's blog has additional examples and information on this feature.

You can also use special builtin functions (SignByCert) to sign your own data, but unfortunately, due to a bug, their implementation uses the MD5 algorithm instead of the SHA1 algorithm used in T-SQL signing, so they are not interoperable - you cannot use these functions to simulate the internal code signing, so that you could manually compute the signature of a function, for example; instead, you would need to actually create the function and sign it via ADD SIGNATURE, then read the signature blob from the system catalogs.

The second use of certificates is quite natural for an encryption key - we would definitely like to encrypt something with it. The reason why certificates are more convenient to use for protecting symmetric keys than other methods is simply because they can be backed up individually. This also gives them an edge over their cryptographic sibling - the asymmetric keys. For a discussion of why there are two objects encapsulating RSA keys in SQL Server, see this explanation.

Some people think that certificate encryption is inherently safer than symmetric key encryption - it is not. There is no significant gain in strength from securing your data with an RSA key instead of using an AES one, as long as you are using equivalent key lengths - not equal, but equivalent - more on this below. The RSA encryption is slower than any symmertric key encryption and its larger key length is simply due to it being a fundamentally different technique and requiring longer key lengths than symmetric key algorithms, to offer the same strength of encryption. For a discussion of key lengths and a comparison of key lengths across symmetric and asymmetric algorithms, you can check this article or a cryptography book. This means that certificates are not appropriate for data encryption and their use should be restricted to the encryption of symmetric keys (which are small enough that the encryption performance is not a concern) and to the application of digital signatures (when the key is only used to encrypt what is basically a hash of the signed data, hence, again, performance is not a concern given that the length of a SHA1 hash value is 20 bytes/160 bits).

SQL Server 2008: Transparent data encryption feature - a quick overview

lcris — Thu, 04 Oct 2007 02:55:00 GMT

I have kept silent on this feature while it was being developed, but as it has now been publicly advertised in various ways (being mentioned here, here, here, and here, for example), I think it is probably time to write a bit about it. Given that my posts so far have covered SQL Server 2005, I'll point out again that this is a SQL Server 2008 feature!

The transparent data encryption feature in the next SQL Server version is the last feature I worked on while I was in the SQL Server security team, before my move to MSR. Transparent data encryption is quite a long name, so I'll just refer to it as TDE from now on.

TDE addresses two of the encryption requests we have received most often from forum questions and from discussions with customers:

(1) a way to enable data encryption without affecting applications that consumed that data (for an idea of what problems are raised when encrypting a table column in a database, see this post)
(2) a way to encrypt an entire database

TDE addresses both these requests by providing a database level encryption feature. Both the data and the log files of a database are encrypted on disk and get decrypted when they are read into memory. This makes encryption really transparent to applications. Because database applications attempt to minimize their I/O (a costly operation), tying encryption and decryption to I/O will also take advantage of existing application design optimizations to minimize the performance impact of encryption.

It is important to note that TDE should not be perceived as a replacement of the encryption solutions shipped with SQL Server 2005; instead, TDE should be viewed as a complementary feature providing encryption at a coarser granularity level. Whereas the encryption features introduced in SQL Server 2005 provide a way to encrypt individual pieces of data (something we refer to as cell-level encryption, because it offers finer granularity than column level encryption), the new TDE feature enables encryption at database level. Also, from a cryptographic point of view, the algorithms used in TDE have also been available with the cell-level encryption, so the two features offer the same encryption strength.

The encryption of a database with TDE is done using a special key called, simply, database encryption key (or DEK, for short). The DEK can be managed using standard DDL (CREATE/ALTER/DROP) and the actual state of the encryption can be turned on or off using the ALTER DATABASE statement and a new clause: SET ENCRYPTION [ON | OFF]. Information about DEKs can be gathered from a DMV called sys.dm_database_encryption_keys. If you like using a GUI for database operations, all these features are also exposed from within Management Studio. I prefer typing SQL queries when it comes to managing a database, which is the reason why in my posts you'll find more details about DDL and system catalogs than about menus and dialog options.

If you have a CTP build, you can quickly check for the presence of the TDE feature by issuing the following statement: alter database <db_name> set encryption on. A syntax error will mean that the feature is not present, while a more specific error message will indicate that the feature is available - note that the statement should result in no state changes anyway, as long as you have not used TDE before. As of today, to my knowledge, only the latest CTP build includes this feature.

Security and copy protection

lcris — Tue, 25 Sep 2007 01:57:00 GMT

I have been watching the SQL Server Security forum for several years now and there is one question that gets spawned about once a month under different titles. It invariably begins with a request for guidance on how to secure access to a database, which sounds like a reasonable security inquiry, but after a while it becomes clear that the subject is copy protection for some application's database. All right, but why does it matter? Well, it matters because these are very different topics. (Note that I am using copy protection as an umbrella term - these days, DRM is the fashionable term, which stands for digital rights management and which covers more than the simple operation of copying. But I'm trying to keep things simple.)

Let's see what security and copy protection are about. Security is about controlling access to data - a person is either allowed to access the data or not. Security may restrict the way in which the access can be gained, but it cannot control what the person will do with the information once he gets access to it - that person may give it away, sell it, or store it for his personal use. This is where copy protection comes in and attempts to establish some control over the use of the data. The goal of copy protection is to restrict what the user can do with some information once he already got it. To be sure, the goal of copy protection may pertain to security, but the problem is that there are no viable techniques that allow us to achieve that - the techniques used so far are simply not capable of providing the guarantees that one associates with security techniques.

But why is copy protection a hard problem? The difficulty of achieving copy protection should become immediately apparent with the following simple example: let's say the data I want to protect is a confidential telephone number. There is no way one can possibly copy-protect that, because no matter what access restrictions one would set around the record storing the phone number, the people that have access to it can do whatever they want with it. There is no techology that we can use to enforce the restrictions we would like placed on that telephone number. Some solutions may come to mind, but they are either extreme, or expensive, or both: permanent surveillance of the persons that came into contact with the phone number (Big Brother method), restricting the contact that those persons have with any unauthorized person (imprisonment technique), or inflicting capital punishment on those persons (medieval approach) - so, basically, there are no solutions that we can implement in IT. What remains is recourse to the legal system - we can launch an investigation in the leak of the telephone number and we can hope to catch the culprit and have him sentenced - this may not help that much after the fact, but it might be a strong enough deterrent.

At this point, someone may argue that the example I gave above is simplistic - that we may not care about the loss of a single phone number but about the loss of 1 billion phone numbers that cannot possibly be memorized by a person, or that the information that we want to protect is hard to memorize - maybe it is an image or an audio file. Well, it doesn't matter. What that simplistic example shows is that there is a hole that cannot be covered - the fact that the user gets access to the information whose use we are supposed to restrict. Having more information to protect may make the user's task of copying it more difficult if he only has access to a pen and a bit of paper, but when the user has a computer in his hands - a tool designed to relieve man from tedious activities such as computing or memorizing lots of stuff - then there is really no additional difficulty raised.

But what about all those copy protection schemes that are in use today? How do they work - or do they work? They are there, indeed, but what all of them do is that they obfuscate data with a secret algorithm hard coded in software that knows how to provide the data to the user in a limited set of scenarios, but would not allow other scenarios. This sounds hopeful until you realize that there is no way to really protect the algorithm from a curious user - the computer has to execute it and whatever the computer executes, the user can read - it's his machine after all and he only needs to invest some time (a few months) into reading a book that teaches the assembly language of his computer - he just needs to be literate and fairly intelligent. This problem of being able to discover the obfuscation algorithm may not seem a high risk to some, but the situation is even worse: you only need one dedicated person to figure the algorithm out and to write a program that reverses the obfuscation, and then he can distribute that software for the use of all the other people that want unrestricted access to the data - and this time they only need to know how to download a piece of software of the Internet.

If after reading this one still has a shadow of a doubt, it must be related to the use of encryption. Encryption is supposed to be the panacea to any security problem: you want data protection - encrypt it; you want double protection - encrypt it twice. The truth is that encryption will only help if properly used and in the case of copy protection, its use will degenerate into obfuscation, as I have already discussed in this post. Some copy protection schemes use encryption to some extent, but the problem of securing the encryption key is where designers have to rely on obfuscation and that is what the attackers will go after. But actually, in most cases, the implementation of the encryption algorithm or of the entire application is flawed in such a way that data can be accessed without even worrying about getting the encryption keys.

The difference between security and copy protection can be likened to the difference between encryption and obfuscation. With encryption (and other security schemes), the data has some strong guarantee of being secure even if the algorithm is made public, as long as the encryption key is kept secret; in fact, all successful commercial algorithms have had their details made available to researchers before and after being adopted. With obfuscation, the data is safe as long as the algorithm is kept a secret, but as soon as the algorithm is discovered, the entire scheme fails - and there is no way to keep the algorithm secret against a smart attacker that has access to the code that executes the algorithm and to the machine on which the algorithm executes.

Another way of illustrating the difference is via the following generic scenarios. In a security scenario, Alice wants to grant Bob access to some data and does not want Charles to have access to that data. In a copy protection scenario, Alice needs to grant Bob access to some data but wants to prevent him from communicating that data to Charles. Same characters, but very different story.

Final comparison - copy protection is about preventing the dissemination of some information, while security is about preventing access to it in the first place.

By this time, it should be clear that copy protection schemes are not offering any security, because they cannot provide any reasonable guarantees around their policy enforcement. But are copy protection schemes really useless? From a security point of view, my answer is yes. From a practical point of view, my answer is that a copy protection scheme may serve some purpose if the product using it has limited use and its users are either not interested, or they are not capable of breaking the scheme, or they don't have the financial capabilities of hiring someone who can. There is some inherent irony here: the more successful a product will become, the less effective its copy protection scheme will be, as it will attract more attention.

The best bet is to work around the need for a copy protection scheme. One way to do this is to have a software application be reliant on an online service requiring some sort of validation from its company's servers. For example, an online RPG requires the use of game servers and even if the credentials would be shared, only one person can play at any time. Another way would be to have the software only run on dedicated devices, whose use is limited - see video game consoles - there is still the risk of copying the media, but if the media used is expensive to produce (game cartridges), then this risk is alleviated somewhat.