That was the EIC16 that was

Each year, the German security consultancy firm KuppingerCole in Munich is organizing a multi-day conference on the theme of identity and access management.

The KC conference was well organized. Nice location for both sessions and the inevitable vendor marketplace. Lovely brochures, event app, fine catering and a lot of famous people. We'll get back to that later. KC is a large company, has many expert analysts and these are actively present. They moderate panels, are chairing different tracks and give presentations.

The conference lasts three days, long days ... the first keynote generally starts at half past eight and the day closing somewhere between 19 and 20. But that's not all, there are also pre- and post-conference workshops. I decided to join a preconf day this year, namely the workshop on the theme blockchain. I cannot give a full overview of the conference, but I will point to a few highlights.

The hype of this moment is Blockchain. The pre-conference workshop lasted a whole day and treated the backgrounds and ideas around Blockchain and also bitcoin. Also on the third day there was extensive attention given to blockchain in one of the four parallel tracks. Briefly: Blockchain is a promising technology (immutable storage of transactions, transparent, fast and cheap), but so far it’s little used (not really an anonymous platform, ‘bitcoin image’ is not very positive). But biggest problem is the issue of trust. Can you trust the blockchain, do you trust the longevity and continuity? But the advice is: go play with it, within a year or three there are business cases and apps to make use of blockchain technology.

Second hype: CIAM, customer Identity & Access Management. And yet, actually not quite a hype, we have already know,  implement and use it. More importantly is the underlying mechanism, namely federation.

More or less the same applies to IoT and Big Data. These developments also look at federated solutions to preserve both the business benefits and guarantees regarding privacy.

Federation was not only reflected in many presentations. There was a separate track in which the OpenID Foundation presented the many developments. Of course there was OpenID Connect (yes, we really should implement this as often and as broad as possible) and OIX (OpenId Exchange, it so looks like the implementation of what I wished for in my old blogs - http://id-use.blogspot.com/2008/06/trust-model-for-identity-providers.html ), but also a number of working groups on the themes of health (the OpenID Heart working group led by Eve Maler of Forgerock) and the Financial Services API WG.

But not everything topic at EIC16 was about IAM technology, unquestionable the most impressive presentation was by Mia Harbitz of the World Bank. She described identity management in a world where a birth certificate is already a challenge. Children with a birth certificate get a vaccination three times as often as children without a birth certificate. She had more shocking numbers of people without a formal identity, without access to life saving services because of it.

Providing an identity to refugees is also a hot topic (especially in Germany, with 800,000 refugees in the past year). This was discussed in a separate track with an interesting panel discussion. It soon turned out that we give refugees an identity because we want to avoid them actually abusing the services paid by us. Not because we want to offer our refugees just enough identity to survive. Sad really ...

An interesting development was an initiative by Ian Glazer (Salesforce). He and Kantara (for example known for User Managed Access – we should make this a default way of customer access control) took the initiative to investigate whether the Identity professionals can unite. The "Keepers of Identity" are increasingly more import, cooperation is essential. More info: https://kantarainitiative.org/digital_identity_professional/

And for those of us who are in despair… there are still use cases for on premise use of Active Directory. Kim Cameron (Microsoft) sees a shift to Azure AD, but an on premise AD will still remain for the coming years.

These were intense days. I finally met with many digital friends. And I advise you to look up the hashtag #eic16 on twitter. Lots of nice tweets, many photos and video’s and links to interesting articles.

And do yourself a pleasure and visit the blog of my good friend Alessandro Festa...

Adobe lesson learned: do not use complex passwords!

By now we all learned about yet another password leak, this time at Adobe. Not just some incident, no, it's a big one, with some 130 million passwords in the open. A big scandal too. And of course we are amazed at the large number of too obvious passwords chosen by the Adobe customers. Passwords like '123456' and 'secret' are amongst the most frequently chosen passwords. Are we really surprised? No of course not. We already knew that people are not very aware about the security risks involved.

Who are those customers? They are people like you and me, consuming services anywhere on the internet, Services like those offered by Adobe. And for most of those services the provider wants to know who you are by asking you to register an account. So, many of us did.

Accounts

Let me tell you about the way I create accounts. In order to protect my privacy I have to protect both my identity and my behavior. So I try to separate my digital life from my real life as much as possible. And I bet that I'm not alone in this. My preferred method is to create an account using an alias. And since providers want to reach my alias, I need to provide an email address. If possible I use a disposable, or a fake email address. Next I have to pick a password. '123456' will do just fine. Why?
This password is not there to authenticate, it's there because the provider wants me to provide a password to ensure my permission to use a service. But I didn't use a real digital identity, I just claimed some capacity to download whatever I want from the provider. I don't care about protecting it, because in real life it just doesn't exist, and in all fairness, it's worthless. In fact I may have created an Adobe account a long time ago, but I don’t even remember it. And if I don't care, it's just not relevant how secure it is or how complex the password is. The only thing that I need to take care of is to NOT use one of my regular identities and passwords.

That's my real protection. As long as a provider or a hacker for that matter, cannot link the non-existing identity with a real identity, there is no danger for my real privacy if the provider or hackers publish '123456'. I couldn't care less. So, lousy providers like Adobe are not really a risk for me. I was right in not trusting them.
A far better way for providers to connect to customers would be to let them use an external identity, that way you don't need to register an account with the provider and the provider doesn’t need to protect it, there is no password... If you are free to pick an external identity like facebook, Twitter or LinkedIn, then the risks of data leakage are far less. There's another privacy issue, because those identity providers know your interests because of the federation stuff. I will not elaborate on this issue, but if you have enough digital identities, every identity provider only knows part of your interests, part of your activities and thus part of your identity. Divide et Impera.

Threats

The Adobe leak led to a lot of noise in the security community. There were two main comments: Adobe is stupid by not enforcing better security, I agree. And: users are stupid for using simple passwords, well, I don't fully agree. And I will explain this:
Account and identity management is tricky. There are two risks:
1) Someone knows you and tries to steal your identity.
2) Someone knows your password and your login name and tries to find out your real identity and reuse that information

