Cloud Computing Concern: Security: User Names & Passwords

Does your cloud application require users to sign in? If so, it may mean that you are keeping user identification and password data on your system. That could get you in trouble if somebody gets unauthorized access to your data.

Many stories,  such as the story reported at Wired, have reported that a database full of userids and passwords were hacked and stolen. This is really bad news if it happens to your users because somebody hacked your site. Why?  

Because most users don't have the mental capacity to remember a different userid and password for every single web application they use.

So what do users do? They use a small number of userid and password combinations for all web applications that they use. If somebody gets the userid/password by hacking your system and getting your database, they will probably be able to get to the accounts of those users on other systems. Very bad.

There is, of course, a simpler solution. Outsource your user authentication. Many well-known online services will authenticate users for your web application using protocols such as OpenID or OAuth. Examples include Google, Yahoo, Facebook, LinkedIn, and others. However, these authentication protocols are evolving and different providers use different methods.

The easiest one to use is JanRain Engage. You integrate your software with their system once, and they handle the ever-evolving authentication protocols and integration methods with 25-ish other providers including Google and Facebook. After that, you only have to configure your JanRain integration properties to work with the other providers.

Here is roughly how JanRain works:

1. You place a login button on your web page which directs the user to a JanRain frame offering them a choice of providers.
2. The user selects a provider and clicks the button. That directs the user to a your login page at the provider (e.g. Google).
3. On that page it asks for the user's userid and password for that provider, and it asks the user's permission to share some information about the user's account. The user types in the proper userid/password and grants permission. 
4. When the authentication clears, the provider (e.g. Google) handshakes with JanRain, JanRain then redirects the user to a URL with a unique single-use token. 
5. Your web application parses out the token and makes a secure web services request call to JanRain to request the user's authentication information. Please note that the user's password is not sent by the provider to your web application. The email address is often sent, as is the OpenID token and various other information. And JanRain does not get the password either.
6. Your web application then checks that information with what is in the web application's user database, and if there is a match, the user is considered authenticated, and is logged in.
7. From there, your web application grants the user a login session and gives him access to all pages that require authentication that the user is authorized to see. 

Outsourcing user authentication is a great way for a cloud application producer to gain the benefits of user authentication without getting into the messy business of securely storing passwords. A nice side benefit is that the application does not need "Forgot Password" functionality because that will be done at the authentication provider.   A nice side benefit for the user is that she does not have to remember the userid and password for yet another web application. Using a well-used identity such as Facebook or Google (which is common for a lot of people) means that you .

Some people argue that outsourcing your authentication to JanRain, Google, or Facebook makes your site  look "unprofessional". However, getting your users to authenticate with a well-known authentication provider is more professional, as is providing an authenticated service without needing to store their passwords. Also, users are more likely to register with your site if all they need to do is log in using the credentials of a service that they already use such as Facebook or Google, because they don't have to memorize another userid/password combination.

Some people argue that trusting authentication to other providers won't work if their sites go down. That is true, but your site is almost certainly more likely to go down more often than Google or Facebook.