All your passwords are belong to criminals

Again a few issues with password being copied by criminals. This week alone saw mentions of ebay, avast (forums) and spotify. In all cases the managed passwords were said to be hashed, so criminals have to brute force the passwords. But that is just a matter of time. And since Moore's law extends to password crackers, chances are that the copied passwords will be guessed shortly.

What does this mean? The Avast case looks not very critical. As I wrote earlier, many people create account with little security, just for the purpose of connecting to services that are not very critical. But the ebay case is a severe incident.
ebay is not just any website, it's a site that allows you to make transactions and it keeps lots of files and records about you. It's like a digital identity and they know your behavior. And the criminals not only stole the password and userid, but other sensitive data as well.

Of course you should change your ebay password. But: since your ebay account is important for you, you may well use the same account information for other sites too.

If by any chance you use the same ebay password with any account that is connected to the same email address that you registered at ebay, you should change the password for those accounts too!

Still running XP? Bad for you...

Last month I wrote that, despite all warnings about the imminent death of Windows XP, until May 13th Windows XP could still be used in a relatively secure way. In fact, the recent off-schedule security patch by Microsoft proved my point. But I also said that from that day on XP is doomed. If you still use an XP system, chances are that the system will be a victim of an attack.

On May 13th, Microsoft publishes some security patches that will not be published publicly for Windows XP systems. Only a few organization, who pay dearly for extended extended support, will enjoy the benefit of keeping their XP systems alive. But for the rest of us, XP will be at risk.

What happens every month: if Microsoft publishes a security patch, criminal minds reverse engineer a vulnerability based on the changes in the patch. They try to figure out ways to penetrate systems that are not (yet) patched. And in many cases within a few days the first exploits are around. Since all Windows generations from NT onwards are very alike, chances are that a vulnerability in a recent Windows version exists in Windows XP too. And if a system is not patched, such an exploit will be a zero-day exploit for ever.

Can you protect XP systems that are not enjoying extended extended support? No, not unless you never connect it to the outside world directly or indirectly. Even anti-malware software may not guard an XP system against exploits.

What should you do? Migrate, migrate, migrate, to whatever more recent operating system that you can think of. If you're in a company: get your management fired asap. They are the next vulnerability that will not be patched.

Attribute management

In my previous post I said that I need a facility to manage attributes issued by third parties. I have plenty digital identities, but most of them can only be used for a specific purpose. A limited number can be used in a multi-purpose fashion.
There's DigiD, the Dutch digital identity that was provided to me by the Dutch government and that can be used in my relation with a number of national and local government transactions and for a few transactions beyond that, like for my health insurance business. But these services can use only one specific attribute of my DigiD identity, the 'BSN', a unique identifier, like the American SSN.
Another multi-purpose identity is my Twitter account. But it also only has some predefined attributes, but if a service provider needs extra attributes, he needs to capture those through other channels. But there are no attribute providers beside the identity providers we know and love...

But, a few weeks ago I received an invitation from ISACA to download digital Badges that can be used to indicate that I am a Certified  Information Systems Auditor (CISA) and a Certified Information Security Manager (CISM). These badges can then be imported in an 'Acclaim' account, that I can use to present my badges to others. And ISACA mentioned that presenting these badges in my LinkedIn profile is a preferred way to show my certifications.

How about that? ISACA issues a badge that proves my qualification. It is an attribute of my profile, it belongs to me. Not to one of my identities, but it is an attribute of me as a professional. And ISACA is qualified to issue these attributes, ISACA created these attributes, ISACA is the owner of the CISA and CISM titles.

ISACA issues badges in the form of an Open Badge, an open standard, created by Mozilla. And Mozilla created it's own backpack facility in the Mozilla Persona digital identity. The backpack can be seen as a wallet that contains the badges. Acclaim is another form of a digital badge wallet. Here is the acclaim page with my ISACA badges.

I really liked this idea, so I created my own badge issuing process. As you may recall I started the #ditchcyber campaign and this campaign is supported by the @CyberXpert account. I decided to offer CyberXpert badges to followers of this Twitter account. Any follower who uses the RCX or CCX title can get a digital badge and import that badge in a Persona Backpack. Here's my backpack, showing a CyberXpert badge.

Next thing we need to find out is if an Open Badge attribute can be collected by a digital identity and combined to a SAML message.

I need a PAL or a PASS

There are two IAM concepts that I really like:

• Identity 2.0, where I can login to a service provider using an identity that was provided to me by an identity provider, who proofs that it is really me.
• Attribute Based Access Control (link to the NIST ABAC standard): you get authorizations not based on your identity, but on your capabilities that some authority feels you have.

