The US Government Claims You Don’t Own Your Cloud Data

Apparently the government thinks I don’t own the content of my blog:

But in addition, the government’s approach should terrify any user of cloud computer services—not to mention the providers.  The government maintains that Mr. Goodwin lost his property rights in his data by storing it on a cloud computing service.  Specifically, the government argues that both the contract between Megaupload and Mr. Goodwin (a standard cloud computing contract) and the contract between Megaupload and the server host, Carpathia (also a standard agreement), “likely limit any property interest he may have” in his data.  (Page 4). If the government is right, no provider can both protect itself against sudden losses (like those due to a hurricane) and also promise its customers that their property rights will be maintained when they use the service. Nor can they promise that their property might not suddenly disappear, with no reasonable way to get it back if the government comes in with a warrant. Apparently your property rights “become severely limited” if you allow someone else to host your data under standard cloud computing arrangements. This argument isn’t limited in any way to Megaupload — it would apply if the third party host was Amazon’s S3 or Google Apps or or Apple iCloud.

Putin Silencing His Critics

Using “The Children” to silence one’s critics.  You want to protect the children, don’t you?

Signed into law by Vladimir Putin on July 28, the internet-filtering measure contains a single, innocuous-sounding paragraph that allows those compiling the Register to draw on court decisions relating to the banning of websites. The problem is, the courts have ruled to block more than child pornographers’ sites. The judges have also agreed to online bans on political extremists and opponents of the Putin regime.


The Value of Partnership

Today I want to talk about a very simple idea:

A successful implementation begins and ends with a successful partnership.

This may sound obvious, but you’d be surprised how many people don’t understand this concept.  I’ve seen customers who are more concerned about extracting everything they possibly can from a vendor that they lose sight of their goal.  They point to the vendor any time a deadline is missed or a mistake is made.

I’ve also seen software vendors and integrators who seem to care more about landing a deal and maximizing revenue that they fail to serve their customers in the best way possible.  They look for excuses when things go awry, and resort to making up answers to issues.  This does not build trust with a customer.

I recently completed a project with a healthcare organization that understood this very well.  The project wasn’t the biggest technical challenge, but it was going to noticeably affect everyone in their organization, most notably their help desk who was going to have to handle calls for the new system.  However, we didn’t see the same resistance we see when implementing visible change at other organizations.  We were even able to get buy-in from the doctors, which is often a challenge in itself in healthcare.

The customer sponsor, the implementation team, the help desk and Identropy had all formed mutual trust with one another.  Because of this, we were able to effectively communicate the benefits of the project and work together towards a successful implementation.  One member of the customer’s implementation team even told me they liked Identropy from the start because we were willing to say “I’m not sure about that, let me get back to you” to questions before even landing the deal.

We ended up going live with barely a blip on the radar.  There were a few things that had to be tweaked after feedback from end users, but nothing major.

And one other thing, the project was also completed WAY under budget.  Part of it was due to changes in the initial scope.  Most of it was due to two things:

  1. We rarely had the communication issues that can arise from looking out for #1, and
  2. With guidance, the customer was willing to take on some of the work even though they weren’t formally trained on the product.

Rather than focusing on CYA and individual interests, we focused on the project.  I attribute this to the fact that the customer saw the value of our partnership, and viewed myself and Identropy as “Trusted Advisors” rather than just another vendor.  On the flip side Identropy understood the value of the project, and rather than just billing just because we had the hours, we truly worked in the customer’s best interests.

After wrapping up that project I joined an ongoing implementation with a large telecom.  Its an aggressive project.  Within the next 24 months we are to design, build, test, and implement a best of breed collection of logical access controls, physical access controls, privileged access management, as well as automated and request-based provisioning for an organization that cannot tolerate any real measurable downtime.  Oh, and the customer is new to pretty much all of these concepts and products and is relying heavily on Identropy’s expertise.

In most situations I would call this a daunting task.  In this instance I not only think its doable, but I have every confidence we will exceed expectations and deliver on-time.  How can I be so confident?  This customer recognizes the value of partnership.  They value a work-life balance, even for their vendors.  As a services vendor, I must say this is refreshing.

I just returned from my first on-site visit.  The purpose of the visit was to get to know the team and build rapport.  Of course I had deliverables to work on, but they could have just as easily been completed at the home office.  The better we know and understand one another, the better we will communicate and work together.

Don’t get me wrong, this customer can’t afford to simply waste dollars just to have their vendors visit the office.  Nor do they think they need to watch over us. They have assured us that they fully trust our abilities to work off-site without watchful eyes.  They just understand the value of getting to know one another.

