"Authentication versus authorization" - Axiomatics blog

If you're interested in modern acccess management techniques, using, SAML, OAUTH and XACML based access, you should really read the three part blog by Andrew Hindle on the Axiomatics website:

Part 1: Federated Authentication

Part 2: SAML and OAuth

Part 3: Bringing it all together

Enjoy!

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.

Don't stop using XP until...

There is a lot of misconception about the security of Windows XP. Microsoft extended support ends today, after publishing the final set of security patches for XP that were developed to tackle security issues that occurred in the last few months. Microsoft has a 1 month patch cyclus, every 2nd tuesday of a month patches are published.
What does ending extended support for us mean:

If Microsoft would still support XP, the next set of security patches would only be published on the 13th of may 2014. Any zero day vulnerability that was discovered today, could, in an ideal world, only be fixed on the 13th of may, thereby leaving your pc vulnerable until the 13th of may. But that is the case for all supported Microsoft operating systems. Your 7, Vista, or 8 system would also be vulnerable until the patches of may 13t. Only in a few instances has Microsoft been pushed to fix earlier, but they keep with their regular scheme.

What does this mean for poor XP?

A fully patched XP system will be no less secure than a fully patched Windows 7, Vista or Windows 8 pc! Only on the 13th of may 2014 will the security be affected negatively because no new patches will be published. Your system will be vulnerable for ever...

Should you migrate?
Yes by all means. You may not be an interesting target for a criminal (you are, but I can probably not convince you today), but your pc is. It will be used as a spambot platform, or for bitcoin mining for others, running porn hubs for criminals, whatever. So migrate: YES


Should we panic?

Yes of course. But not because of today. We should panic because there are still too many XP systems.
Most consumer systems will be fully patched, but I bet that most companies who still run XP have graver problems. Many systems will not even be fully patched. So, consumers, you have one month left to migrate to 7, 8, Apple or Linux. Should you? Yes by all means!
And companies? You are in big trouble. You should fire the responsible management for not preventing this event.


===Update===
Hans Bos from Microsoft Netherlands mentioned that a fully patched XP system is less secure than a fully patched 7/Vista/8 system. He is right of course. Just have a look at Internet Explorer.
But then again, this has always been the case, XP has always been in a minor security league than more current systems. The class difference stays the same...

More XP trouble than you imagined

After april 8th 2014 Microsoft will no longer support Windows XP. Microsoft will publish no new security pathches for vulnerabilities and Security Essentials will only provide new malware signatures for a short while. Windows XP will be orphaned. By Microsoft. But many consumers and companies still use XP systems. They will be at risk. Because XP will not be orphaned by criminals. Vulnerabilities in newer Windows versions will be patched, but since all Windows versions since NT are related, chances are that a vulnerability in a more recent version is a vulnerability in XP too. While it will be fixed in Vista, 7 and 8 and will no longer be a vulnerability in those systems, such a vulnerability will still exist in XP and will be exploited by criminals. From april 8th this will be bad luck for XP users. At least for consumers. Most consumers will run a fully patched XP system, since Microsoft advises you to. So, for consumers to move to a more recent operating system is the only way to stay secure. But so far consumer pc's are not a big problem.

But there is an even bigger risk and it is not even a new risk: Enterprises and other organisations running XP systems. Those organisations have a serious problem. If they still run XP, then they have a change management problem. Commercial support for XP ended long time ago, meaning that they gambled that they would not need any support.

And we may have a big problem with that. In professional surroundings most workstations are managed centrally, from an update server. Patches are not downloaded directly from the Microsoft servers, but these organisation distribute patches in releases after they tested the patches. And such a process may take a while. Many companies roll-out new releases once in a while, two or three month intervals are common. Changing more frequent is often seen as a risk, because these (unsupported) systems better not be touched. Never change a winning team...

Will these systems be at risk after april 8th? Sure. Are they at risk now? You bet. If a company is still running XP at this moment, chances are that older patches have not been applied either. Stay away from organisations running XP, the problem is bigger than you imagined.

Complex passwords? As easy as 1-2-3

A few posts back I promised you an new and easy method for composing complex passwords that are, nevertheless easy to remember.

First some background to password complexity.

Why do we need complex passwords in the first place?

We don't.

There are two real reasons, we are told, why need complex passwords.

The first one is that a complex password is more difficult to remember, thereby reducing chances of password leakage. But at the same time creating the Post-It note problem of people writing down the password.

The second is that a complex password takes more time to attack using brute force password cracking techniques, but it doesn’t in itself prevent the use of dictionary based password cracking techniques. A dictionary based attack compares the hashed password in a password file to a words in a dictionary that are hashed using the same hashing algorithm. If the hash of a word in a dictionary is the same as the hash in a password file, then the corresponding word is the password. A clever cracking tool subsequently tries several permutations of the word, by replacing lower case letters by upper case letters or numbers or symbols, 'P@ssw0rd' will be discovered just as quick as 'password'. That way using leetspeak doesn't make password more secure that regular speak. If a word is not in the dictionary, another technique is required: just trying out all combinations to see is a hash resembles a hashed password of the target account. And in all simplicity that means that the longer the password, the more time it costs to crack it.

This leads to 2 simple conclusions.

