The death of the password cannot come soon enough

The death of the password cannot come soon enough

The death of the password cannot come soon enough

2 comments 📅02 January 2016, 02:45

The death of the password cannot come soon enough

The death of the password cannot come soon enough. Not only have passwords proven to be insecure, but with the advent of mobile devices that lack full-sized keyboards, entering them can be one of the most frustrating activities for an enterprise end user. The recommendations of the security community to have long, complex passwords are at odds with the difficulty of entering them in the first place. And then, entering them multiple times per day is even worse.

Things are really awful for the average mobile user who uses a multitude of consumer-oriented internet services. First of all, it’s become clear that service providers cannot reliably keep these passwords secure. That means that, at least for the services that are storing our personal data, it’s really important that we use unique (i.e. different for each service), long, complex passwords.

But sometimes it seems to me that this is being taken too far. I recently registered online for a news-reading service, where I didn’t need to use my real identity and there was no personal information involved. And it STILL made me choose an 8-character complex password without any common patterns or repetition. I could live with it if the desktop was my only device. But I use my phone all the time, and this was too much. No way I’m going to enter this password on my mobile device regularly, just to read the news. I gave up on the site. There are plenty of others.

There are a couple of solutions that the industry is brewing up for this problem. One of them is to use a common service, like Google, Facebook, or Twitter to act as your identity provider. You log into them and you authorize them to share your identity with whatever new service you want to use. But if you don’t trust Google with your password to begin with, can it be a trusted broker for your identity? What will it be able to do with that data? Will it use that data appropriately?

A more safe and secure option is password managers. The assumption is that users WANT to help maintain the security of the data they access, so they recognize the need for unique, long, random passwords across all of the services they use.  The password manager generates a random password for each service and stores it.

The user needs remember only a single password, which is the one that unlocks the password cache.  The tools help the user retrieve the password out of the cache and enter it on the website.  This works great if users are willing to launch their website from the password manager tool (awkward), or if they are willing to add an extension to their web browser that can automatically enter the password.  But what if it’s not a web-based app?

And how do you sync the information across services?  And what if the user’s browser of choice cannot be extended (for example, on iOS?)  This then requires lots of awkward copying and pasting, making the situation even worse than it was before. Still, using password managers is better than NOT using them!

However, password managers don’t really apply to the enterprise user, where there is normally only a single password used for all enterprise services. Yes, for browser-based services on the desktop, password managers can help you enter the long, complex password on each website, but, beyond that, they don’t really help.

In the enterprise, the authentication answer has been “Single Sign-On” (SSO) solutions.  The promise of SSO is that, first thing in the morning, when end users interact with the enterprise, they will get prompted to authenticate themselves (normally with a username and password) to their computing devices. The assumption is that the device is already trusted by the enterprise. The user has now established a session with the whole enterprise so that the next service accessed won’t require a password re-entry. The user only has to authenticate once during a given time period, no matter how many services are accessed.

However, only a small minority of enterprises have implemented SSO. It requires communication and collaboration inside the IT department. This can be challenging, especially for the larger enterprises. And even for the ones that have an implementation, there are still limitations, especially for mobile apps:

  • In some cases, SSO only works from Windows desktops, not from mobile devices.
  • In other cases, SSO only works for web-based apps because it’s the browser, not the device, that brokers the identity.

The Mobile First world doesn’t have Windows desktops and does have lots and lots of distinct apps. This requires a complete re-think of SSO.

Here’s how we’ve been addressing this challenge at MobileIron. With our AppConnect framework

  1. We have a secure application communication bus. Authorized, IT-managed apps can communicate with each other on the device, but their data and communications are protected from unauthorized, user-managed apps on the same device.
  2. We can intercept server communication from authorized apps to transparently tunnel appropriate requests back into the enterprise network.
  3. We can distribute unique identity certificates directly into an app’s sandbox.

What do you get by combining these existing functions with a little bit of new code? True SSO on mobile! Whether the SSO system is based on Kerberos, SAML, OAuth, or anything that follows their basic principles, these features can be combined together to achieve the goal of SSO without security compromise.

My next post will discuss how to eliminate password entry altogether through replacement technologies such as smart cards and biometrics.


Mitchell Buchler
    08 January 2016, 02:45 Mitchell Buchler

    I have a pair of the Shure SE846. You should try them if you have the chance.

    Reply to this comment
    10 January 2016, 02:45 MUTINOUS

    Mind blown…. ~ €: – o

    Reply to this comment

Leave a comment