It seems like all too often we focus on short term goals rather than building lasting relationships.  It’s good to work with customers (and for a company) that understands the value of these relationships not only for the team members, but for the organizations themselves.

Taking an Apple Approach to IAM Implementations

This post can also be found here on the Identropy Blog.

Ah, the religious wars: vi vs Emacs (vi!), Republican vs. Democrat (Neither), Mac vs. PC (Mac!)…

Mac vs. PC. We all know the talking points:

  1. Macs are pretty, PCs are not.
  2. PCs can be configured a billion ways, to use a Mac you must do it the way Apple thinks you should.
  3. Macs are easy, PCs can be difficult
  4. Did I mention Macs are pretty?

You may not agree with these assessments, but they’re popular opinions. You might ask why I would be blogging about them in a blog where I typically stick to consulting and Identity Management.

The fact is, we generally take a PC approach to IAM implementations: Here is the product, and these are the 5 million different switches we can flip to customize it for your organization. We have our best practices (default configuration), but ultimately we’re going to customize it the way you want it to be, whether it’s good for you or not. We want to be everything in IAM to everybody who will pay for IAM.

Is this the right approach? I don’t think it is. Why don’t we take a look at how Apple does things?
I recently read an article from Pragmatic Marketing, a journal my wife used to read as a product manager. They go through some of the reasons why Apple is worth billions of dollars and you aren’t.

A few of them stuck out at me:

You need to know your customer and your market.

The point is not to go ask your customers what they want. If you ask that question in the formative stages, then you’re doing it wrong. The point is to go immerse yourself in their environment and ask lots of “why” questions until you have thoroughly explored the ins and outs of their decision making, needs, wants, and problems. At that point, you should be able to break their needs and the opportunities down into a few simple statements of truth.

This is terrific advice. People do not typically know what they want, they only think they do. Invest the time in figuring out what the end goal is, then you can propose the right solution to the problem.

Pony meetings.

These meetings are scheduled every two weeks with the internal clients to educate the decision-makers on the design directions being explored and influence their perception of what the final product should be.

Keep leadership involved, and keep them on your side. Present them with an elegant solution that meets the needs of the organization. As long as they are on board with your solution, you can better drive the project.

Apple focuses on a select group of products.

Apple acts like a small boutique and develops beautiful, artistic products in a manner that makes it very difficult to scale up to broad and extensive product lines.

Dont try to solve every problem. Dont try to work in every vertical. Stick to what you’re good at, and be the best at it. This will actually make future engagements easier as you’ll have some street cred.


Ultimately, if you pay attention to detail and listen for what the customer really wants, not what they think they want, you should be successful. Just don’t be afraid to tell the customer “no” and explain why they need to change course a bit. The end result will be a successful implementation and a happy customer.

How strong is Your P4ssw0rd?

This post also appears here on the Identropy blog.

I never thought I would have a post on an Identity Management and Security inspired by a cartoon, but here we are.

In my earlier post about using CAPTCHA for authentication, I referenced a blog post by Thomas Baekdal.  A large part of his post was devoted to the idea that one should use a password comprised of a few relatively uncommon English words, rather than 8 – 10 characters of mixed case, punctuation, and numbers.

Randall Munroe was able to sum it all up in today’s xkcd cartoon:

Password Strength by XKCD

Password Strength by XKCD

It may sound counterintuitive to some, but we can break it down:

  • According to Webster’s, there are about 475,000 words in the English language.
  • To brute force a 3 word password would take on the average ((475,000) ^ 3 / 2) = 5.35e16 attempts
  • At 1000 attempts per second, that amounts to about 1.7 million years, on average, to brute strength crack the password.

Even if you limit it to the 50,000 most common English words, you are still talking about it taking 1,980 years to crack, and that doesn’t even take into account that you could still capitalize a letter here and there.

Using short pass phrases of 3 of the top 50,000 English words is not only more secure than your typical password, it is also more memorable.  That means it is less likely someone will write it down or need to call the help desk to have it reset.

Why aren’t more organizations pushing for pass phrases over passwords?

Debating the Email Charter

Email Overload

Email Overload

I’m sure that by now many of you have read or heard about the idea of an Email Charter by Chris Anderson.  It ended up spawning the site which lists the 10 Rules to Reverse the Email Spiral.