The first risk can be real, but it need not be that big, provided that you think about a few best practices. Protect your behavior. If someone doesn't know to relate your real identity to a digital identity, not a lot of harm can be done in the digital world, in Cyberspace.

As I mentioned, the second risk can be neglected as well, if you understand it and act upon it. I hope/believe that most of the Adobe top 20 passwords are used by people who knew this. In my opinion most of the accounts used are disposable accounts. And preferably accounts that cannot be linked to real identities.

Password complexity

Both reactions to the Adobe leak came down to one issue: password complexity. Fact was that Adobe didn't enforce password complexity, not in the user space, not by using good practices for cryptography. Second fact: lots of users didn't use complex passwords.

Password complexity is difficult. A password needs to be complex for a few reasons:
- You don't want it to be easily guessed by someone who knows your digital identity.
- You don't want it to be easily cracked by someone who has access to your encrypted password.
Yet at the same time you want it to be easily remembered, by yourself.

The first risk is in fact the risk that we need to manage to mitigate the threat of someone who knows you to steal your digital identity, that's the first identity risk. It's the risk of someone retrieving an identity => password combination based on known identity information.

The second risk is more difficult to manage. The enormous amounts of processing power makes this risk hard to mitigate, password cracking isn't that hard to do anymore. This risk works the other way around: someone tries to retrieve a password => account combination based on known password information. Encryption of the password in transit and in storage does help safeguarding the password information, but it will probably only help temporarily. So we are trying to use one measure, password complexity, to tackle different risks. This may seem efficient, but in fact it's not what we need to do.

In order to prevent identity => password retrieval, we need password complexity. No one should be able to retrieve a password based on identity knowledge alone.
One example is Phishing: an attacker tries to retrieve secret information from a known identity. That means that the real, or physical identity => digital identity => password trail needs to be protected. And since the password is the valuable item, the password needs to be secured. That means using complex passwords (and to fight phishing: educate users to not hand over secret information!).

To prevent retrieval of a valuable identity based on a found password, another mechanism is required. If someone retrieved a password, he may be able to retrieve the digital identity, but he should not be able to retrieve the real identity behind the digital identity. Why?
This might lead to misuse of the identity => password risk!

If the password => identity trail can be found, an attacker might gain knowledge to intercept other identity => password combinations. The identity is the valuable resource, so you need to protect your identity. And the best way is to use disposable identities or external identities in those cases that you have to trust providers.

This leads to an interesting conclusion

Adobe user accounts with complex passwords, may well be more at risk than accounts with easy to guess passwords: customers using a complex password may well have used a valuable identity, expecting the complex password to protect it. How about that?

In my next post I will introduce a real simple complex password method.

What US-Cert should have said about the Adobe hack

This is what US-Cert said in a rather pointless advise: "US-CERT advises that Adobe customers be aware of possible fraudulent account activity."
What US-Cert should have said instead: Advise for Adobe customers: If you have an account at Adobe: Change your password.

But that's not all: If your Adove account has a username/password combination and/or emailaddress that you use for other websites services as well, change your password on all the other sites too.

And perhaps, if US-Cert could spare some time and effort (thank you #shutdown) they could have added this:
Advise for all service providers: Get rid of password management by moving to federation protocols like OAuth or OpenID Connect. If you don't store passwords, you can't lose them.
And an advise for Adobe and all other providers: Please don't ignore secure programming guidelines.

Another business case for federation

Traditionally Identity Management is almost core business for many companies. Of course we all sell products and services to consumers, but those are commodities when it comes to identifying the trouble we have managing our business. You have to comply to all kinds of laws and regulations and operating an identity business is no small task. There are lots of small processes and you have to operate in a trustworthy and secure way. And the reason? We only trust ourselves.

There are several reasons to reevaluate the need for identity management. First there is the trouble implementing the technique. Not only does it have to be secure enough, privacy laws are applicable so supervisors will be on the loose.

Second: your customers hate identity management. You're not the only one that has to manage identities, so do your customers. Identity 2.0 didn't happen just because it could.

Federation is an intriguing technique for identifying individuals. It does require another point of view, but there are many benefits. For instance you don have to manage identities, but you can have a specialist, the Identity Provider, take care of that. You only have to trust the IdP and open up your business for the new protocols. And your customers don't need yet another account and password. The can reuse an existing identity.

Last week a new business case appeared. In France new regulations require website owners to make identity information accessible to the authorities. Accounts, password, personal data. Not really what security is about. These laws apply to French companies, but perhaps also to companies dealing with French customers, although I cannot imaging how French authorities can plan to execute these regulations.

But this new development does help us to define a new business case for federation. Federation means that the relying party, the party trusting a 3^rd party IdP, doesn't have to store personal data, except for transaction data. And what you don't have, you can't lose. Or hand over to others.