Wednesday, June 17, 2015

P@$$w@rdS Must Die!

...okay look here.

Every one of us wrestles daily with the problem of both protecting our online assets, and reliably gaining access to them. It's crazy, and as Cloud Computing comes into its own for mainstream use, the problem is going to just get more unmanageable.

Let's talk about passwords a little bit, and maybe we can agree on what's reasonable for the future.

When individual computers used to be a Big Damned Deal, we could rely on some primitive measures to protect them. First, there were only a few people who knew what to do with them, and then they had the only boot disks, so the machine couldn't even start unless they were there.

It's sort of appalling that entire offices actually did meaningful business with one or two "IBM compatible" computers in them, and with these marginally trained jealous harridans to guard them.

But then something happened to change everything...


We began to work in an interconnected world, and that meant Unix (or some strange thing called Novell, but blissfully, most everyone has forgotten about that).  Once we had interconnected computing and the stakes were higher, we had to adopt some of the practices of mainframe computing.

Everyone who wanted to gain access to the computing system had to have a username/password pair known only to them. (Well, only to them and anyone who knew where they stashed the PostIt Note™ with the information on it. Or someone who knew their pet's name, or their kids' birthdays.)

We taught computer operators to obey some simple rules of password management.

  • Change your password regularly
  • Make your password unguessable by avoiding obvious personal information or key words
  • Never write down your password or share it with others, especially by phone

But the truth is, none of them did that.

So after a generation of "pasword1234" and "sally1979" (for Sally who was born in 1979), we had to do something to stem the tide of compromised credentials that led to cascading security failures. (That's when one person's weak credentials allow a hacker to get into a system deeply enough to ruin it for everyone else who uses it - including management, customers, and business partners.)

This is why today you encounter systems that are designed to protect some deeply critical knowledge (like your accumulation of airline miles, or free Starbucks Coffee points) that militantly insist that your password must have at least two alphanumeric characters, at least two characters from that part of the keyboard that you can only reach in very bright light because you don't use the ^ or the & key in day-to-day communications, and must be at least 14 characters long.

Here's the real thing you cave-dwelling "so called security experts!"

Passwords are the second worst possible security mechanism you could possibly ever use. (The worst is simply not caring who uses your system.) And in many cases, the measures you apply in the attempt to make your system more secure pushes the strategy well up into the realm of a contender for the #1 spot! (ie. With you around, passwords become the very worst possible security measure.)

Look here -- If you make the password regimen too difficult for ordinary people to manage in their heads, and in our increasingly faulty memories - do you know what we'll do?!

We'll write the damn things down on paper, and if we really care, we'll make copies to share with our friends.

So how about if we think of another way.

Phil Zimmermann, the inventor of PGP, talked about an idea in the 1990's called Circles of Trust. The principle behind it is that rather than rely on a single secret (your password) we can determine the authenticity of any person by the various elements of evidence that surround them that confirm identity. This includes others who will vouch for the person, and the network of others who will vouch for the "vouch-er" and additional clues that point to the veracity of a person's claim.

The simple principle we see in (not nearly enough widespread) use today is the principle of Multi-factor Authentication. Some "so-called security experts" think that this means using some technology dongle that generates a complex key that can be used to prove that a person is who they say they are.

But it really goes beyond that. Here are the basic principles that allow us to begin proving that someone is who they say they are:

  1. They know something that only they should know
  2. They have something that only they should have
  3. They can do something that only they can do

Passwords satisfy only the first case. Or perhaps, knowing which of the Three Stooges is their favorite, or (in some cases) knowing who was the Major League Batting Champion in 2004, or knowing who "that guy -- who was in that movie" really is.

To satisfy the second case, a dongle supplied by your employer that generates a one-time key, that's a great thing. But biometric data such as fingerprints or retina patterns, that's another good way. It's even true that we can measure the rhythm between keystrokes when writing at the laptop keyboard and discover a pattern as definitive as a fingerprint.

One thing that modern IT systems could use is a trace that uses our social media graph and our location-based data evidence. More and more people enable location-aware services for their devices, and the pattern that they provide is one that can help prove your identity very easily.

If I'm checking in on Instagram regularly throughout the day, and suddenly someone tries to log in as me from another continent, there's a big clue.

For many of us now, it's actually No Big Data trick to tell whether we're telling the truth.

So would you Get Off It, you silly little system operators who protect the data for the Hyatt Rewards program, or the Sally's Very Specific Interest Forum page? Move to Single Sign On (SSO) and let professionals manage the world of deciding who is really who.

On the other hand, daar reader, since you are the consumer (and the victim) in this scenario, plus you probably don't have the phone number for Sally, or a meeting invitation to the Hyatt Information Security Roadmap meeting, stay tuned here and we'll talk next about some tools you can use to manage the (literally) hundreds of credentials pairs you have to manage.

I think we have much to discuss.


No comments:

Post a Comment

Reduce to Dashboard

When developers use DataWeave, they often come to rely on the reduce() function to fill in any gaps left by the standard Core library. Altho...