Establish Your Fundamental Security Posture

Part of the allure of cloud-based services is the whole access from anywhere aspect of it -  at work, on the road, in a coffee shop, in a public park, in your hotel room. As public, often free, wifi becomes something we (especially road warriors) start to rely on more, make a checklist of things you do in order to secure your interaction with cloud services, which should include (but isn’t restricted to):

1. Make sure you secure your communication with cloud services by using HTTPS instead of HTTP. I highly recommend installing the ‘HTTPS Everywhere’ plugin that the EFF have released
2. Use a Virtual Private Network. It lets you route all your activity through a separate secure, private network, thus giving you the security of a private network even though you’re on a public one. A lot of people can get it through work, but if your job doesn’t come with one then get your own, like CyberGhost VPN or WiTopia (Check out this Lifehacker article)
3. And watch out for shoulder surfers

Don’t Reuse Your Passwords

It’s an all too common phenomenon: when setting up an account with a cloud service, users are forced to come up with yet another password, and they choose a familiar, well used one. Especially when signing up for services for work, people will often use the same password they use to access services internal to the enterprise (like their email system, or their corporate CRM system). Reusing those passwords definitely helps you remember it for next time, but it’s the equivalent of leaving your house keys in the mailbox – someone else will eventually see it and figure out how to use it.

Better Still, Use A Password Manager

As our usage of the cloud increases and we battle password fatigue, that last point becomes increasingly harder for us. But there are tools like LastPass and 1Password that can help us greatly, not only by remembering the passwords for us (in the cloud, of course) and providing simple plugins to autofill those pesky login forms, but by also generating random string passwords that are stronger than your average password. Just remember to follow all their recommendations: create a really strong and unique Master Password, configure the settings to recognize trusted locations (like your home network), make sure to read their ToS and security policies, and use common sense in trusting what is still a cloud service.

Bring Your Own Identity

But those last two points still rely on having multiple passwords, which is recognized widely as an insufficient approach to security. Federation technology has matured to the point where we can now rely on federated login to cloud services. Most enterprise service providers will support federation with your corporate identity, eliminating the need for passwords to log into these services. And on the consumer side it is becomingly increasingly easy to sign into your services like Tripit or Flickr using your Gmail, Facebook or Twitter identity, using mechanisms like OpenID and OAuth that do not share your password with the relying site. The goal is not to go down to one password for one account that is your key to your online life, but rather have a manageable number of identity providers that you then use to access your various services. And use common sense to evaluate the sensitivity of a particular service before setting up a relationship between it and an external site.

Review Those Service-to-Service Relationships

The concept of a periodic review of user access is a cornerstone in enterprise governance programs. Why should our personal life be any different? As you rely increasingly on the federated model, set up time to periodically go into your services and review which Mobile Apps and 3rd Party Services you have granted access to. Did you grant some twitter ranking site access to your twitter account months ago, but have never gone back and used it? Reviewing the access grants will remind you to sever that relationship, removing any possibility of abuse or exploit.

Are there any other steps you take that help keep you safe? Practical suggestions only please, unlike this (hint: see second last bullet).

[Cross-posted from the Identropy blog]

Tags: Cloud Security, Password Management, Passwords Must Die, Personal Identity Management

RSA is not the best conference for identity related news and topics, but there were more than a few interesting story lines that emerged last week (and no, I am not referring to what went on at the Ping Party). One of those was the announcement that Microsoft would not be shipping Cardspace 2.0, which is being widely interpreted as the death of Cardspace. Mike Jones points out that this may be an exaggeration, and until I see Pam pronounce it dead, I won’t be writing any obituaries. But I did want to share a thought that has been rattling around in my brain for a while.

The day before RSA started, the Kantara and IIW folks gathered in a studio not far from the Moscone Center for ID Collaboration Day. One of the sessions was about the work that the Universal Login Experience Work Group of Kantara has been doing in trying to solve the usability problem of 3rd party logins at sites that want to be open and accommodating of providers and protocols. And when we look at the Cardspace experience, one thing is crystal clear: it has to be SIMPLE.

