Voice of the DBA

Tag: security

  • Creating a User without a Login – Contained Databases

    In SQL Server 2012, we have a new feature: partially contained databases. In a previous post, I showed how to enable this, and this post will look at one of the advantages of contained databases: users without logins.

    Contained Users

    One of the problems in non-contained databases is the fact that when a database is moved or restored, the login mapping to the user in the database doesn’t always transfer cleanly. Microsoft has sp_help_revlogin and sp_change_users_login to help fix this, but in a DR situation, or in a crisis, this may not work. It’s also a hassle.

    Contained users help fix this. They are users that exist within the database, and do not require a login mapping. The server level authentication will transfer to a database level authentication, if the database has the partial containment option set.

    To create a contained user, you can use the GUI, or T-SQL, both of which are easy and I’ll show them below:

    SSMS Contained User

    If you right click the Users folder (under Security) in a database, you can select the New User option.

    cdb3

    When this appears, you can then use the drop down to select a User with a Password option for a SQL Server user that is contained inside a database.

    cdb4

    The traditional user is a user with a login. Here’s the dialog from SSMS 2008, with no option for a user without a password.

    cdb8

    Back to 2012, I can enter a user name and password, and then I have a user in my database.

    cdb5

    The process for a Windows user (again, without a login) is similar. I can select a “Windows User” and then select the ellipsis by the User name and search for an AD user.

    cdb6

    This looks the same when I accept a user

    cdb7

    I can set a default schema here, and a language, but I don’t need the login.

    T-SQL

    The process with T-SQL is the same. The code for the CREATE USER command is simple:

    create user Billy with password = 'Billy2Goat$Gruff'
;

    If I want a Windows user, I can do this:

    CREATE USER [DKRSQL2012\Andy]
GO

    Note that this is domain\user syntax. Some AD tools allow the user@domain syntax, but this isn’t allowed in SQL Server 2012 for the CREATE USER command.

    You can replace the user name with a group at the database level, and the syntax is the same.

    Summary

    That’s it. It’s simple, and in another post, I’ll look at authentication.

  • Key Storage

    keys
    Hopefully your digital key storage is more organized and secure than this.

    One of the issues with encryption, perhaps the biggest issue, is the management of the keys that protect the encrypted data. I have been an advocate of keeping the backup of the keys far away from the backup of the encrypted data.I usually want them on separate media, or a separate tape, just so that a loss of my backup of the data (or the data itself), doesn’t include the key.

    However this presents a problem in a DR situation, especially over time. If I make a backup, and lose my server in a year, can I easily find the copies of the asymmetric keys or certificates? Can I easily match up the proper key with the encryption if I rotate keys periodically? There hasn’t been a great solution I’ve seen to solving this issue.

    Recently I saw a talk on security, and the speaker mentioned they kept copies of their certificates on the backup tape with the backup of the data. This person felt that since a password was needed for the certificate, that this was secure enough. Perhaps, but you still have the problem of securing that password over time as well. This week, I wanted to ask those of you that use encryption, how do you handle the issue.

    Would you store a secure asymmetric key protected with a password on your backup drive or tape?

    If so, then how do you handle the security of the password? If not, then what other solution do you have? I know key management is a struggle in many organizations, but if you have something that works for you, let us know how it works.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Hashing Collisions

    One of the problems with hashing is that you can have collisions from values that are not very similar. This means that if you are using hashing as a way to identify similar values, you need to make further checks with the original data after the hash matches are gathered.

    This post will show a few examples of the collisions that can occur if you use the CHECKSUM() or BINARY_CHECKSUM() functions.

    If we examine this code:

    -- Checksum
declare 
  @i varchar(200)
, @j varchar(200);

select @i = 'LE';
select @j = 'AAAAAAAAAAAAAAAALE';

select 
  Plaintext = @i
, checksum = CHECKSUM(@i)
UNION ALL 
SELECT
  Plaintext = @j
, checksum = CHECKSUM(@j);
GO

    This returns a result like this:

    hashing2

    Note that these two values are the same as far as the checksum hash goes.

    If we switch to BINARY_CHECKSUM(), we can get similar results.

    -- binary_checksum is no better
declare 
  @i varchar(200)
, @j varchar(200)
, @k varchar(200);


select @i = 'LE'
select @j = 'Ou'
select @k = 'MU'

select 
  Plaintext = @i
, BINARY_CHECKSUM(@i)
UNION ALL 
SELECT
  Plaintext = @j
, BINARY_CHECKSUM(@j)
UNION ALL 
SELECT
  Plaintext = @k
, BINARY_CHECKSUM(@k)
GO

    hashing3

    While these two functions can be useful, you do have to be careful with the results. A matching hash from these functions does not mean that the source data is the same.

  • Certificates Everywhere

    To me, certificates are the best way to secure communications and be aware of what’s allowed and what isn’t.

    One of the things that I think has been most disappointing to me in technology over the last few decades is the lack of progress is managing security keys and certificates. There hasn’t been a really good method designed that works well at scale for disparate organizations.

    Recently at the DevConnections conference, I saw a talk where Mark Minasi talked about the future of tablets and smartphones, where he mentioned the idea that we will use many devices in the future that don’t necessarily need to connect to the domain inside a company. They’ll still authenticate, but with certificates.

    That would be the ideal situation for me, a world where we individually have multiple certificates that identify us, and allow us to have secure communications, layers of security for different purposes, and a way to easily revoke, change, and add new certificates as needed. I’d be able to use easily manage certificates across devices to provide some level of authentication.

    As we move to the deep intermixing of user and company devices, it does start to make sense that we consider using a more ad hoc authentication scheme that can be deployed in a more distributed fashion, rather than the monolithic, authenticate to the domain completely or not at all, scheme we have now.

    I don’t have a solution worked out, but I know there are some very smart security people out there and I’d hope that they are working on a variety of solutions that will increase the security we have, while allowing us lots of flexibility.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.