Identifying Opportunities for Improvement in Security Architecture

Here's a report that should surprise nobody - people pick predictable passwords (say that five times fast).

 

After the security breach, database security firm Imperva analysed the passwords used, publishing a report entitled Consumer Password Worst Practices.

The data found that the most common passwords were:

1. 123456

2. 12345

3. 123456789

4. Password

5. iloveyou

6. princess

7. rockyou

8. 1234567

9. 12345678

10. abc123

The analysis revealed a large amount of users had chosen "easy-to-crack" passwords, the most common being "123456", which was chosen by 290,731 users, or almost one percent.

'Nicole' was the 11th most commonly chosen code, followed by 'Daniel' in 12th. Other names appearing in the top 20 passwords include 'Jessica' and 'Michael'.

What is surprising is that this "secret" along with other great "unknowns" like Social Security Number, is what's used in standard practice Information Security to bootstrap the whole access control program. When the users are spoofed, phished, pharmed, and otherwise tricked into clicking on something that allows the bad guys in, they're routinely insulted as "how could they be so dumb" to click on that or whatever. But is it any dumber than architecture that relies on storing & shipping the dynamite and the detonator in the same truck?

Here is the process view of a typical, simplified software architecture

That looks fine, right? The Subject (users, web service, client) is separated from the Object (Web App, Server, Web Service, data), but let's look at storage of the above.

Notice anything? The Object logic and data is stored in the same domain as the Subject *and* the Subject's secrets. Does this make any sense? I will now bash my head on my desk repeatedly. 

The current architecture is not a security architecture in any meaningful sense, its an operational and deployment convenience. If you are building out security architecture like this for Web apps, Web Services, and Cloud, then please stop. Step away from the keyboard and look at using something else.

Start here for some ideas

Its not that any of these new identity standards are silver bullets, but they do something important. They move to enforce a separation of the Subject environment and the Object environment. They get the dynamite and detonators out of the same truck and into different trucks.

Not only that, but it changes the management process to enable each domain to do what they can do best. 

The lifecycle management of the Subject - such user registration, account maintenance, user authentication, is kept separate from the lifecycle management of Objects like service versioning, app deployment, instance level authorization, business rules and so on. The third rail being the agreement points in the federation, like contracts, between the domains (such as across organization, business units, and technologies). Carving out the responsibilities this way, gives each domain a chance to execute, and the standards like SAML enable moving the tokenized version of this around so it works at  runtime.

From a security architecture standpoint there's no real excuse to spray username/password around everywhere any more. The role of architecture is to separate concerns and place functionality and ownership in places where they have the most knowledge and resources to accomplish the task. In identity the knowledge and resources required to identify and manage users are totally separate from those required to identify and manage apps and servers, yet they are often combined into a lowest common denominator. The new identity standards like Information Cards, SAML, and oauth are widely supported in products, best of breed and open source. Investigate them and find the best fit for your company and systems. The only thing worse than a weak/guessable password is lots and lots of weak/guessable username/passwords. And that's what we have now.

Comments

[Chris]

The mainstreaming of "douche" as a slang term -- to the point of it passing muster with editors at a publication aimed at C-level geeks -- is fascinating.

Then again, it's clear no editor looked at that x-axis, since "teens" was left as the lone plural category description.