Operations // Identity & Access Management
12/20/2013
08:06 AM
Patrick Harding
Patrick Harding
Commentary
Connect Directly
Twitter
Google+
LinkedIn
RSS
E-Mail
50%
50%

Yes, In The Internet Of Everything, Things Will Have Passwords

Things would have no problem remembering passwords like "jH6Gf!e6Bf@." But even for things, passwords are less than ideal.

It is easy enough to say that, in the Internet of Things, things will have identities. (It must be easy because every identity management vendor appears to be saying it). Toothbrushes, toasters, jet engines, HVAC units -- each will all have an identity.

But just what does a thing having an identity mean? To explore that, let’s think about what having an online identity means for ourselves. Consider three key online use cases that involve identity: sending an email, logging into a website, and authorizing a website to access your information stored elsewhere.

When we send an email to a friend or colleague, we enter the person's address into our email client, type the message content and then click send. Our mail provider's servers, based on the domain of the target address, determine how to route that message to the corresponding server at the other end, where it can be subsequently retrieved and then read.

We don’t think about it, but the @ in the email address implies that email works across email providers. (It didn’t initially. There were islands of email.) There is significant invisible (to us) resolution infrastructure making that interoperability happen. Similar magic happens when we enter a website address into the browser URL bar -- the name format that we find convenient in referring to websites is not what the IP network uses -- and lots of invisible infrastructure works to resolve between the two.

Depending on the use case, things may require the same sort of cross-domain interoperable addressing. How we name things will matter, and in the absence of a single global registry of such names, we will need mechanisms to match entries between multiple similar registries. When we log into a website, we (typically) present a username and a password -- both established with the website in a previous registration step. The site compares the presented password to its copy and if the two copies match, grants us access to the corresponding account data.

Human evolution & SSO
For humans, passwords are challenging. Evolution has wired us to find it easier-to-remember gossip and stories about hunting bison than strings of characters, so we cheat by choosing the shortest and easiest to recall we can get away with. Federated Single Sign On (SSO) systems replace passwords with standardized security tokens, which are issued by some other website to which the user actually directly logged on, and so serve to mitigate a full password explosion.

Things will also need to login to each other, to local gateways, or perhaps to cloud servers. They will do so by including some sort of secret authentication credential on their messages to those other actors. The SSO model is also relevant to things, but not because of a thing’s limited memory. Things would have no problem remembering passwords like "jH6Gf!e6Bf@." But even for things, passwords are less than ideal. Would a thing need to establish and store a different password for every other party it might interact with? If so, the resulting cache of passwords would be an attractive target for hackers.

The federation model will be relevant to things because it will allow things to authenticate to other actors in different trust domains, i.e. to actors with which the thing does not have a direct relationship. In a federated world, things will directly authenticate to some authentication authority (perhaps on the cloud) with an existing credential and receive back in response a different (authentication) token to be used to authenticate to other actors. This model would, as an example, allow a Nest thermostat to send a "close" message to a garage door controller from a different manufacturer if it sensed the temperature dropping.

Another common identity use case these days is for a website to ask us for permission to access our account information stored at another website, the data flowing through API calls. To do so, the requesting website must be able to present some sort of proof to the API endpoint that it is acting with our consent. The current best-practice model has the requesting site asking the user to consent to the hosting site with a security token that represents the user's consent for some operation (e.g. read the user's Google calendar) to be performed against the API.

That dynamic may also be relevant to the IoT. Many things will be operating on behalf of a particular human, or set of humans. For example, my Fitbit Flex sends my step data up to the Fitbit cloud, not some other user's data. That relationship could be captured and expressed via the delegated authorization model. The user would facilitate the issuance of a security token from the Fitbit cloud to the device. This token would then be used on subsequent API calls to identify to the cloud the combination of thing and user. Also important, this model allows the relationship to be broken when appropriate, such as if the Flex were lost, stolen, or sold.

Like us, things will have identities. They will have identifiers and addresses and will need to be authenticated. They may even act on behalf of particular users.

Patrick Harding is responsible for the Ping Identity product and technology strategy. He brings more than 20 years of software development, networking infrastructure, and information security to the role, which includes oversight of the Office of the CTO and Ping Labs.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
1/2/2014 | 8:35:55 AM
Re: Scary "Things storing passwords"
Confession: I took a little liberty with the headline  to add a tongue-in-cheek element of playful humor and hyperbole reflecting on Pat's tone inorder to grab your attention. And it worked, judging by the string of comments. But in the article itself, it is very clear that Pat is talking primarily about identity and the IoT. I think he does a great job comparing what having an online identity means for people versus things.
asksqn
50%
50%
asksqn,
User Rank: Apprentice
12/30/2013 | 10:45:38 PM
Get a password remembering plugin
The priblem is not one of memory as much as it is having to surrender more info than what is necessary for A to authenticate C, D and E. Case in point: Mobile apps with my way or the highway TOS. The app wants e access to everything short of a blood sacrifice and a drug screen, and, if the user does not agree carte blanche, then the app won't install. This type of shrinkwrapped agreement is neither secure nor private and does not inspire confidence from those of us who are technically savvy.
jgherbert
50%
50%
jgherbert,
User Rank: Apprentice
12/30/2013 | 4:01:45 PM
Re: Scary
@shamika: "The best combination of password's always consist of characters with both lower and uppercase, special symbols and numbers. Those considered being more stronger."

