Having assessed many client-server, web and mobile “logon” infrastructures during penetration tests, I am left pondering several industry enigmas.

1. Why are there so few good toolkits and libraries for performing secure logon activities?
2. Why does nearly every application team develop logon as one-offs?
3. Why do so few organizations “sponsor” the development of a common “logon” for their apps?

Excluding a few “platform” capabilities (e.g., .Net), as a whole, most applications end up having to roll-their-own logon. Even when there are “platform” capabilities, development teams often bypass them in full or part and still roll-their-own. Almost always in these “self developed” solutions (or parts) are found the greatest weaknesses.

So why does this keep happening?

When you look at the CIA triad (confidentiality, integrity, availability) Authentication is one of those elements of applications that crosses and exposes all three to corruption. This series is on Authentication and in it I will describe what it takes to have secure Authentication (“Logon”) in modern hybrid applications.

In part 1 (this article) we will tackle describing a common “logon” process that is platform and technology independent. In subsequent parts we will dissect each part of this process, step-by-step and identify two versions of “secure”: good and great. Good represents the least case “secure” version of this process step, and great represents the best secure case.

Let’s get started…

At the coarsest level of description, logon consist of three structural elements:

• Authenticatee
• Authentication pipe
• Authenticator

The process corresponding to these elements similarly is:

1. Authenticatee provides credential factors
2. Authentication pipe routes factors to Authenticator
3. Authenticator provides a authentication token or failure response

Sounds simple doesnt’ it? Well in modern client-server, mobile and web architectures the complexity of these simple elements and steps is pretty high. Which is why we need to understand what it takes in each to secure them effectively.

Why is such a simple set of elements and steps so complex? Let’s review some of the factors that makes them so, and underscore why care needs to be taken in building out a “logon” infrastructure:

1. Multi-technology stacks – More often than not each of these elements and steps involve crossing platform and technology “stack” boundaries. Often more than once.
2. Environment – At the least very little environmental control is available over the Authenticatee side of the world. This opens the doors to snooping, bypass, hijack and other attack activities which make securing that environment difficult.
3. Fragile underlying code bases – Yep, that’s right, let’s admit it as a community once and for all. The speed at which most platforms, infrastructures and applications have been built has far exceeded the quality assurance needed. Anything technology has inherent fragility built in from the sins of the past.
4. Encoding and inputs – The fact there are no clear ways to segregate natural language, code, and other encoding and distinguish them in a fool-proof manner has become a bane of authentication bypass.
5. Standards – Across the elements, technology, etc the various standards are often at odds with each other and with “security” as a whole. Further, implementing some of the standards is often complex and convoluted opening the door for mistakes which leave holes in security.

As you can see there are many complexities that make securing authentication difficult at best, and even more so when you try to roll-your-own each time you build and application. The goal of this series, once again, is to identify the best path through all these at each element and part of the process (and sub-elements and processes as future articles will reveal).

Coming up next  Authentication Part 2: Authenticatee “The Client Login”