The first development makes it possible to separate responsibilities for objects on the internet. A service provider only needs to take care of services and data, an Identity Provider (IdP) only has to take care of digital identities and authenticating it's users. A service provider only needs to trust the digital identities provided by an Identity Provider, and that creates an enormous scalability of web services.

Attribute Based Access Control enables the authorizing of persons as requested by a process owner or data owner. This owner has to define the quality requirements for executing tasks within a process of towards a data element. The process owner or data owner doesn't need to have any knowledge about the identities or roles or groups that are defined within an organization. But this is a new concept and a very tough responsibility: these owners never before had to think about these requirements. Nevertheless, this is an exciting concept: someone doesn't get permissions because of his function or role within an organization, but because of his capabilities. And these capabilities are called 'attributes' of the identity.

The interesting thought is that an identity provider also provides some attributes. Such as address, phone number, gender, date of birth, expiration date and a lot of other variables. The IdP concept of ABAC is implemented in the SAML message format, where the term Claim component is used as the attribute component.

One of these attributes could well be the Role of an identity. An internal identity provider in an organization may well know the function type or role of an employee, who gets a business identity. In such a case an attribute can be used to allow Role Based Access Control capabilities to the access control mechanism.

But... what if a process owner requires an attribute outside of the scope of the identity provider? Where does the extra attribute come from? In the ABAC concepts attributes are bound to identities, that means that in order for an employee to prove that he has the extra required attribute, he in fact needs to provide another identity that does contain the required attribute. But... in all reality, that's just not feasible. What might be possible is that the identity provider forwards the attributes provided to an identity on behalf of another identity provider. For instance: an internal IdP could add attributes, like results from a course that the user attended. But that creates new trust issues (did the user follow the course successfully, is the attribute really provided by the school, in what context can the attribute be used and some more).

I am not aware of any implementation. And perhaps we should not want such an implementation and we should think of another way.

As a user I would not like this hassle of using different identities or of 'IdP-in-the-Middle' constructs. I want a convenient place to store my attributes, some kind of a wallet. Not a wallet with different identities (although I really loved the Information Cardmetaphor promoted by Kim Cameron), but a wallet with different attributes. And the attributes within this store could be used with any of my identities that I want to use for a specific purpose.

I need a PAL, a Personal Attribute Locker, or a PASS, a Personal Attribute Storage System (I'm great with acronyms :) ). Identity Providers could post digital identities and/or attributes to my locker and I could mix and match whatever combinations of identities and attributes I would want to use. Provided that the context and scope of identity and attribute is a valid combination, but we'll have to think about this in another post. What would the implication be? Suppose I am an employee who needs access to the CRM system. But in order to execute some CRM task, I would have to provide an attribute that I am an experienced blog poster. This attribute cannot be provided by the company I work for, but it can be provided by Google because of this blog. Google could post this attribute to my PAL and I could use this 'external' attribute with my company Identity to execute the CRM task.

What do you think? Is this a feasible idea?

In a future post I will expand on this idea, because recently I found out about an interesting standard that could perhaps be used as the mechanism that I want...

Why worry about Facebook Whatsapp - part 2

A few weeks back I commented on Facebook taking over Whatsapp. As you can see my concern was that only if Facebook knows your phone number, it can datamine on the combined databases. As long as Facebook doesn't know your Whatsapp ID, your phone number, it cannot correlate the events in both social networks.

But I was naive. Chances are that facebook knows your phone number. Just recently I had to use a Facebook account. I don't have one. A few years ago I had a Facebook account, but I had Facebook delete my account.

But I needed to have a Facebook account in order to get access to a free wifi spot, I had to logon using a Facebook account. So, I created an account. And at that moment I found out that I had to enter a phone number in order to receive an SMS authentication token. Without a phone number I could only register by sending a copy of an ID card to Facebook. No way, I was in a hurry.
All I could do was enter my own phone number, because I had no time to get a prepaid sim.

So Facebook now knows my phone number. But, I created a fake Facebook account, with lots of strange likes.

And behold: Facebook suggested I became friends with a lot of people I know in real life... What other information in my account other than my phone number related to these people. My phone number must already be there, hidden deep within Facebook's treasure chest. I can hardly imagine my friends posting my phone number on their accounts.

Facebook never deleted my phone number or my friends network. So, am I worried about that Facebook - Whatsapp deal? No. I just kill my Facebook account again. I don't want at. And if I need another Facebook account, I will make sure to have a prepaid sim to use.