2015 Dec 18

Building a CAS Server to Help Rid the Web of Passwords

It's getting close to that time of year when we take time to go home and visit family and loved ones at the end of another year. And, when you're a "computer expert" like me, that means one thing:

Trying to sort out the disaster your family has made of their passwords and web-accounts this year.

Simply ask any baby-boomer what the worst part of the internet is? Answer: "too many passwords"

And they're absolutely right. It's not just a baby-boomer problem – it's a problem for all the users that we work so hard to build online services for.

The Authentication Problem

Passwords are painful for users and a common failure point for websites, but they are required.

The web is a public place and like any public place, it will be graffitied. In order to protect our users' content we need to authenticate them, traditionally with passwords.

The trouble with passwords is that there is a 10% chance your password is in this list:

top 20 passwords on the internet in 2015
top 20 passwords from 2015

And passwords like that mean that it's possible for the services we build to be broken into far too easily. Every site which contains useful data for its users has this issue – and it gets worse. What do you do when you have multiple sites that provide services to a related user base? This is exactly the problem that many of our clients find themselves with.

How can we help?

We can't make passwords go away, but what we can do is provide a way to share user data across several sites. This, at least, allows us to have a single password for each user and have a single place for them to login and then share that authentication information across any of the related sites and services that we provide online. Then it's easier to encourage our users to use better passwords to protect their data. In addition, we can provide a centralized place for them to manage, update and maintain their profile.

You're probably already familiar with this if you employ any cloud services. Typically larger service providers like Google, Apple, Microsoft and Yahoo! allow you to login to one service, like Mail, then allow you access other services, such as Photos, because you already logged in to read your Mail.

This is called: Centralized Authentication

Centralized Authentication — (CAS)

Recently we had a project with a need for multiple site coordinated authentication, so we put our heads down and built a CAS server. We also required that this server authenticate against a user-table with bcrypt-encoded passwords. What is CAS?

The Central_Authentication_Service - (CAS) is a single sign on protocol for the web.

Why would we do this? The answer is simple: to save our users from remembering more passwords. By using this CAS service we will be able to provide a user the ability to log in once and access a large variety of sites and services without having to log in again. For instance, they might be able to:

  1. go to their Drupal site and update content for an upcoming blog,

  2. manage a Mail Campaign for upcoming notification to their members,

  3. access an intranet portal where they can see all their internal documentation and accounting information,

  4. track the analytics to see what all of their members are doing across all of their sites, in one central place.

If this sounds awesome, it is. Check out https://wicket.io to learn more about this modern approach to core data management for your organization.

What Does “Centralized Authentication” Mean

  1. Our client presents with an existing user/password database used for their site.

  2. They want to move away from this silo and take advantage of more contemporary distributed services, while still allowing their users authenticated to their site.

  3. We are moving the services from a single existing site to a distributed approach involving multiple sites, better adhering to the Single Responsibility Principle .

What is CAS?

Single Sign-On (SSO) is a mechanism for related websites to securely share authentication information. If more websites took advantage of SSO, then we all would have fewer passwords to remember.

And of course, this can extend further using broader [and older] backing protocols to provide authentication, such as:

  • LDAP – simply logging into your office computer, or

  • OpenID – logging into your cloud-based email

OpenID is an open standard […] that allows users to be authenticated by certain co-operating sites […]. In other words, users can log into multiple unrelated websites without having to register with their information over and over again;

— https://en.wikipedia.org/wiki/OpenID

The Way Single-Sign-On (SSO) Works

The first time a user attempts to access a web page protected by WebAuth, they will be sent to a central login server (weblogin.stanford.edu at Stanford) and prompted to authenticate. Normally, they will be asked for a username and password, although other authentication methods are possible. Once the user has logged in, the weblogin server will send their encrypted identity back to the original web page they were trying to access. Their identity will also be stored in a cookie set by the weblogin server and they will not need to authenticate again until their credentials expire, even if they visit multiple protected web sites.

— http://webauth.stanford.edu

BCrypt for Encryption

For our CAS implementation we had to extend the protocol to interact with existing user/password stores already using bcrypt. Is bcrypt a good choice? - it's better than many alternatives. There is no perfect encryption algorithm, given time and computation these codes can be cracked. But there is a concept of sufficient security. No matter which side of the debate you land on, bcrypt is a still solid choice:

Open-Source CAS implementation using BCrypt

We now have this server up and running acting as the central user-authority for 3 coordinated websites. We have the project up on GitHub:

https://github.com/industrialdev/cas-bcrypt

Feel free to check it out and send us any feedback. Basically the CAS server running now for our projet sitting centrally to the 3 services:

  1. Sitefinity CMS legacy site that we’ve broken services away from.

  2. Drupal site that we created to handle new content and some user tasks.

  3. A preliminary Wicket.io site with some pared-down capabilities to marshal the services.

So this is our first contribution to help some of the users out there rest assured that their content and services are secure on the web, but enjoying the fact that they have 3 less passwords to remember.