Debates over what is simple, which button goes where, how to order things, etc will go on and on. But when I step back and think about it, I see that a good workable model already exists which has gained a lot of traction – that of the browser-based login helper. This goes from Firefox/IE/Chromes in-built password manager, to the venerable Sxipper, to the upstart (but on the rise) cloud-based solutions like LastPass. They solve the problem by giving the user a simple, intuitive UI to work with, without relying on metaphors like cards or avatars. And it is obvious that all the debates about whether users would trust some random service to remember their sensitive passwords goes out the window when it just works.

Sxipper UI (from sxipper.com)

Granted, they are dealing with the (relatively) simpler problem of form-filling. But there is no reason why the UX couldn’t be expanded to handle IdP-based AuthN, where instead of selecting the user name in the widget, I select the provider. Having the widget (service) remember which providers I have registered and commonly use, and also remember usage history would not be a problem. And the UX for presenting multiple personae already exists and, more importantly, is understood.

I’m sure there are technical nuances that would need to be solved. But I’m focusing on the specific usability aspect of the problem, and it seems to me that there is already a successful model that can be built upon. And I’m also sure that I am not the first one to think of this, so if there are reasons why this wouldn’t work that have been previously discussed and blogged about, please point me to them. Because it could impact some of the work we are doing at Oracle. And nobody wants us making a mistake

Update (2/22 at 8pm): Kim Cameron wrote a post that seems to at least confirm what I am thinking here.

Tags: Authentication Services, Cardspace, Federated Consumer Authentication, Identity In The Browser, Information Cards, Password Management, User-Centric Identity

1. The answer cannot be easily guessed or researched [Safe]
2. The answer doesn’t change over time [Stable]
3. The answer is memorable [Recall-ability]
4. The answer is definitive or simple [Simplicity]

Good criteria to remember next time you are deciding between “What is your pet’s name?” and “What was the name of your first stuffed animal?”.

Of course, the service you are interacting with needs to allow you to choose from a large enough set or supply your own questions so you can adhere to this principle. And a highly sensitive application should go beyond just plain security questions. While most services are moving towards simpler yet more secure mechanisms – emailing the user short-lived password reset tokens, for instance – there are many cases where you still need a challenge-based mechanism (like when the forgotten password is the one used to access your email).

Knowledge-Based Authentication has gotten increasingly sophisticated over the last few years, and enterprises looking to leverage this can do better than just providing their users a few hard-coded questions to choose from. Oracle Adaptive Access Manager 11g brings features like Answer Logic (which employs fuzzy logic to increase the usability of security questions) and One-Time Passwords (delivered via SMS, email, IM or voice) into the mix, while also adding real-time risk analytics to make the overall process more secure, reliable, usable and cost-effective.

And all of this is delivered as a service so that enterprises can incorporate KBA into their various applications as needed. In fact, as part of the suite-wide integration design theme of Oracle Identity Management 11g, OAAM now has out-of-the-box integrations with Oracle Identity Manager and Oracle Access Manager. So if you deploy the suite, the real-time risk analytics and risk-based challenge mechanisms of OAAM are automatically leveraged by those other products. It is a sweet thing to behold.

Even as we sound out the call to kill passwords (an NPT for passwords; I like that), KBA will continue to be a critical tool in the identity proofing arena. So keep an eye out for all the innovation that will take place in this field.

Tags: Identity Proofing, Knowledge-Based Authentication, OAAM, OIM, Oracle Identity Management, Oracle Identity Management 11g, Password Management, Password Recovery Techniques, Security Questions, Service-Oriented Security

