All this sounds perfect (except for if I’m out of the country and I can’t get their text messages), except for one little issue.

Adding a new cell phone to send a text message to is as simple as just logging onto the bank’s webpage. Once I log into the site I can simply add another cell phone, verify that I have the cell phone via a text message and then I can use that cell phone to approve any wire transfers. All very convenient. The problem is that is someone else figures out my username and password for the website they to can add a cell phone to my bank account, approve it for use, then start sending wire transfers off all my money to their account.

So while Bank of America has two factor authentication, the second factor is dependent on knowing the first factor. For this to be actually useful two factor authentication it would need to require that I go into a branch with my ID to prove that I’m me and that I can add the phone as a two factor authentication phone. Additionally they should be using as an option one of the phone application based two factor authentication processes so that if I have several phones I can just use the one application, or if I’m not in the country I can still manage my money (which has been a problem a couple of times).

While I applaud the effort that Bank of America has put into having two factor authentication, doing it correctly would be a lot more useful.  As currently you have one factor authentication with an annoyance.

Denny

Recently I was setting up access to just another high security system and I was presented with this list of questions (I had to select three) as my security questions so that I can get my account back if (when) I forget my password.

Lets review these questions for a minute.  Now some of these Facebook actually asks you to provide them so that they can put them on your profile (that annoying part at the top of your Facebook profile).   The rest you can probably figure out about most people just by looking at the information that they provide during the course of using social media in their daily lives and with the groups on Facebook that they belong to.  You add access to a public linked in profile and a little searching in public records and getting most if not all of these answers shouldn’t take you more than a couple of hours.

As the people that build these applications we need to take more notice of just how easy it is to figure out these questions.  The questions that we are putting into the applications shouldn’t be so annoying as “Favorite Teacher’s Last Name”, which I’ve actually seen but they need to be stuff that is at least a little harder to figure out if these are the things that we are going to use to ensure that people are who they say they are.

Things like drivers license number or state ID number (for those without a drivers license) are a good start.  They don’t change all that often (except when you move between states).  Social Security Numbers basically never change so those aren’t a bad number to use (granted there are other issues with using a persons tax ID here in the US).

When you are designing these sorts of authentication systems, don’t assume that just because your paranoid ass doesn’t upload your entire live to Facebook, LinkedIn and Twitter that no one else does that either.  People do, do that and they will continue to do that.  If you want to actually provide a level of security for your customers, which I sure hope that you do as that is kind of your job, then assume that the customers will be posting the easy to figure out questions online for all to see so you might want to use some slightly more complex questions.

Denny

Database chaining is when permissions cascade from one object to another because they are used by the parent object.  The perfect example is a stored procedure which accesses a table.  The user only needs rights to the parent object (the stored procedure) and the rights to access the table exist automatically because the stored procedure accesses the child object (the table).

Cross database chaining uses this exact same concept except that the parent object is in one database and the child object is in another database.  In order to use cross database chaining the feature needs to be enabled on both databases.  This is done by using the ALTER DATABASE statement as shown below on both databases.

ALTER DATABASE A_Database SET DB_CHAINING ON

Once this is done, the login which is mapped to the user within the database which has the parent object needs to be mapped to a login within the database which has the child object.  The user within the database which owns the child object doesn’t need any specific rights other than to be a member of the public role.  Once this is done the cross database permission chain will be made and the stored procedure (or other parent object such as a trigger or function) will begin working.

Denny

During this full day precon we will review a variety of ways to secure your SQL Server databases and data from attach.  In this session we will review proper network designs, recommended firewall configurations, and physical security options.  We will also review our data encryption options, password protection options, using contained databases, and AlwaysOn Availability Groups security.  There will also be discussions about additional measures which should be taken when working with Internet facing applications.

From there we will move to the most dangerous attack vector SQL Injection including all the ways that attackers can use SQL Injection to get into your system and how to protect against it.  The security options for database backups is the next topic on the list followed by proper SAN security designs.  We will then finish up by reviewing the auditing options which are available and how they can be used to monitor everything else which we’ve just talked about during the course of the day.

If you are interested in attending the precon check out the precon page on the SQL South West website which has the registration link.  I look forward to seeing you there.

Denny

In this technique we’ll encrypt the data using just a single column.  This technique requires butting some additional logic within the application to figure out if the value is encrypted or not, but other than that logic, which you can leave in and strip out later the changes to the application are pretty minimal as the column stays the same, so that means that the stored procedures don’t need to be changed.