• First: if a cracker uses an English language dictionary, he will not find my Dutch language word, meaning that will have to resort to a brute force attack...
• Second: for a brute force attack the password '1234567890' is just as complex to crack as '6Gr*7jgkhi'. It will probably be found faster because clever cracking tools will know this too and will use this kind of 'semi-dictionary' cracking words too, but in a sense: if a word is not in a dictionary, brute force requires a lot more time if the password is longer.

Proof of this principle:

The old Windows OS uses the lanman hashing algorithm. A password was broken in 2 7-byte segments, that were hashed separately. The hash of a 7 character password was enlarged to a 14 character password by adding a 7 character long Null string hash. If not more than 7 characters were used, the second hash was always the same. So, although the hashed password was 14 characters long, when the password was not longer that 7 characters, cracking the first 7 characters was enough to guess most passwords. If an 8th character was used, brute forcing the complete 14 character password was required.

In effect, this is the reason why many password policies prescribe the use of minimal 8 characters.

This results in a few simple rules:

Use long words that are not in a (regular) dictionary... German speaking people have an advantage here...

Use non-words that are long enough to make brute forcing a lengthy operation but that are easy to remember.

My advise:

Use your telephone number, but use leetspeak backward.

Example: phone number 01 234 567 89 consisting of only numbers.

Just exchange a few numbers to letters/characters in such a way that you feel comfortable with. A '0' can be an O (oh), or Z (for zero) or N (for Nul), in lower case or upper case, your choice.

So, this simple example may result in NE2D4vzZ8n or zOt3f5sse9. You just need to remember the order of hashing, but you don't need to remember the password, just remember the phone number used.

The entered password may look familiar if you know the algorithm used, but to a password cracking tool these passwords look all very different (all MD5 hash examples):

0123456789 > 84D89877F0D4041EFB6BF91A16F0248F2FD573E6AF05C19F96BEDB9F882F7882

NE2D4vzZ8n > 4DB3EA7E7894603A00091C8AABA25556B0366CF4C7045CF5B862477B44357040

zOt3f5sse9 > 4A384192BB6933877D9B7E29993DE7AF1EBC191DE6C30289F13F084EFD332B1B

Compare that with:

password > 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8

If a cracker can get at your hashed password, the cracker has no way of knowing how you defined your password. Make it as easy as you can.

We don't need complex passwords. And in a future post I will expand on this some more.

Facebook and Whatsapp, why worry?

The deal of the year, Facebook buys Whatsapp. And even before the dust settles, the privacy world is screaming murder. The privacy denying company buying a private messaging company spells doom for the privacy of hundreds of millions of users. You are warned to leave Whatsapp if you care for your privacy...

But is your privacy really at stake? Is the merger a new threat?

Facebook knows a lot about you. It knows your friends and relations, your likes, your updates, your whereabouts and it even knows what you would like to post but never really did. Facebook not only has access to your metadat, it has all content as well.
Whatsapp knows a lot about your telephone number. It knows the telephone numbers your phone number connects with and it has an enormous amount of metadata of all connections made.
And since both companies are American, you can bet that the NSA and it's friends have access to these (meta)data too.


But, and it's a big but, as long as a Facebook profile doesn't contain a telephone number, Facebook has no way to connect a profile with all Whatsapp metadata. There is no way to correlate a human profile with a phone profile.
It's a big but, but Facebook and Whatsapp live in different worlds en never the twain shall meet. So in my opinion there is no new privacy risk. If you really care for your privacy surely you would have left Facebook a long time ago?
So as far as I 'm concerned there is no need to dump Whatsapp. There are bigger threats to your privacy.



There's a second but, and that's a bit more tricky. A Facebook app and a Whatsapp app on a smartphone are different apps and they don't share between them, the operating system of the smartphone takes care of separation. Unless the operating system doesn't. I would say, stay away from any Facebook marketed phone...

So, until Facebook asks for your phone number, or you provide your phone number to Facebook, don't worry.

Trust is a one way affair

Cleaning up my blog and I found this snippet of text, waiting for further investigation. Feel free to join the discussion:


Any digital identity can only be trusted, as much as the identity provider (who provided the digital identity) can be trusted. If you don't trust an identity provider, you shouldn't trust it's identities. Seems logical. And even if you do trust the identity provider, you don't have to trust the digital identities from that provider. And you may trust the identity provider, but that is no guarantee that you can trust the digital identities. Or better... there is still no guarantee that there is a real individual behind the digital identity. It all depends on the identity management processes of the provider. But how can you tell which digital identities belong to real individuals?

What's the problem: if someone creates an account on my site, is that identity more reliable than an identity from a third party identity provider, that I may or may not trust?


If the identity is used only for identifying a website user for personalization purposes, then why not allow the use of any identity, trusted or not. If you allow extra permissions for that identity user, then that's up to you.

Allowing permissions for whatever task, should be based on a risk assessment, thereby taking into account classification of information and processes. Then you decide what level of trust is required. And it's up to you to decide what kind of identity is sufficient. It could imply that a gmail or twitter identity is enough for users to log into your site.


Perhaps that's why I don't like current trust models. They are too complex for most purposes. If people trust you to service them, that in itself is no need for you to trust them as well. Why should you? Only if you want them to service you, or get stuff from you and then pay you for it, then you should trust them. Until then, trust is a one way affair.