Cloud computing is a technology paradigm shift that is a magnitude equivalent to changes from mainframe computing to client/server and from client/server to web applications. Each historic shift has resulted in a significant decrease in the cost of deploying an application, which has, in turn, resulted in a significant increase in the number of applications available to users.
The cloud is no different. The shift to cloud computing will result in another dramatic increase in the number of applications that users will leverage on a daily basis.
What has not changed in 40 years is that the simple password remains the default authentication mechanism for all applications.
So with more cloud applications, we get more passwords; which means there is an ever-increasing risk of compromised user accounts via malware, phishing, keystroke loggers or plain user laziness.
It is no surprise that the simple password is the Achilles’ heel of cloud security.
Single sign-on (SSO) has generally been considered a viable solution to this password proliferation problem – especially when partnered with a strong, multi-factor authentication capability.
Unfortunately, SSO solutions can come in multiple flavors that are not always what they seem. The SSO gold standard is for cloud applications to implement Tier One SSO, which is standards based, cross-domain authentication. Tier One SSO is based on proven standards that connect a web session to the application, authenticating it back to a central directory that acts as a single place to enforce policies. Standards that are incorporated in Tier One SSO include the Security Assertion Markup Language (SAML) or OpenID.
Much like 20 years ago when the internet standardized on SSL for encryption, and 10 years ago, when enterprise applications standardized on LDAP as an authentication protocol, today’s cloud requires security standards to address scale and avoid proprietary lock-in.
Implementing Tier One SSO based on standards like SAML or OpenID means that a cloud application can rely on an identity provider (e.g., a user’s employer, email provider or even social network) to authenticate the user, rather than maintaining its own password for the user.
Unfortunately, alternate SSO technologies exist for cloud applications that hide the password problem rather than solving it.
Password managers/brokers refer to a set of proprietary technologies designed to address SSO by automating the process of logging into a cloud application. The password manager implements ‘password vaulting’ (also known as password masking), which involves storing all of a user’s passwords on their local computer or in a cloud service. Password vaulting then transparently uses those stored usernames and passwords when that user is presented a log-in screen by a cloud application.
Plainly stated, password vaulting does not eliminate the use of passwords; it just masks the fact that they are being used. It’s like taking Tylenol for sore feet while you are wearing tight shoes. The pain goes away for a while, but you have not actually addressed the underlying problem.
So what are some of the issues that make password vaulting unsuitable for use with cloud applications?
First, and most obvious, is that password vaulting still requires that passwords are stored in every cloud application. All of these cloud applications continue to remain vulnerable to phishing, malware and keystroke logging attacks. A user may choose to re-use their corporate email address and matching corporate password in multiple cloud applications. Now an attacker only needs to break into a cloud application or use malware to successfully steal the user’s corporate credentials.
Once that attacker has a working email address and password, they can attempt to use that credential to authenticate to internal corporate assets, and also to other corporate assets in the cloud. Password vaulting has no ability to protect from that fate.
Alternatively, Tier One SSO with protocols like SAML, where cryptographic tokens are sent instead of passwords, eliminates the need for a cloud application to maintain a password database, and thus eliminates these risks.
Second, password vaulting is a very fragile solution. These solutions use screen-scraping techniques to learn how the log-in page works for every application it supports. If the log-in page changes for any reason, then SSO will fail.
The log-in pages for cloud applications can change for any number of reasons, including:
• Look and feel of the log-in page
• Addition of stronger authentication such as SMS-based one-time passwords
• Addition of CAPTCHA messages
• Addition of interim user-consent pages
• Use of A/B testing
There are generally two basic implementations of password vaulting for cloud applications. The first relies on a browser plug-in to handle the password vaulting automation.
The second relies on a cloud proxy, where a cloud service intermediary handles the password vaulting. This eliminates the need for a browser plug-in but requires changes to DNS for every ‘masked’ application. In addition, the cloud proxy approach requires that the log-in request and all subsequent browser requests to that cloud application pass through the cloud proxy.
Both of these techniques obviously are also much harder to implement when users start to leverage their smartphones and tablets in addition to their laptops. Further complicating matters is that password vaulting does not work when using native mobile applications or other non-browser applications built to call cloud API’s.
The simple password has proven time and again to be a major weakness in cloud security. Technologies such as password vaulting don’t solve the problem, they simply cover it up, hiding the fact that passwords are still being used. To address SSO at cloud scale, IT administrators, security architects and developers must focus their energy on solving the problem with Tier One SSO and secure standards like SAML, rather than implementing Band-Aid solutions like password vaulting.
Patrick Harding brings more than 20 years of experience in software development, networking infrastructure and information security to the role of CTO for Ping Identity, where he is responsible for the company’s technology strategy. Previously, Harding was a vice president and security architect at Fidelity Investments where he was responsible for aligning identity management and security technologies with the strategic goals of the business. An active leader in the identity security space, he is a founding Board Member for the Information Card Foundation, a member of the Cloud Security Alliance Board of Advisors, on the steering committee for OASIS, and actively involved in the Kantara Initiative and Project Concordia. Harding holds a BS in computer science from the University of New South Wales in Sydney, Australia.