Archive for June, 2012

It’s all about relationships, not roles

Tuesday, June 19th, 2012

Are roles the right way to control access?

In some cases, clearly yes — there’s a whole formal model of role-based access control (RBAC) out there and it’s worked well in some business contexts for years.

But in other cases, just as clearly, RBAC is inadequate.

I raise this because in the context of an identity management system, one of the things we have to do is control who has access to whose profile. For example, can one employee see another’s work phone number? Home phone number? Scheduled termination date? Who can edit these things?

It turns out that pure RBAC is a poor model for access controls in these cases.

If we use RBAC, then we have to define roles for users who can access this data. Whose data can they access? Everyone’s apparently. For example, we might say that “all employees can access the work phone numbers of all users.” Sounds reasonable. Another example might be “only HR can access home phone numbers and scheduled termination dates.” Is that reasonable too?

If we think about these examples, we have to conclude that RBAC isn’t up to the task. For example, do we allow one HR user to see another HR user’s scheduled termination date? What about his own? If Bob in the corner (who happens to work in HR) is going to be terminated on Friday, should he know that? That’s a security problem.

What about usability problems? I would think that co-workers should be able to find one another’s home phone number. What happens if someone is hurt at work and you want to contact their family? How about if there is an emergency off-hours and you want to call someone to see if they can help? Clearly, we want to open up home contact information — not to the entire organization, as this could raise privacy concerns — but perhaps to people in the same department or location.

The same thing applies to scheduduled termination dates. It would be useful for managers to be able to see and change these for their subordinates. For example, a manager responsible for a large segment of the organization might want to periodically see what contractors are due for termination in the coming few weeks and perhaps extend some contracts to allow for unfinished work. On the other hand, the same manager should not be able to see his own scheduled termination date, or that of anyone who does not report to him.

The common thread that runs through these scenarios is relationships. What one user — lets call him the requester — can see of and modify in another’s profile — lets call the second user the recipient — should depend not merely on the requester’s role, but also on the relationship between the requester and recipient.

That’s the context of access control decisions inside an identity management system. In other systems, context may include other things — how is the requester related to the data he wishes to access?

And this is where RBAC falls short. To make access control decisions about what a given user can see or do, we need more than the identity of the requester — we need context for their requested access. In identity management, that context is a relationship.

So why do I bring this up?

In previous releases of Hitachi ID Identity Manager, access control within our software was built on an RBAC model. What I’ve seen of other, competing products is the same — access control decisions are made based on the requester’s role and usually nothing else.

Organizations that wanted to manage sensitive data in their IDM system would then either have to exclude it, reducing the value of their investment, or write lots of custom code, increasing the cost of their system. These were not good options.

Starting with release 8.0 of Hitachi ID Identity Manager, we completely overhauled our internal access control model. Our customers first define relationships and then attach access rights to those relationships. Relationships can be anything — manager/subordinate, same-location, same-department, etc. Really any set of criteria based on each user’s profile attributes and group memberships.

This means that with Hitachi ID Identity Manager 8.0, organizations can easily model their real-world requirements, without resorting to custom logic. Want to allow managers to see/edit termination dates for their subordinates? No problem. Want branch office IT staff to be able to reset passwords for co-located users? Easy. Want to block HR staff from seeing their own termination dates? Simple.

Call us and try it out. You’ll be impressed by the difference a smarter access control model can make.

Even more on linkedin..

Friday, June 8th, 2012

A cool calculator for the size of the search space that an attacker would have to cover to guess your password using a brute force approach:

More on linkedin

Wednesday, June 6th, 2012

Someone went to the trouble of registering a domain name and hosting some JavaScript sha-1 hash code, so you can test to see if your password was among those compromised:

Very cool.

linkedin hack

Wednesday, June 6th, 2012

Looks like someone managed to extract a copy of linkedin’s password hash database today.

Didn’t take me long to get my hands on a copy of the file. Here’s what
I found:

  • The file contains password hashes, but not user IDs. I guess it’s intended to demonstrate that the hashes got exfiltrated and that users pick weak passwords, rather than to compromise actual users.
  • The hashes are sha-1 without a salt. Forgetting to salt password hashes is a novice mistake – I’m surprised linkedin did that and in their shoes I would remediate that immediately. A simple way to do so would be to rehash every user’s password at successful login time, using a 64-bit random salt.
  • There are 6.5 million hashes in the file…
  • It looks like the file has passed through “sort|uniq” — i.e., each hash appears exactly once. Nothing to learn here about password popularity, alas.
  • Since the hashes were not salted, I was able to write a script to SHA-1 hash every password in a common dictionary and search the file for matches. That took all of about 10 minutes and yielded almost 20,000 passwords. No big surprise there (out of 6.5M different passwords, 20,000 are common words).
  • I’m sure that if I spent some time with it, I could do what crack used to do — add digits at the front and back, implement various capitalization rules and in general permute my dictionary to get many more hits. Probably not worth my while though, since the bit that would really make it interesting is missing (frequency of occurrence of each unsalted hash).

So lessons learned from all this:

  • Vendors: use best practices. Protect your password DB and salt password hashes.
  • Users: assume that your logins on at least some public web sites will eventually be compromised to some degree. Some people are screaming “change your password!” or “choose a strong password!” but really — you should just keep in mind the risk level of compromise of any given account. Personally, I wouldn’t care all that much if my linkedin account got compromised, but others might be more concerned than me.
  • It doesn’t look like anyone really malicious was involved here (they didn’t publish the user IDs, after all) but you have to wonder what would happen if this really was malicious?!