In a nutshell, here is what happened as I understand it: A hacker named Hacker Croll (who has been a pain in Twitter’s behind for a while now) was able to gain access to the Gmail accounts of various twitter employees, including founder Evan Williams. He was then able to use the regular password-recovery techniques that rely on email-based mechanisms to gain access to other services being used like Paypal, GoDaddy, Amazon and Apple. But most notably, he had access to the Google Docs service that the Twitter folks were using extensively to store sensitive corporate documents. This landed Hacker Croll a goldmine (that has been shared with TechCrunch) of documents, including “financial projections, product plans and notes from executive strategy meetings”. Twitter has a lot to deal with here. But this is an important IdM and Cloud Computing related cautionary tale for all of us. And the takeaways, while obvious, bear repeating.

This episode underscores the fact that password recovery techniques that rely on email delivery of passwords or password-reset links are highly insecure. Secret question based mechanisms (aka Static Knowledge-Based Authentication) are not that much more reliable either (anyone and everyone can find out the name of any celebrity’s first car, dog, mother’s maiden name, etc). Services that deal with sensitive information NEED to rely on Dynamic Knowledge-Based Authentication (where the data source for the authentication questions could be the content stored in the service itself, which only the users should have knowledge of) or Out-Of-Band Identity Proofing (something Oracle Adaptive Access Manager can help with).

As more and more companies rely on the cloud, the security of cloud services (or lack thereof) needs to be evaluated very carefully, as will corporate security policies on access to those services. Strong passwords need to exist not only on the service access, but also on the accounts that have access to the service. Ideally, the service provider should support Multi-Factor Authentication and federated identity and authentication for higher identity assurance by corporate clients. And encryption of sensitive documents and data is a must. Cloud service providers need to understand the implications of entering the enterprise market, and that includes deploying enterprise-grade identity management and security technology.

Unfortunately this event will sow doubts in the minds of those that are considering using cloud-based services. Which is why we have to work hard to define the standards cloud services need to live up to. As Michael Arrington so bluntly put it:

It’s not our fault that Google has a ridiculously easy way to get access to accounts via their password recovery question. It’s not our fault that Twitter stored all of these documents and sensitive information in the cloud and had easy-to-guess passwords and recovery questions.

That is quite plainly an unacceptable state of affairs.

Tags: Cloud Computing, OAAM, Oracle_IDM, Password Management, Password Recovery Techniques

My tween daughter was entering some sort of online popularity contest. It involved registering yourself as a contestant online with your email address, and then verifying your entry by clicking on a link in a verification email you would receive. I saw my daughter on the site for what I thought was much longer than needed, and then noticed her furiously logging in and out of multiple email accounts.

“How many email accounts do you have?” I asked.

“Oh, I only have 2, but these are the email accounts of my friends. I’m registering them and then confirming their entry for them”.

“Your friends gave you the password for their email accounts?” I asked, horrified.

“Oh yeah! Some of them haven’t used their email in years. We’re all on facebook”.

The implications of this kind of behavior from the future citizens of the web is staggering, to say the least.

Tags: Password Management

The F.B.I. said that the younger Mr. Kernell allegedly hacked into the account in mid-September by resetting Gov. Palin’s password.

I obviously don’t know the specifics of how the F.B.I. says the password was reset. But for the sake of our discussion, let’s assume that the email system relied on a typical challenge response mechanism (currently the norm in most free email systems). The hacker obviously didn’t know the password, but was able to reset the password to something of his/her choosing by successfully answering the challenge questions. In the age of Google, how hard is it to find out the the first school, the first car, the mother’s maiden name or the pets name of a famous public personality like Sarah Palin?

As Bob Blakely likes to point out, there are no secrets any more therefore any system that relies on secrets is inherently flawed.

In a completely separate conversation, a colleague of mine sent me the following thought:

All the banks and merchants I do business with online have been increasing their level of security, especially with password complexity requirements.  Historically I have limited all my passwords down to 3 based on the type of site so I had no need to write them down.  Now because of all the different password complexity requirements, especially the password history requirement, I can no longer do that…. so I’m now forced to write them down

