Operational Problems with Traditional E-SSO
The core element in every traditional E-SSO product is the concept of a credential database. This may be encoded in different ways and stored on various media but fundamentally it is a set of login ID / password pairs that the E-SSO application will type on behalf of the user when each application prompts for login verification. This data must be available for every user.
- Remote Access and Mobile Devices:
Over time, a traditional E-SSO system will respond to applications expiring passwords by choosing new, random password values, allowing the application to change passwords and storing the random password value for future reference.
With this process in place, over time users lose knowledge of their own passwords and become dependent on the E-SSO system to sign into their applications. This means that users cannot access their applications from devices that are not equipped with the E-SSO software, such as smart phones or even their home PCs.
- Cost to Deploy:
Building and maintaining a database of every login ID and every password on every application can be both costly and time consuming.
- Cost to Reset Passwords:
Login IDs and passwords stored in a traditional E-SSO system are typically encrypted using a key derived from the user's primary network password. When users forget their primary password, they lose this key and can no longer decrypt their application passwords. As a result, password problems may be less frequent with E-SSO, but resolving them is more complicated, time consuming and expensive.
- Security and Availability:
In the event that the password database in a traditional E-SSO system is compromised, every user ID and every password would be exposed.
If the password database suffers an outage, every user would be locked out of every application.
In addition, traditional SSO systems have to integrate with a variety of subsystems on the user's PC, both to detect when a password prompt is displayed and to inject passwords into input fields. This requires integrations with:
- The login subsystem on 32-bit and 64-bit editions of Windows (XP, Vista, 7, 8, 10, etc.).
- Applications built using native Windows dialogs.
- Applications built using frameworks such as Java AWT or Swing, which appear to the Windows OS as just bitmaps.
- Web applications, rendered using any version of any web browser.
- Unix or Linux applications, rendered in a terminal emulator such as PuTTY or SecureCRT.
- X-Windows applications, rendered in an X Server such as Ming, Cygwin/X, VcXsrv or many others.
- Applications on IBM z/OS mainframes or iSeries midrange servers, rendered in a TN3270 or TN5250 terminal emulator.
- Undoubtedly, others...
Some organizations require integration with other platforms -- MacOSX, Android, iOS and Linux, which significantly expands the scope of the problem.
Each of these components operates totally differently than the others and has its own release cycle. Web browsers such as Chrome and Firefox, in particular, release new versions every 6 weeks or so, which often break backwards compatibility.
The net result of this complexity is that it is quite difficult to maintain compatibility across a variety of applications as various application development frameworks constantly evolve. Customers are impacted in that they are either prevented from upgrading their endpoints (as this would introduce breakage), or having to frequently upgrade their SSO software, or suffering frequent compatibility problems because upgrades to applications cause SSO to stop working.
Some E-SSO vendors try to turn some subset of these problems into competitive advantages, or as a justification for cross-selling other products:
- Some vendors create a mechanism for users to display their
own plaintext passwords, when accessing applications from
non-traditional devices. This is, of course, insecure.
- Citrix uses the remote-availability problem to encourage customers
to migrate their users to Citrix Presentation Manager. If users
access every application by remote control, and the terminal services
servers are equipped with SSO, then the problem goes away (and Citrix
sells more server licenses).
- Most vendors offer some back door, to bypass the credential encryption system with some privileged credential and so to address the problem of expensive password resets. This can create security weaknesses and/or administration headaches.
These operational problems are serious. It is Hitachi ID Systems's opinion that these problems prevent most large enterprises from completing large-scale E-SSO deployments. Instead, pilots and department-scale deployments, which work reasonably well, hit these roadblocks when trying to scale up, and project scope is subsequently curtailed.
Is E-SSO More Secure than Password Synchronization?
Many E-SSO vendors claim that E-SSO is more secure than password synchronization. They reason as follows:
- If passwords are synchronized, then:
- A compromise of one security database will compromise all systems.
- An intruder can make more incorrect password guesses before triggering a lockout, since he can distribute guesses across multiple systems.
- In contrast, in an E-SSO system, every password is different,
so these "vulnerabilities" disappear.
- Using an E-SSO system together with a two-factor authentication system eliminates passwords altogether. This sounds more secure.
These arguments are very weak, however:
- Few, if any, modern password databases are vulnerable to total
- Most systems do not make password hashes available to a would-be attacker.
- Password guessing attacks depend on weak passwords, which are easy to prevent using either built-in policies or an external password management system.
- Most systems do implement an intruder lockout system, which prevent brute-force attack against their public authentication mechanism.
As a result, a compromise of any one security database is quite unlikely. If such a compromise were as easy as claimed, then every corporate network would be under constant and successful attack, which is clearly not the case.
- The argument regarding a higher number of failed authentication
attempts before an intruder lockout is triggered is accurate, but
largely irrelevant. If a user has a strong password (this is easy to
achieve -- see above), does it really matter if an intruder can
try 3, 10 or 100 guesses before being locked out?
Current security best practices generally recommend setting the intruder lockout counter high (on the order of 50 -- 100 failed attempts) anyways. A low count is no substitute for strong passwords and if passwords are strong, there is no harm in setting the counter high, since the password will not be guessed in anything short of billions of guesses.
- It's true -- with either password synchronization or E-SSO, if an
intruder compromises one password, he has compromised all passwords
for the affected user. In the password synchronization case, an
intruder who compromised any of a given user's (victim's) passwords
has compromised them all, since they are the same. In the E-SSO
case, an intruder who has compromised the victim's primary password
has compromised them all: the others can be decrypted using the
primary password and the E-SSO product will obligingly log the
intruder into those systems anyways.
In other words, the only difference between password synchronization and E-SSO in relation to the single password argument is which password must be compromised before all are compromised -- the primary password or any of them. This is not much of an advantage for E-SSO.
- Using stronger authentication technologies sounds good, but the
application passwords are still there -- still encrypted using a
primary key and still used to log into each application. Moreover,
when deploying stronger primary authentication, the method used to
generate or acquire the key which decrypts all the user's application
passwords is often obscure and in some cases is easily compromised.
In other words, strong primary authentication is often accompanied
by weak encryption of sensitive application passwords.