The first thing to remember is that the encrypted data will be larger, possibly much larger than the plain text version of the data.  Because of this you’ll need to increase the size of the field which you’ll be putting the data into.  Now the good news is that if this column isn’t indexed this change should be pretty quick and easy as it should just be a meta change which tells the SQL Server that the column size can be bigger without having to actually change the pages.  You can see this by making some changes to the [HumanResources].[Employee] table within the AdventureWorks database.  By turning on STATISTICS IO and using the ALTER TABLE statement we see that there is no IO generated when we change the size of the LoginID column from nvarchar(256) to nvarchar(512).

set statistics io on
alter table MyTable
alter column LoginID nvarchar(512)

Once the column is made larger the .NET code needs to be modified to see if the data is compressed for not.  Now there is no sure fire way to check to see if a value has been encrypted or not, but a pretty good test is to look at the last two characters of the value.  If they are both an equal sign (==) then it is probably safe to assume that the value is encrypted.  To don’t want to just attempt to decrypt the data and look for an error message, and if there is an error assume that the encrypted value is in plain text, throwing and catching error messages in .NET is very expensive, especially compared to simply checking to see if the last two characters are an equal sign.  This isn’t to say that you shouldn’t have TRY/CATCH logic around the code that decrypts the values as someone could easily enough put two equal signs at the end of their password.

At this point either a .NET app or a T-SQL script can loop through the values in the table which aren’t encrypted and then encrypt them, updating the rows which aren’t already encrypted.

Look for more blog posts in this series on how to encrypt data which already exists within your applications database.

Denny

I’m afraid that I’ve got some bad news.  You can no longer pre-order Securing SQL Server 2nd Edition from Amazon.

Instead you have to settle for ordering the book outright and having it shipped to you.  That’s right, no more being a pre-order book, it’s published and available to be shipped directly to you.  Currently Amazon is selling the book at full price which is $49.95, but if you have Amazon Prime it is available for Amazon Prime shipping.  Because it is considered to be a text book you get a $5 Amazon MP3 Credit (what ever terms and conditions that Amazon chooses do apply).

This is a totally updated edition of the book including all sorts of new information about security within SQL Server 2012.  I of course cover things like how to secure AlwaysOn Availability Groups, how to use user defined server roles, contained users, etc. I also dive into how to properly secure SQL Server Reporting Services and SQL Server Analysis Services so they can’t be used to access data that people shouldn’t have access to.

All in all this book is much larger with Amazon showing it at 408 pages compared to just 272 pages for the 1st edition.  If you find someone cheaper to purchase it make sure that you are in fact ordering the second edition.  The ISBN number is 1597499471.

I hope that you pick up a copy of the book and that it is useful for you in securing your SQL Server environment.

Denny

Not only was this breach a major embarrassment for Yahoo! but it is a potential nightmare for their customers.  If those customers (there were a few hundred thousand in the list) use the same email address and password on other websites they’ve now had the username and password for those other services leaked as well.

Now I know that best practice for Internet security says that every website should have a different password, but for the bulk of Internet users this simply isn’t going to happen.  Among IT professionals the percentage of people that actually use a different password for each website is probably pretty close to zero.  I know that I personally use dozens of different websites a month, and for most people that it probably pretty normal between banks, credit card companies, Facebook, Twitter, work sites, Gmail, etc. that quickly gets up to dozens or hundreds of passwords which need to be remembered.  There are plenty of password vault type applications, but general Internet users aren’t going to be using them.  As IT professionals we need to remember that we are dealing with the general public and the general public isn’t going to know that they need to do this, no matter how many times we talk about it within the IT field.

One reason that there is lots of unencrypted data out there is that converting older applications from using plain text data to encrypted data is pretty hard to do.  There are lots of places within the application which need to be touched and there are possibly lots of different applications which need to be updated all at once.  Then there is the possibility of needing to take an outage to do the actual data change.  When it comes down to is biting the bullet and taking the outage and making the change.  It is well worth it to take the outage and encrypt all the data now, rather than have to worry about a data breach later.

There are lots of techniques which you can use to do this data encryption, to many to list in a single blog post so look for blog posts from me later on how to handle this change.  There are also plenty of consultants, including myself, who are happy to help with projects like this.