In some sick way, more security by merchants is now leading to worse security for me, the user.  I’m forced back to the sticky note.

From the Good News/Bad News Department

The bad news in all this is that we seem to be going through a phase where additional mechanisms introduced to secure the systems in a user-friendly manner have actually exacerbated the problem because they rely on flawed assumptions. The above issues are clear illustrations of this. The mechanisms deployed (challenge response, password complexity requirements) would have been fine on their own for the system they are meant to protect. But these solutions did not anticipate how they would be impacted by the reality of their users online environment. The aggregation of multiple such systems for a user actually ends up degrading the effectiveness of these solutions, to the point where they end up becoming liabilities instead.

The good news is that new technologies and solutions are emerging that (hopefully) will address these problems. OpenID and Information Cards aim to rid us of the multiple password problem by promising a world of reduced sign-on built on trust. Identity assurance technologies (like the ones in Oracle’s Identity Assurance Partner Alliance) provide safer, more reliable means to verify the interacting parties identity than traditional challenge response mechanisms, thus preventing the kind of attacks described above.

So better days are coming. The real challenge ahead of us is getting all involved parties (consumers, online enterprises, vendors) educated on how these solutions can be used to make our online lives more secure.

Tags: Identity Assurance, Password Management, User-Centric Identity

Both these products attempt to solve a very interesting problem – providing controlled, audited access to passwords for highly privileged administrator accounts. Also referred to as service accounts, these types of accounts have been a problem in the IAM space for a long time. They usually do not belong to one person, though there is typically one administrator who “owns” the account. These accounts are often shared between different users, making it difficult to track who actually used the account when they logged into the system (a compliance nightmare). They are also used in application integration scenarios, making them especially critical to an enterprise’s complex infrastructure.

While a tool like OIM can be used to manage the lifecycle of these accounts, a tool like EPV can step in to provide a lot of help in the runtime usage of these accounts. The basic idea is simple: Any time a user wants to log in using one of these accounts, they obtain the account password from EPV (check out the password). They use that password to log in, and after finishing their work, they let EPV know that they are done using the account (in effect, checking in the password).

This simple methodology allows EPV to do some interesting things. Because of the need to check in and check out passwords, EPV makes sure that only one person is using the privileged account at any time, and is able to track who was logging in using that account at any given time – thereby solving the all important audit issues associated with such accounts. EPV is also able to then layer a lifecycle process around that password, changing it (through a connector mechanism) to a new, randomly generated value after it has been used (checked out and back in). This prevents any user from logging back into the system using that same password at a later time. In effect, it makes sure that all passwords used by anyone to log into a privileged account are random, one time passwords.

While the overhead of the password lifecycle could prove burdensome in certain usage scenarios for privileged accounts, it is not really a problem in the vast majority of use cases involving UNIX root accounts, DBA accounts and Windows Administrator accounts

You can learn more about Oracle and Cyber-Ark’s collaboration here.

Tags: Burton Catalyst Conference, BurtonGroupCatalyst07, Cyber-Ark, Oracle Identity Management, Password Management, Privileged Account Management

About changing the passcode, the owner said “Oh yeah. I’ve change it twice since then. I’m paranoid now. I’ll probably do it again tonight.”

Talk about the need for complex passwords and privileged account management.

Tags: Password Complexity, Password Management, Privileged Account Management

Another password study in November looked at 200 corporate employee passwords: 20 percent letters only, 78 percent alphanumeric, 2.1 percent with non-alphanumeric characters, and a 7.8-character average length. Better than 15 years ago, but not as good as MySpace users. Kids really are the future.

Makes you think, doesn’t it? Why is it that corporate passwords are easier than the passwords teens are using to protect their MySpace accounts? Does it point to the perceived value of these accounts to their owners, the lack of a sense of ownership, or the same old issue of “too many passwords”?

It would be interesting to see if there is a similar study on the complexity of SSO passwords. Let me know if you happen to come across one.

Tags: Password Complexity, Password Management