This thread created quite a spirited discussion at Identropy with some pushing strongly for better email restraint, while others believe one should err on the side of over-communication, letting the receiver decide for him or herself what is important, rather than the sender.  I’d like to outline each of the arguments and share my own opinion:


  1. Email can be a major timesink.  The more people are cc’d on emails, the more time is consumed by reading email.
  2. Brevity is a virtue.  The ability to be concise with language can more precisely illustrate a point while consuming less of the readers’ time.
  3. Appropriate communication is better than over-communication.  Often when over-communication occurs important emails get lost in the shuffle and ignored.


  1. We should err on the side of over-communication when working with customers, so that the left hand always knows what the right hand is doing.
  2. Everyone on a project should know all the information about the project.
  3. “If it wasn’t written, it wasn’t said”.  Always follow up a phone conversation with an email summary.
  4. I would rather have too much information than not enough.
  5. Today’s effective professional doesn’t operate on a M-F, 8-5 schedule.

After weighing the pros and cons, I have to side with the Email Charter.  Reading email has become a constant interruption and a chore for many.  The key is to be thoughtful and respectful of others’ time.  If you can say it in 2 sentences, then please do it.  If I send you an email about something, don’t respond back with “Got it.”  Its pretty safe to assume you got it.  

If you want to be cc’d on everything in a project then let everyone know and they can cc you, but don’t assume everyone else feels the same the way.  This allows the reader to have better control over their inbox and therefore their time.

Item 2 of the charter, Short or Slow is not Rude, addresses one of my biggest beefs with email: the idea that you should respond to email within minutes of receiving it.  If you need an urgent response, IM or call me.  I may not be sitting in front of my email.

Just this week I had someone ask my boss why I was ignoring them because I hadn’t responded to an email within 40 minutes.  I typically only even check my email every 30 minutes to an hour, and rarely check work email in the evenings or on weekends.  It’s nothing against you, I just don’t want email interrupting a meeting or my train of thought during the work day, and I don’t want work to interfere with my personal life.

Some may argue that you have to be available after hours to be effective.  I would argue that if you can’t get it done during your normal business hours, then you are either overworked or ineffective.

While I like the overall charter, One thing I would add is “Be polite when being concise.”  I’m old fashioned and still include a salutation at the beginning of virtually all of my email correspondence, even if it is a short one sentence response (Many people think I’m crazy for doing this).

I’m not saying that a salutation is necessary for all emails, but I am saying that one should at least be aware of how the recipient could view the tone of your response.  It can sometimes be difficult to discern tone in an email.  I typically give all my emails a quick second read before sending.

I think the email charter is a step in the right direction.  If we can all be thoughtful and concise when sending emails, it can greatly reduce the amount of time spent on checking email, as well as the distractions it causes.

No More CAPTCHA For Authentication

We have a customer who is looking to implement CAPTCHA on the authentication page of an external facing self-service password reset page.  This just seems like an unnecessary measure to me.  It’s something that will end up frustrating users and leading to helpdesk calls.

We’ve all tried to log in to a website and been frustrated by the dreaded CAPTCHA.  We stare at it trying to figure out what exactly it says.  According to a study at UC San Diego [pdf link], the median response time to CAPTCHA is 14 seconds, and accuracy is about 90%.  That adds up to a lot of wasted time.

Here is the latest one I received from Google:

Captcha Image

naushdest? ndishclest? noushclest?

Can anyone tell what this says?

I’m sure some of you can but I sure couldn’t, and I have 20/20 vision.  The biggest problem I have is that it wasn’t even necessary.  I was logging into my Google account.  It already has authentication.  If you’re worried about bots brute forcing authentication, CAPTCHA is not your answer.  Better authentication is.

It reminded me of a blog post by Thomas Baekdal I read a while back about the usability and hackability of passwords:

All you need to do is to prevent automatic hacking scripts from working effectively. What you need to do is this:

  1. Add a time-delay between sign-in attempts. Instead of allowing people to sign-in again and again and again. Add a 5 second delay between each attempt.It is short enough to not be noticeable (it takes longer than 5 seconds to realize that you have tried a wrong password, and to type in a new one). And, it forces the hacker to only be able make sign-in requests 1 every 5 seconds (instead of 100 times per second).
  2. Add a penalty period if a person has typed a wrong password more than – say – 10 times – of something like 1 hour. Again, this seriously disrupts the hacking script from working effectively.

If you just add in a 5 second delay between attempts with a 5 minute penalty period after 10 failed attempts, then a 6 character password, letters only, case insensitive would take an average of 171 years to crack via brute strength.  I have a feeling the password would either be irrelevant or reset by that time.

I understand that CAPTCHA has it’s place when you want to make sure a human being is using a page to answer a poll, purchase tickets, register for a site, etc.  For those limited circumstances, it’s appropriate.

It is not appropriate when coupled with authentication.   Can we finally get rid of it and actually make sites that are easy on end-users?

Hat tip to Kerem Kacel for pointing me to the 14 second stat.