Denny

The really sad thing about this is that it is very easy for software developers to protect against SQL Injection attacks.  The way that software developers protect the application from SQL Injection is by using parameterized queries instead of the older, and usually easier technique of simply building the database query using variables in the software code.

One of the reasons that I that I think that SQL Injection is just a big problem is thanks to the separation of duties that we have at most companies.  The reason that I say this is because the software developers that build the applications never have to deal with the cleanup from the SQL Injection attack.  Many developers, probably because they don’t work all that closely with database administrators, see SQL Injection as a SQL Server problem not an application problem.  This thinking would be wrong, as the only way to prevent SQL Injection problems is to protect the data at the application layer by using coding best practices like using parameterized queries like that shown below, taken from Chapter 8 of my book Securing SQL Server (this sample is for VB.NET, the book includes examples in C# as well as VB.NET).

Private Sub MySub()
Dim Connection As SqlConnection
Dim Results As DataSet
Dim SQLda As SqlDataAdapter
Dim SQLcmd As SqlCommand
SQLcmd = New SqlCommand
SQLcmd.CommandText = “sp_help_job”
SQLcmd.CommandType = CommandType.StoredProcedure
SQLcmd.Parameters.Add(“job_name”, SqlDbType.VarChar, 50)
SQLcmd.Parameters.Item(“job_name”).Value = “test”
Connection = New SqlConnection(“Data Source=localhost;Initial Catalog=msdb;Integrated Security=SSPI;”)
Using Connection
Connection.Open()
SQLcmd.Connection = Connection
SQLda = New SqlDataAdapter(SQLcmd)
Results = New DataSet()
SQLda.Fill(Results)
End Using
‘Do something with the results from the Results variable here.
SQLcmd.Dispose()
SQLda.Dispose()
Results.Dispose()
Connection.Close()
Connection.Dispose()
End Sub

Now I freely admin that coding the .NET code this way is harder than using Dynamic SQL which is shown below.

Private Sub MySub()
Dim Connection As SqlConnection
Dim Results As DataSet
Dim SQLda As SqlDataAdapter
Dim SQLcmd As SqlCommand
SQLcmd = New SqlCommand
SQLcmd.CommandText = “exec sp_help_job @job_name=’” + MyVBNetVariableWithTheJobName + “‘”
SQLcmd.CommandType = CommandType.Text;
Connection = New SqlConnection(“Data Source=localhost;Initial Catalog=msdb;Integrated Security=SSPI;”)
Using Connection
Connection.Open()
SQLcmd.Connection = Connection
SQLda = New SqlDataAdapter(SQLcmd)
Results = New DataSet()
SQLda.Fill(Results)
End Using
‘Do something with the results from the Results variable here.
SQLcmd.Dispose()
SQLda.Dispose()
Results.Dispose()
Connection.Close()
Connection.Dispose()
End Sub

The problem that I have with application developers taking the easy, shorter way out is that their job isn’t to take the easy way out.  Their job is to build the application securing and robustly, not in such a way that the application is as easy as possible to write.  This problem can probably be traced back to the specifications which were written for the application which probably don’t mention security at all anywhere in the specification from the business unit.  Because security isn’t a primary concern for the business unit it is left as an afterthought, an afterthought which is typically ignored until after there has been a breech.

Another reason that I think that SQL Injection is a problem is that we trust that our users wouldn’t want to do anything to hurt our applications or their data as they have a vested interest in keeping the system working correctly.  And this is true to some extent.  However when you publish an application on the public Internet not only will you customers be using it, but others will be attempting to hit the forms within the application.  Because of this, we can’t trust any input that the application user passes in.  Even if the value that is passed in is from a hidden field, or has been validated by the front end. If the value hasn’t been validated by the back end, and properly scrubbed then it shouldn’t be trusted.  And the only way to fully validate and scrub the value is to use the parameterized query technique which I showed above, no other technique no matter how clever will be as successful.

I’ve been working in the IT space for about 15 years now, and I’ve worked on dozens of application development projects over the years at companies large and small, and I can’t recall a single application design specification which included security of the data as a component of the application development.  As the production DBA for companies I’ve forced the issue when I would find problems early enough in the development cycle, but often I wouldn’t find out about the application that was being built until it was time to deploy the application to production.  At this point it is to late to make the kinds of major changes which need to be made, and because security doesn’t add value to the application or to the business unit security isn’t given the developer or QA resources which are needed to make the changes needed to properly secure the data from potential attackers.

I urge everyone that reads this, developers and administrators alike, to look at how applications within your environment connection to the database engine (it doesn’t matter what database engine you use, they can all be broken into via SQL Injection, and yes MySQL is included in this) and if dynamic SQL is being used, and isn’t being properly parameterized talk to upper management about this problem.  Explain to them that while this won’t be something which adds features to the application and won’t necessarily add value to the business, this is something which absolutely needs to be resolved.

Suffering from a SQL Injection breach will have a negative impact on the company, and the IT department in several ways.  From the company side of things customers will loose confidence in the company, which means that they will stop purchasing your product or using your service.  This means that the company will make less money.

Internally the business unit will loose faith in the IT staff as they can’t properly secure their applications from attackers.  The business unit will then loose faith in the developers as the IT staff explains that the only way to protect 100% against this sort of attack is to fix the application which means lots of time (possibly hundreds or thousands of man hours) just fixing database access code and not adding functionally into the application.  The business unit will then assume that the developers aren’t good developers and may request that new developers be brought in, that the application development be outsourced, or that a third party application be purchased.  All of which mean that you and/or your coworkers could easily be out on the street looking for more work.

If you are working on a new development project and security isn’t included in the specification push to have it added.  Yes it will slow the delivery of the application down, but it will remove the risk of a data breach, or worse than that a total network breach (where the attacker is able to get into the company network and take control of internal resources like domain controllers, file servers, etc.) which would be a major disaster  to any company no matter how large or small.

I hope that you take this to heart and fix any applications in your environment which have SQL Injection issues so that we can all stop reading about these data breaches which are coming all to often.

Denny

Where Should I Be Encrypting My Data being presented by me

SQL Server 2012 Security for Developers being presented by Andreas Wolter

The Evolution of Security in SQL Server 2012 being presented by Don Kiely

SQL Injection: From Website to SQL Server being presented by Mladen Prajdić

There are a couple of other sessions that mention security in the abstract, but based on these abstracts I’m guessing that security won’t be mentioned very much during the actual sessions.

Denny

P.S. Don’t forget about my free SQL PASS 2012 First Timer’s webcast coming up on October 17th, 2012 at 1pm Pacific / 4pm Eastern.  You do need to sign up for the session, which is FREE so get signed up.  Even if you have attended the SQL PASS summit before, this is worth it as there are some big changes in how PASS will be laid out at the convention center this year.

The other day I was connecting to a clients SQL Server.  I had to log onto a different server to run SSMS, so far so good.  But then they gave me the connection information for the SQL Server which had a SQL Auth username and password.  I’ve already got a domain account, so for the love of god why did I have to have another stupid username and password instead of just connecting via the Windows Account I had JUST USED to log into Windows.

Vendor apps are just as bad.  They’ll insist that the Windows services run under a domain account, usually so that they can access network shares or something, but then they require a SQL Auth account to be created to log into the SQL Server database.  This means that someone needs to track another username and password, and given that SQL Auth accounts are easier to break into than Windows Auth accounts it’s less secure over all on top of that.

In 15+ years of managing SQL Servers for people I’ve found only a few software venders that were even willing to try running the software under a domain account so that we could use Windows auth to connect to the SQL Server.  And one of those was the one that I worked for, where I forced the developers to make that an option so that the DBA & sysadmin would have the option to install the Software under domain accounts and use those domain accounts to connect to the SQL Server.  The developer didn’t understand why I cared about this but eventually I got my way, mostly I think so that I’d shut up about it.

In my mind there are only a few times when it is truly acceptable to use a SQL Authentication Login at this point.

1. The clients are not running Windows.
2. The clients are not on the same domain, and the two domains aren’t trusted, and the user doesn’t have a Windows login in the same domain as the SQL Server.
3. The SQL Server is running version 4.2 or earlier.
4. The client application is a Windows service and it isn’t on the domain or the domains aren’t trusted.

Now you’ll notice for #2 I was pretty specific.  That’s because if the client is running Windows and the user has a domain login in the same domain as the SQL Server then the client application can be run as the users account in the other domain (this includes SQL Server Management Studio).

In summary, in case you didn’t get my point yet, STOP USING SQL AUTHENTICATION LOGINS.

Denny