As they say, it isn't what you have, it's what you do with it. If the way in which we use those various characters is predictable, then even an encrypted hash of the password could be easily crackable. e.g. If you take a dictionary word like "notebook" and the password is "N0t3b00k!" - i.e. first letter capitalized, all vowels replaced with numbers, bang on the end, I would wager the password would not last long with a good cracker, yet it meets your stated requirements.

So maybe let's add to those requirements "...has decent length, is pseudo-random and does not follow predictable patterns" or something like that? Whatever the definition is, what it comes down to is that a "good", "secure" password is exactly the kind of password that's not memorable, and that sucks.
jgherbert
50%
50%
jgherbert,
User Rank: Apprentice
12/30/2013 | 3:56:37 PM
Password Managers
"Evolution has wired us to find it easier-to-remember gossip and stories about hunting bison than strings of characters, so we cheat by choosing the shortest and easiest to recall we can get away with."

On a slight tangent from the main point of the article, the standard response to moaning about passwords is to be told "use a password manager". I've discovered that so far, at least, they're good for storing things, but really are not as convenient as they should be in terms of how they integrate both with systems requesting authentication, and with cross-platform support.

For example, most password apps allow you to auto-generate a password for a web site (a good long random(isj) mix of character types creating an utterly unmemorable password). That's fine, but now I MUST have that password written down (stored in the manager) for that site. Next time I go to that site, I have to find that password in my manager. Some will spot that I'm on the site and offer up a shortcut to go get the password; some will enter it for me once I find it; and - many fewer - will spot that I'm on the site and automatically log me in. So far so good, but now I'm on my iPhone and want to log in. First of all, using a complex password to protect my password manager is a pain on a mobile device's soft keyboard, which is an immediate turn off - all those special characters and upper/lower case shifts makes a 12-character password require 22 keypresses to complete. Then I have the same problem - the best I might achieve is to find the site entry, copy it, then go back to the browser and paste it in. It's a very cumbersome process.

I've worked with one SSO system in the past, and it was quite good - login when you bootup and after that it was able to log in to almost every system on your behalf. Certainly almost every website authentication request could be managed, and even some apps. That's what I need on my phone too, plus automatic cloud sync between my phones and computers (I have mac, PC, iPhone and Windows Phone, so I need cross-platform support). When that comes, I don't mind having a highly complex password for my SSO manager and complex passwords for every site, because I only have to login to my SSO once per session. Oh - and yes, this does rather imply on a mobile phone that a PIN and automatic screen lock is a necessity, and that automatic password-protected screen savers were likewise a necessity on computers. Add to that the concept that a single login failure should trigger a logout of the SSO client so that brute forcing wouldn't get you access to a system with SSO enabled, and we have something that might actually be vaguely usable. Let me know when you find that, would you?
jgherbert
50%
50%
jgherbert,
User Rank: Apprentice
12/30/2013 | 3:46:34 PM
Re: Scary
@PaulS681: "Things storing passwords is a bit scary."

 

Agreed; and this is why it may be preferable to have a device holding a digital token on your behalf (like giving a Twitter app the ability to do things via API) giving them per permission to (a) do limited things, possible (b) for a limited time, and (c) revokable on demand. While this doesn't prevent credential theft, it does at least limit the impact of what that theft can achieve. You wouldn't, for example, want your thermostat to hold a copy of your password for your online banking just so it can pay the gas bill for you automatically or something; you'd want it to have permission only to pay a bill, only to a pre-determined recipient (the gas company) and for a limited value. Probably a bad example, but you get the idea. I like the concept that apps (or items in the IoE/IoT) can ask for permission to do things and I can grant it, with restrictions, and not have to actually deal with a password for the device.
shamika
50%
50%
shamika,
User Rank: Apprentice
12/28/2013 | 9:46:05 PM
Re: Scary
@ WKash, Interesting point you have highlighted. I believe it is an important aspect to look in to.
shamika
50%
50%
shamika,
User Rank: Apprentice
12/28/2013 | 9:45:34 PM
Re: Scary
The best combination of password's always consist of characters with both lower and uppercase, special symbols and numbers. Those considered being more stronger.
shamika
50%
50%
shamika,
User Rank: Apprentice
12/28/2013 | 9:45:01 PM
Re: Scary
"For humans, passwords are challenging" this is true. When we use passwords it is always important to look for strong passwords otherwise it can hacked easily. There are enough and more password hackers in the current market.
shamika
50%
50%
shamika,
User Rank: Apprentice
12/28/2013 | 9:44:27 PM
Re: Scary
Interesting article and thanks for sharing this information. This article shows  the exact workflow on how things happen which we see as a simple task. 
PaulS681
50%
50%
PaulS681,
User Rank: Apprentice
12/23/2013 | 8:19:00 PM
Re: Scary
Things storing passwords is a bit scary. As Patrick points out they could be a target for hackers (no pun intended). Things with passwords is an interesting futuristic concept although the future is now. I will be interested to see how these things manage passwords.
Page 1 / 2   >   >>
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.