Securing WCF Services: Preventing Unauthorized Access

Suppose you are writing a web service to perform a sensitive calculation. Your web service should only be accessible by authorized users and/or applications. Here’s my advice for configuring your service:

Use .NET to Your Advantage

.NET has built in features for ensuring that the code calling yours is authorized to do so. For example, take a look at this snippet of code:

[PrincipalPermission(SecurityAction.Demand, Role = "MyLocalSecurityGroup"]
public SearchResults Find(string contractNumber)
{
    ...
}

Notice the [PrinciplePermission] attribute. This attribute tells .NET that only principals who are members of the "MyLocalSecurityGroup" role are allowed to run this method (where a principal is a user/service account, and a role is a locally defined security group on the server). In other words, in order to run this method, the caller must be running under an account that is a member of the local security group specified.

Local Security Groups

By telling your code to check a security group on the local server, you get around the problem of having to care about the different test regions in your code. The local group on your DEV server will contain only those accounts which are authorized to access the service in DEV. Likewise, the TST and PRD local security groups will only contain accounts authorized to access TST and PRD respectively.

Domain Security Groups (NT Groups)

Of course, you don’t want to manage access at the local server level. Rather, you want to let User Account Services (UAS) manage access centrally. The way to do this is to create domain security groups for each test level. For the middleware, I created these groups.

  • MyDomainSecurityGroup.DEV
  • MyDomainSecurityGroup.TST
  • MyDomainSecurityGroup.PRD

Then update the local security groups on your servers to ONLY contain one of these domain security groups. If the server is a DEV server, put the DEV make the DEV domain group the only member of the local security group. All other user/service accounts should be removed from the local security group and added to the appropriate domain security group.

Conclusion

If you follow this pattern to secure your web services, you’ll be able to prevent unauthorized access to your service by adding a single line of code to every method that needs to check authorization. Furthermore, in a more complex scenario – say one where users may have read, write or admin access to your service – you can create as many local and domain security groups as you need to ensure that users and applications have the lowest level of access required to do their work.

One final thought: If you web service is hosted in across a pool of servers, remember to create the local security groups on all of the servers. You could probably do this with your installer. Or, you could make it a manual step in your implementation plan that only gets executed once.

iPhone 3GS Security Flaw

Apparently, the iPhone 3GS has a security flaw that would allow someone to access the data on a PIN protected device by connecting it to a computer running Ubuntu Lucid Lynx. (There was no mention of the iPhone 3G or the iPad having the problem. And, the original iPhone device didn’t offer encryption at all.)

Obviously, this kind of attack would only work if the hacker had possession of the actual iPhone. But, phones get misplaced all the time. Because of this, if you own an iPhone and you care about the security of the information on the device, you need the ability to reset the device remotely.

For corporations running Microsoft Exchange 2007:

You can initiate a remote wipe using the Exchange Management Console, Outlook Web Access, or the Exchange ActiveSync Mobile Administration Web Tool.

iPhone OS Enterprise Deployment Guide (page 9)

Individual iPhone owners can use MobileMe to “Remote Wipe” their device should it be irretrievably lost. Though, the service costs $99/year, it does include many other services.

From Password Strength to Privacy

At it’s core, password strength is about privacy. Well, that and theft prevention.

One of the blogs I follow had a thought provoking piece on privacy in the age of the Internet, today. I wanted to blog about it. But, I couldn’t put it any better than Tweetage Wasteland already did.

And, yes. I read the Confessions of an Internet Superhero.

How can I handle password overload?

Now that I’ve scared your pants off, you’re probably wondering how in the world you’re going to manage all of those passwords for all of your various surfing needs. In this post, I’m going discuss several options for managing strong passwords. I’ll also discuss the approach I’m planning to take, now that I know better.

Reuse

Most of us tend to reuse the same password all over the place. But, if you’ve read my previous posts – especially the one that talked about how a cracker can use your personal email address password to gain access to other web accounts – you now realize that this is not a very secure strategy.

But, security may not always be your highest priority. Convenience might rank higher in some cases. If that describes you, then just allow me to point out a few things you may not have considered:

Corporate domain account passwords should be unique. 

To reuse this password elsewhere would put corporate data at risk, potentially including any customer or employee PII that you can access. Disclosure of this information could have seriously negative ramifications for the company – and your job.

Personal email account passwords should be unique. 

Sharing these passwords puts your entire Internet-hosted life at risk.

Financial account passwords should be unique. 

 No sense taking the risk that someone smart enough to break into Bank of America can also access your 401(k), credit union accounts, and home equity line.

Any account where you post content should be unique. 

Do you review products on Amazon.com? Do you use Facebook or Twitter? Do you comment on videos at Hulu? If so, those posts are all a part of your online persona. If a prospective employer or significant other were to Google you and read those posts, would they want to hire or date you? Would you want to give some random cracker the ability to post in your name? I didn’t think so.

What’s left? 

Not much. And, that’s my point. You need to use unique passwords just about everywhere.

Pass-phrases

A significantly stronger approach is to make up a unique pass-phrase for each site. But, how can you remember them all? It’s actually easier than you might think. Instead of trying to remember all of the passwords for all your sites, come up with a formula for creating unique passwords, and remember the formula. Here are a few to get you thinking:

I love Facebook

Adding the web site name to a short password significantly strengthens the password, and makes it unique to the site. This pass-phrase, which contains 15 characters, including upper case letters, lower case letters and spaces, is extremely strong against brute force attacks. Though, it seems like it would be a whole lot less strong against a dictionary attack or a random guess.

Facts About Crime

This pass-phrase was created using the first three letters of the website name: FACebook. It contains 17 characters, including upper and lower case letters and spaces, which makes it even stronger against brute force attacks than the previous password. This pass-phrase also seems stronger against a dictionary attack.

4 the <3 of Facebook

Using “text” shortcuts, like “4” instead of “for” and “<3” instead of “heart” or “love”, significantly increases the strength of a pass-phrase against brute force attacks because it introduces numbers and symbols. Though, as with the first pass-phrase, this one seems a bit easy to guess.

F.a.3.%.B.o.15._

Can you see the pattern here? This is Facebook spelled out using this pattern: Upper, Lower, Number, Symbol, separated with periods. Replace the “c” with a 3, since it’s the third letter. Replace the “k” with an underscore – the eleventh symbol on the keyboard. Granted this would be incredibly slow to type. But, it’s probably also the most secure against dictionary attacks. (The third password is actually stronger against brute force attacks due to it’s length.)

There is one caveat here, though. Finding a single formula that works across all the different web sites out there is probably not possible. So, you may need multiple different formulas. And, then you’re back to where you started.

Password Vaults (or Password Managers)

Don’t think you can remember all those passwords? Why bother when a password vault can remember your passwords for you? Password vaults are nothing more than encrypted databases for your passwords. In order to access the passwords in the vault, you need to enter a master password – to unlock the vault. Some even offer mobile or web-based solutions, so you can always access your passwords, where ever you are.

The key things to consider with password vaults are:

How strong is the encryption used to protect the vault?

You’ll want to make sure that the passwords are encrypted using an industry standard encryption algorithm.

How strong is your master password for the vault?

Remember to create a strong pass-phrase for opening your vault. It’s got the keys to your online kingdom in it, after all.

Can I access the vault when I’m away from my computer?

Some vault programs let you take your vault with you when you hit the road – either on your cell phone or via the web.

Personally, I use a password vault called 1Password, both at home and at work. I store my vault in my Dropbox, so it is automatically synced to all of my computers. Plus, because I can access my Dropbox from the web, and because 1Password builds a web interface into the vault itself, I can access my passwords from just about any web connected device. There’s even an iPhone app (which I don’t use yet).

I’m less familiar with other vault software. But, a quick Google search for “password manager” turned up several, including LastPass, which I’ve heard good things about.

One final note on password managers: Many of them come with strong password generators. Before using them, make sure that their algorithms are “cryptographically random”. Otherwise, they’re susceptible to dictionary attacks targeted at that specific generator.

In conclusion

Once I discovered how weak my personal passwords were, I went on a quest to inform myself. These posts are my way of remember everything I learned. I hope you find them useful, as well.

How strong should my passwords be?

Allow me to turn that question around: “How valuable is the information that you are trying to protect with a specific password?” The more valuable the data, the stronger the password you should use. Let’s take a look at a few examples:

Your Corporate Domain Account Password

At my company, policy dictates that my password be at least 7 characters. But, I am not required to use complex passwords (with both upper and lower case, or numbers, or symbols). So, in theory, I could use a short, simple password. But, as we learned in my previous post, short, simple passwords are trivial to crack, taking less than an hour of a computer’s time.

Of course, our corporate policy also requires me to change your password every 60 days. So, I might feel safe enough with an 8 letter password containing lower case letters, numbers and symbols, which would take an average of 1 year to crack.

That said, the advice from the author of the open-source Jack the Ripper password cracking software is to use pass-phrases rather than pass-words, whenever possible:

“Yes, for operating systems, applications, etc. which do not have a low limit on the length of passwords they accept, I recommend the use of passphrases instead of passwords. For even better security and/or to have fewer characters to type, both approaches can be combined: separate some words with punctuation rather than spaces, embed numbers and other characters, etc. Ideally, the passphrase should be something you can remember or derive again, but it must not be based on information that is known to others (e.g., your name, a quotation, a piece of the output of a Unix shell command, etc. - those are all to be avoided).”

Your Personal Email Account Password

As I mentioned in an earlier post, reusing your personal email account password across the web is a gigantic hole in your personal information security – not because your email with your Mom about her casserole recipe is particularly valuable, but because your personal email account can be leveraged by a cracker to change your passwords on other systems. In other words, the “information” you are trying to secure with your email account password is every password to every account you have. For that reason alone, I recommend using the longest, most complex password (or passphrase) possible under your email provider’s authentication mechanism.

And, whatever you do, NEVER reuse your email account password on other systems!

I was guilty of this until recently. Never again!

NOTE: Google Gmail requires 8 letter passwords and provides some good advice regarding how to create strong passwords. Microsoft Live only requires 6 letters. Who do you think values your security more?

Your Other Web Passwords

So, what about all those other passwords you have to create for use across the Internet? Well, as with Gmail and Live.com, policies differ wildly from site to site. For example, here are the password policies for four sites I use frequently: AmericanExpress.com, CapitalOne.com, Facebook.com, and Twitter.com. (Can you guess which is which?)

Strongest Password Policy

  • Do not use the same password that you use for other online accounts.
  • Your new password must be at least 6 characters in length.
  • Use a combination of letters, numbers, and punctuation.
  • Passwords are case-sensitive. Remember to check your CAPS lock key.

Strong Password Policy

  • Be tricky!
  • Your password should be at least 6 characters.
  • Your password should not be a dictionary word or common name.
  • Change your password on occasion.

Weak Password Policy

  • 8-15 characters
  • Not case sensitive
  • Aa-Zz, 0-9, ( - ), and ( _ ) only
  • At least 1 letter and 1 number
  • No spaces

Extremely Weak Password Policy

  • Contain 6 to 8 characters
  • Contain at least one letter and one number
  • Not case sensitive
  • Contain no spaces or special characters (e.g., &, >, *, $, @)
  • Be different from your User ID and your last Password

I ordered the sites in the order I consider to be the the strongest password policy to the weakest.

Note that the first two, while only requiring six characters, both allow you unlimited flexibility in the characters you choose. So, while they allow short passwords (insecurely short, in my opinion), they don’t prevent you from using longer, more complex passwords. (I prefer the first one because it recommends using letters, numbers and symbols – the green line on my graph.)

The third policy is fairly week due to the lack of case sensitivity or the ability to use most symbols.

That final policy is extremely weak. It has me seriously considering my options there. Either I’ll need to start changing that password regularly. Or, I’ll need to take my web browser elsewhere. Fortunately, the site takes other precautions with my data – such as only displaying the last four digits of sensitive numbers, and asking a series of personal questions before allowing me to change my password.

So, which of these organizations values my personal information most?

One more post to come…

How strong are my current passwords?

WARNING: This is the geeky post.

The strength of a password is determined by three factors:

  1. The length of the password,
  2. The complexity of the password, and
  3. The processing power available to the cracker.

The formula looks like this:

  • Strength = Complexity ^ Length / Encryption Operations per Second

Where:

  • Strength = the amount of time it would take (in seconds) to process all permutations of a password,
  • Complexity = the number of different characters in the character set that the password was drawn from (e.g. numbers only = 10, lower case letters = 26, lower case + numbers = 36, etc.),
  • Length = the number of characters in the password, and
  • Encryption Operations per Second = the number of permutations a cracker can try per second.

Given that a modern desktop computer can perform over 1,000,000 encryption operations per second*, we can calculate how long it would take to run through all of the permutations of passwords of varying length and complexity as follows:

image

This chart shows the exponential trend of each of the average complexity curves mapped on a logarithmic scale.

Er, what?

English translation:

  • Exponential = Imagine a chart that looks like the right hand side of the letter U
  • Trend = With so few data points, the chart looks rather jerky. So, I told Excel to display a trend line, instead. It smoothes the curve.
  • Average Complexity Curve = The average amount of time it would take crack a password of a specific length and complexity.
  • Logarithmic Scale = Vertical axis goes up by powers of 100 rather than linearly (1, 2, 3, etc.)

So, how strong are your current passwords? Are they strong enough? Stay tuned…

* I got this number (> 1,000,000 encryption operations per second, or crypts/second, or c/s for short) from an interview with the creator of a password cracking tool called John the Ripper. Here’s the interview. It’s worth a read, if you’re at all interested in this stuff. I found the number in a question on the second page, second paragraph.

How are passwords cracked?

The simple answer to that question is that passwords are cracked by guessing.

Now, I know what you’re thinking – that the corporate login system will lock someone out after five failed attempts. Sure. But, by the time a cracker comes to the front door of your system, they’ve already guessed your password.

How?

Well, it likely started with a successful SQL injection attack that gave the cracker access to a database containing user account information. Sure, the passwords were encrypted. But, now that they have the cipher text, they can start trying to crack it.

Dictionary Attacks

The first thing they’ll do is to try all of the passwords on lists of commonly used passwords and default passwords. This is called a dictionary attack. It will likely crack several passwords in the database, since these are, after all, common passwords.

Foiling a dictionary attack is quite easy. Just don’t use common passwords. Take a few minutes to follow the links above to see just how easy this is for crackers.

Brute Force Attacks

To crack even more passwords, the cracker can instruct their computer to try every possible password until one matches. This is called a brute force attack. This type of attack is guaranteed to work – eventually.

The key to thwarting brute a force attack is to use strong passwords. Password strength is affected by two things:

  • The length and complexity of the actual password, and
  • The processing power available to the cracker.

Obviously, you cannot control the second. But, you can control the first. I’ll cover password strength in more detail in the next post. But, suffice to say that the longer and more complex your password, the stronger it is.

Email Attacks

Finally, there’s one more way a cracker can “guess” a password: They can change it.

How?

Assuming the user account information database that they downloaded also includes email addresses (which many sites use as the logon id), the cracker now has two pieces of information about you: Your email address and a password that you use on at least one website.

Using the knowledge that many people reuse passwords on many different sites, including email, the cracker will naturally go to your email site and try to login using your email address and the cracked password. If it works, then not only can they read your email, they can also potentially change your password on other sites and intercept the new, system-generated passwords.

Sure, some websites (notably banks) now require you run a gauntlet of personal questions before allowing you to change your password. But, others do not – including Facebook which is rapidly becoming defacto authentication standard across the web.

There’s only one way to prevent this kind of attack – don’t reuse passwords across sites – especially email!

Now that I’ve scared the pants off you, stay tuned for a deeper (geekier) discussion of password strength, and some (less geeky) recommendations regarding passwords.

How strong are your passwords?

I stumbled on a good (very geeky) article about password strength last week. (I’ve since lost the link, or I’d add it here.) It turns out that my passwords aren’t as strong as I thought. So, I’ll be addressing that over the coming weeks by creating unique passwords for every web site, device and system that I log onto with long, complex passwords. Why go to all that trouble? I plan to explain this in a series of posts beginning today, including:

  • How are passwords cracked?
  • How strong are my current passwords?
  • How strong should my passwords be?
  • How can I handle password overload?