Sunday, July 17, 2016

Single Sign On, potentially your biggest Security headache

It is not uncommon for companies pursuing the principle of Single Sign On (SSO) for their information systems, often disguised with the claim to ‘improve’ security. Although I agree that the usability for users are increased in almost in every case, I do not agree that the same applies towards security. On the contrary, if not implemented in a good manner it decreases your security and increases your headache!

To explain my statement, I will take you through some layered thinking about the subject and address some things to do to address SSO in a secure manner.

Password ethics

The ethics towards password use are most often not that of the standards that we as Security Officers would like to see it. This concerns many aspects, such as password uniqueness, password length, and password secrecy. Passwords (or passphrases for that matter) are often not unique, are to short and are kept secret in a rather insecure manner.

Imagine an IT-environment with full-blown SSO with primary accounts that have the same password as somebody’s home computer, combined with passwords that are way to short (anything less than 12 positions is short) and are kept in an spreadsheet on a computer without disk-encryption. And now imagine that such password gets compromised and all extremely sensitive data can be accessed on your corporate network through that one account, just because you implemented SSO.

When thinking about SSO, you need to re-think your password ethics.

Password uniqueness

It is hard to address uniqueness and it is for the most part pure awareness of the people. But there are some things you can address. First of all, make sure passwords cannot be re-used. Whenever a user changed his or her password, it should be at least 20% new. When considering a password of 12 characters, you already have to change at least 3 positions.

Also audit the passwords of your users on regular intervals. On the Internet you can find sources with the most often used passwords. Take a big amount (for instance, the 20, 30 or 100) of most used passwords and make sure users cannot use those passwords and if they do, forcible reset their accounts. Apply these tactics also when password databases of other companies get compromised and compare (if possible) those passwords against your database to prevent misuse of accounts due to hacks at other companies.

Password length

Password length is rather easy to fix. First of all, bump it up from the pretty much default of 8 positions to 12 positions. There is some debate about whether or not it should be a difficult password with special characters and all. I tend to say that when your password is unique within the scope of all accounts of yourself and that it is at least 12 positions long, you are good (enough).

Password secrecy

And now password secrecy. Who doesn’t know that one guy who saves all his passwords in an spreadsheet, so it is convenient for accessing them? Do you realize that you’ll probable have some of those as your co-workers? And that they are likely have access rights to important data-sources?

So give your users the tools to safely store every password. Whether or not this is an on-premise tool or a Cloud-based tool, make sure it has enterprise features like central management for your admins and a full audit trail for your auditors. It will make everybody’s life easier and users can keep their passwords safe. The fact that you are on the verge of implementing SSO, does not mean you can skip the password manager.

Data classification ethics

And then there is the aspect of data classification. The ethics of topics such as these can be made extremely complex or extremely simple (to simple). In many organizations data classification is not really done and for the better part of it, I can totally understand that. But for an improved SSO you will need to have some form of classification.

If you have data classification, you can skip this part. Otherwise this might come in handy. When there is a lack of data classification you can approach this subject with three types of classifications. The first is public.

Public data

Public data may be read by at least anyone in the organization. It does not mean it needs to be readable to everyone, but it might be just as well.

Corporate data

The second one is corporate data. Corporate data is data that may not be read by everyone in the organization. This type of data is important for the business to function, but it lacks protection of laws and it is also not intellectual property.

Secret data

The third one is secret data. All personal identifiable information (PII), intellectual property (IP), and all other information that is subject to law or regulators must be considered as secret data. Most often of the time you can find the crown-jewel data in this category. Think about information that is vital to stock-trading and may not leak due to regulators and think about personal information of your customers that is subject to the EU Privacy Directive.

And now grab some engineers in a team and divide the information systems into these categories. I bet that in 90% of the time these assessments can be done out the top of the head of the engineers.

Stepping up your SSO

When you have put the controls in place to improve password uniqueness, length and secrecy you can move forward to implementing SSO. When implementing SSO you really need to factor in the two-factor authentication (2FA). And this principle is easy.

Whenever a user accesses information in a higher level category, you will need to ask for a new 2FA-code.

There is no need for re-asking the password, just the code from the authenticator app, physical token, YubiKey, SMS or whatever you use for 2FA. This mechanism prevents that when a password gets compromised, that all data can be accessed without further obstruction. 2FA also helps users to detect (in case of SMS) login attempts on their accounts.

There is on caveat though…

There is one caveat in SSO that is often overlooked. The moment you start using a system (such as Active Directory) as the primary source for identity management, it is then by definition the most critical system in your network. You really need to be rigorously protective towards that system.

Therefore, never allow unencrypted traffic towards and from such central system. Never use insecure APIs to connect and make obsolete technologies impossible to use. All security controls are completely irrelevant when some old system that is not SSO compatible transmits the username and password unencrypted over the network just to get it to work.


To implement a secure single sign on (SSO) you will need to improve the password uniqueness, length and secrecy. You will also need to have at least three categories of data classification. With these controls you can implement SSO with the use of two-factor authentication (2FA). Whenever a system in a higher level of category is accessed, the principle of 2FA needs to be applied. And harden the central system with all its identities and make sure that all data exchanges are well secured.

If you have done the above, you are a big step further to lessen your headache.