Password strength and adaptive authentication

Posted by Edward Killeen on Mon, Jun 18, 2012

The whole goal of authentication is security.  There is a lot of buzz around password strength and security, highlighted famously by XKCD.  Their theory is that long passwords equals password strength.  And it's true, a long password will take a lot longer to crack and if done right is remarkably easy to remember (like your favorite lyric from an obscure polka song).

Password strength and adaptive authenticationThe question is, will users ever take this advice and stop using passw0rd as their password?  No.  And, even if they do, they will continue to write it on a post-it note affixed to the bottom of their keyboard.  This is the inevitable and painful flaw in any password policy.

You know what solves this?  Two factor authentication.  Single factor authentication should never be allowed, you need a second factor like the user's phone and/or a hardware token.  Something that the user cannot just write down.  And that isn't guessable.  With a second factor, if someone gets your password, they still cannot access your application or data.

But, come on, are you going to make your users respond to an SMS message or spend the money on an RSA SecurID to check their email or punch in to the timeclock application?  Do you want your lowest privileged accounts having to ramp up security that highly?

Enter adaptive authentication.  The idea is that the more secure the data and/or application, the higher level of authentication is required.  So, your user logs in to the network using just his basic credentials.  When accessing email, this is fine.  Punching in to the timeclock, this is the appropriate level of authentication.

But, once your user wants to access CRM or Oracle Financials or the SharePoint site with the 10K draft in it, you want adaptive authentication.  Your authentication workflow should split out at this higher security application and ask for a second factor authentication. 

With this, you are taking a strong password and strengthening it to the nth degree.  Your user will need to provide a token or a code from their phone or a fingerprint or their first born, whatever you choose as the second factor.  You can even ramp it up and ask for something like Equifax's identity proofing service.

We will never get users to use the appropriately strong passwords we need for security, but using adaptive authentication we can add to password strength with second factor authentication on the most important applications.  What the heck, even add a third factor if it's important enough.

Click me

Tags: Password management, Identity and Access Management (IAM)

Google Apps password reset

Posted by Edward Killeen on Mon, Jun 18, 2012

While talking to a customer today, he mentioned that Google Apps didn't have a self service password reset option.  I can't say I didn't believe him, but I was a bit incredulous.  Gmail has a password reset, why not Google Apps?

I quickly googled the situation and found this in the Gmail section:

If your password isn't working, you'll need to go through our password recovery process. Google Apps users, please contact your organization's IT admin for help with password recovery.

Wow.  A service designed to reduce your organizational overhead requires helpdesk intervention to reset a password.

google apps password resetOnce confirmed as a problem, what about a solution?  There are two ways to go about this, Google Apps password reset or Google Apps single sign-on.  It depends on your infrastructure I'm sure and I'm probably looking at this from a very EmpowerID-centric view, but neither is a difficult proposition.

Once you have your central identity repository (metadirectory) connecting to Google Apps, it's easy enough to utilize your current self service password reset solution to change your password and synchronize that with Google.  This only works if your self service password reset solution can call the Google Apps APIs and shoot along the new password.  This isn't always the case.

But if you go the extra couple of inches and federate, you take this password completely out of the equation.  Google Apps federated single sign on means that your users don't need to remember another password, their main network logon is all they need to know.  If they forget that password, the self service password reset solution you have in place already works; they change the password, sign in and BOOM, they are federated with Google Apps.

You no longer have to worry about Google's inexplicably missing password reset feature because your users are authenticated automatically and you have password reset in place.  As great as Google Apps password reset would be, Google Apps SSO is even better.

Take a look at this whitepaper on the Top 5 Federated Single Sign On Scenarios to see how you are going to architect Google Apps SSO into your environment.

 

Click me

Tags: Single Sign-on (SSO), Password management

Secure self service password reset with two factor authentication

Posted by Edward Killeen on Wed, May 30, 2012

The traditional model for self service password reset drives me crazy.  The user gets asked questions to prove they are who they say they are.  And the system just resets their password.  Easy, right?  Secure, wrong.

Here is the issue, I can guess most of the answers to your questions by looking at your facebook timeline and the pictures on your cubicle wall.  Your first car, your daughter's name, your eye color, and so on.  That just isn't as secure as it should be.

two factor authenticatinoWhat you need is two factor authentication with your self service password reset.  The first factor is the questions, in other words "what you know."  The second factor is something you have, whether it's a pager or mobile phone or a keyfob device.  With proper two factor authentication, someone is not only going to have to steal your user's memories but their phone also!

This still doesn't get you everywhere you need.  It is also important to have complexity requirements, either to match or exceed your Active Directory domain policy.  My own personal preference, make the complexity pertain to password length rather than crazy characters.  It's harder to hack a 72 character sentence than P@ssw0rd.  And it's easier to remember the sentence.

Having a proper password synchronization and SSO tool also improves your password security.  If users have a dozen passwords to remember they are going to make them easy to hack.  They are going to forget them a lot and use easy to hack questions.  Make life easier on your users and your security will increase...counter intuitive but true.

Get a second factor in your self-service password reset, it's easy and secure for your users.  Click below for a demonstration of how simple this can be.

Click me

Tags: Single Sign-on (SSO), Password management

Content not found