[ISN] Secure SSO: Dream On?

Forwarded From: phreak moi <hackerelite@deathsdoor.com>

http://www.infosecuritymag.com/sept/feature.htm
Secure SSO: Dream On?
BY FRED L. TRICKEY

A maturing technology, single sign-on (SSO) may signal the demise of the
"PC sunflower." But first the kinks have to be worked out. 

As the corporate enterprise moves from a mainframe to a multiplatform,
distributed computing environment, sysadmins and end-users alike must
grapple with a host of access and authentication challenges…and problems.
Solving these problems is what most enterprises hope to gain from an SSO
solution. However, so far the challenges have proved more durable than the
solutions. 

A Complicated Picture

With the deployment of LANs and shared servers in separate parts of the
enterprise, and with the shift from massive mainframe applications to more
flexible client/server technology, today’s business user works in an
increasingly complex environment. Very few users today can access all of
the applications and data they need on a single corporate mainframe or
central computer. In a typical workday, an individual may require access
to applications and/or data residing on many platforms: Windows NT
servers, various UNIX systems, midranges and local or central NetWare or
AppleTalk servers, to name a few. And in spite of many early obituaries,
IBM S/390 mainframes and other "big iron" has not rolled out the door of

most data centers. Legacy systems still make up a significant portion of
the portfolio, many now "front-ended" with C/S applications to provide
additional desktop functionality. 

Complicating the picture is the growing use of Internet/intranet
technology. As recently as five years ago, most commercial enterprises
were not connected to the Internet, except in a very limited manner. But
rare is the company today that is not connected to the Internet and the
Web. The increasing deployment of intranet technology means that the
client-side point-of-entry to some applications is an Internet browser,
and extranet applications extend the need for secure authentication and
authorization services beyond the perimeter of the enterprise network. 

Authentication Breakdown

What does SSO really mean? A quick look at some of the problems of
distributed computing will help reveal a working definition. 

Few IT managers, network administrators and security practitioners today
would debate the need for single sign-on, and the end-user community isn’t
debating it—they’re demanding it. The typical user needs access to many
applications, which may reside in whole or in part on several computers,
including the desktop workstation itself. The guiding principle of
distributed computing is that all of this should be transparent to the
user.  Where this goal often breaks down is at the point of
authentication. 

Ironically, the need for SSO stems from the fact that information security
practitioners have done their jobs too well over the years. We have
hammered into developers’ heads that we need identification,
authentication and authorization functions, and they’ve responded by
building them into every platform and application. The result is a wide
variety of logon protocols, ID structures and password-control mechanisms.
To change from one information system to another, the end-user is forced
to reauthenticate multiple times with different IDs and passwords. 

Average business users view this process not as security, but as
interference—as an unnecessary barrier between them and the information
they need to do their jobs. If forced to remember multiple IDs and
passwords, users will write them down on a list or sticky notes posted
near (or on)  the PC monitor. The knowledgeable user may script different
logons behind function keys, but the passwords are usually in cleartext.
Users will inevitably use the ID/Password combination for one platform or
application to try to get into another, resulting in lockouts and the need
for Help Desk intervention. 

For system and security administrators, this profusion of authentication
points is nothing short of a nightmare. Enrolling a new user means
creating IDs or accounts, with appropriate passwords, in multiple systems
and access control lists—with audit trails of approval and authorization
at each of them. Changing an individual’s access profile to reflect an
internal transfer or change of job function may require new
administration, de-administration or re-administration by different
administrators in different systems. Producing a list of all employees
with access to a specific system may still be straightforward, but showing
all of the accesses for a given user requires querying multiple databases
and concatenating the results—an almost impossible task given different
administration standards. 

The related needs of end-users and system and network administrators give
us one definition for SSO: An enterprise-wide method of identification and
authorization that (a) can be administered across the enterprise in a
consistent manner, and (b) permits the user to access in a single,
transparent manner all information systems to which he or she is
authorized. Infosec practitioners, of course, know that this is only part
of the solution.  For a definition of SSO as one ID and
password—maintained in one enterprise authentication database—presents its
own set of security problems. 

The Cornerstones of SSO

While new techniques and tools make SSO an ever-more attainable goal, the
real challenges involve implementation and security. There are four
components of a complete SSO solution, two of them basic to the above
definition, one essential from a security perspective, and one desirable
for security but not yet easily achieved (see box). 

The primary function of most SSO systems is identification and
authentication (I&A)—that is, verification that the user is who he says he
is, and verification that he is approved to access a particular network or
application. A few products now incorporate business-rule authorization
(which specifies what the user can do once he gets access). However, in
most SSO systems the authorization function remains at the application
itself. 

Early Solutions

The earliest forms of SSO were Kerberos and PC-scripting solutions that
grew out of security products for the workstation. Kerberos, the first of
the token- or credential-based authentication methods, was developed at
MIT as part of Project Athena. The core of DCE security services, Kerberos
replaced dumb terminals with intelligent workstations, enabled
client/server application development and customized what is presented to
the individual. 

While fully implemented Kerberos provides a means of secure logon to a
central authentication server, its application to SSO is problematic.  The
advantage of Kerberos is that it is password-based. Since the passwords
never actually traverse the network, it provides excellent protection
against capture-and-replay and man-in-the-middle attacks. 

However, in today’s distributed computing environment, implementation of a
ticket- or credentials-based system can be problematic. For Kerberos to be
effective today, all desktop clients (including browsers for
intranet/extranet applications) have to be "Kerberized"—that is, given a
link to a Kerberos authentication request ("kinit"). Moreover, all target
systems and applications must be able to accept the ticket instead of a
traditional ID/password logon. 

Other early SSO solutions were implemented entirely at the workstation.  A
local security system prompted the user for ID and password, then
displayed a custom menu or GUI that listed the applications the user was
allowed to access. When the user selected one, the client used a stored
script to send the ID/password logon to the target system in the format it
expected. 

The advantage to these systems is that they required minimal retrofitting
of existing applications; logons at the server or mainframe end looked the
same as they always had. However, early SSO solutions also had a number of
disadvantages: users were tied to one desktop; security was placed at the
PC, arguably the weakest point in the network; the scripts were vulnerable
to modification by users wanting to grant additional accesses;  and
back-door logons to applications were possible by bypassing desktop
security. In addition, any change to the logon protocol for an existing
application required maintenance of scripts at every affected workstation.

Networked-Based SSO

Most of today’s SSO products rely on a network-based single authentication
service. At the beginning of the session, the user authenticates to that
service, then requests access to individual systems or applications. The
authentication server enables the logon, either by a scripted shadow logon
or by presentation of Kerberos-type credentials (or tokens). Depending on
the underlying methodology, existing applications may or may not need
retrofitting. Also, client software must be distributed to all
workstations. Unlike earlier solutions, changes to an individual’s access
profiles or system-wide changes to services can be centrally administered. 

Note, however, that these improvements only solve the user’s problem. He
or she can now log on once to the authentication client, with the
expectation that the authentication server will complete the connection to
the application. However, sysadmins must still administer multiple
authentication/authorization tables and databases at the target systems
and the central authentication server. To reduce administration time, SSO
products are increasingly offered as part of enterprise-wide system and
security administration products to facilitate changes across all
applications and platforms. 

Threats to Information Security

SSO poses at least three immediate security concerns: 

1. The ID and password become a "key to the kingdom." If the means of
authentication is still an individual ID and reusable password, compromise
now means access to everything to which the user is authorized. In today’s
world of increasingly networked and cross-boundary access, integration of
enhanced authentication methodology will become more and more necessary.
At a very minimum, the SSO solution should ensure encryption of logon
sessions and passwords whenever they are transmitted on the network. In
addition, robust password format and change requirements should be
implemented along with SSO. 

2. A central data repository of IDs, passwords and accesses offers
attackers a single, consolidated target. Administrators dream about one
access security database in which all additions, changes and deletions can
be made—and from which all access information can be logged, reviewed and
reported. The problem is, intruders dream about the same thing. If they
can crack that one database, they can do anything anyone in the system can
do, or they can add and remove accesses at will. Any central repository of
authentication data must be robustly encrypted and firewall protected. 
Administrative access to it must be limited to essential, authorized
individuals. 

3. A single authentication server/service equals a single point of
failure. If an intruder wants to completely bring down your network, he
doesn’t even have to crack the system; he merely has to crash it. If it
does crash, whether by malicious attack or system failure, no one can log
on at all, including the very administrators who are expected to fix the
problem. Any central authentication service must be mirrored or replicated
to provide continuous availability. Critical system administrators and
support personnel should retain back-door logon capability to key systems
even in the absence of the central authentication service. 

Other security concerns must also be considered before you can place all
authentication trust in an SSO solution: Does your security policy include
strong password controls and enforced change at regular intervals? Do you
require re-authentication for some secure functions or transactions
exceeding, say, a certain dollar amount? Do you have time-out controls in
place requiring re-login after a defined period of inactivity? 

What about logs, alarms and lockouts? How are invalid login attempts
detected, reported and handled? Are sessions or IDs merely suspended for
some period of time, or are they locked out so that Help Desk intervention
is required? Are these policies and controls consistent across platforms
and applications? 

Other Potholes on the Road to SSO

>From four or five vendors in the early 1990s, the SSO field has grown
rapidly, to the point where as many as 30 or more vendors offer what they
represent as SSO products (see sidebar). Despite this growth, successful
implementations of true SSO in large environments are extremely rare. 

Until recently, the two key impediments to success have been scalability
and the mix of platforms supported. If you are looking for a solution for
a few hundred users and a limited number of applications in a Windows,
WinNT and UNIX environment on an IPX or TCP/IP network, there are plenty
of solutions available today. Support for other platforms and operating
systems—such as OS/2, VMS, AS/400 and MVS/VM or other mainframe
systems—has been slower in coming. Many of the vendors have announced
plans for agents on other platforms, but exactly which of those interfaces
will get written and deployed will depend on market demand. 

One solution to the cross-platform issue would be an industry-standard
API, such as GSSAPI (the Generic Security Services API), which would
enable local or third-party interfaces to less-common platforms not
supported by major SSO products. Some of the vendors are starting to
provide API "hooks," but many of these have been proprietary. As in other
aspects of distributed computing, many SSO vendors are not eagerly
supporting open-standard interoperability. 

Since many of the solutions on the market today run on server platforms or
require complex cross-platform administration and synchronization,
scalability is often a limiting factor. How many platforms, applications
and users are you planning to bring into the SSO tent? An encouraging
trend is increasing vendor support for X.500 standards and LDAP to extend
the number of users that can be maintained without unacceptable increases
in administration resources. 

TCO and ROI

Perhaps the biggest concerns for IT and corporate management are total
cost of ownership (TCO) and return on investment (ROI). An SSO
implementation in any large installation is an enterprise-level project,
and a big one at that, equivalent to other enterprise projects such as SAP
or PeopleSoft conversions. 

While SSO products from the major vendors are enterprise solutions, they
are far from cheap in and of themselves. Published prices (where
available) are in the $50-$150 per seat range, with additional costs in
the thousands for central server applications. Some solutions come bundled
with other products, which can drive the initial investment even higher.
It must be said, however, that at this point in the development of the SSO
product sector, almost all of the vendors will negotiate steep discounts
for specific contracts. 

But the cost of the product is only part of the TCO. Depending on the
platform for the server itself, some capital investment may be required. 
Older individual desktop workstations may need to be upgraded or replaced
to support client-side requirements. And don’t forget about training
costs—not only for administrators and Help Desk staff, but for end-users
who need to learn new logon procedures. 

Retrofitting of front-ending legacy applications to accommodate new logon
protocols can turn into a major expense. The cost of remediating Year 2000
problems in older applications is a good example of the expense involved
in massive code maintenance across the portfolio in a compressed time
frame. 

Most organizations already have a sizable investment in existing security
and authentication software and databases. Unless the SSO solution can
leverage that investment, corporate management will see abandoning it as
another cost of implementation. Can the product use existing databases, or
is it feasible to convert them? If not, factor in the cost of
re-administering all existing principals. 

ROI may be harder to quantify than implementation costs and TCO. If an SSO
implementation is successfully made across the board, it follows that
ongoing user administration costs should decrease. Studies have shown that
60 to 70 percent of Help Desk calls are password-related, and it’s logical
to assume that a large percentage of those arise from problems with
multiple IDs and passwords. 

Other expected benefits of SSO are even harder to quantify. Easier access
to all information should increase user productivity while decreasing
frustration. Ease of administration should do the same for sysadmins. If
planned carefully, SSO implementation can help administrators standardize
ID and password policies throughout the enterprise and apply
authentication security policies consistently. 

Can We Get There From Here? 

To date there is no "magic bullet" SSO solution on the market, and there
is not likely to be one soon. The good news is that the questions about
SSO have changed from "Do we need to do this?" and "Can we do this?" to
"How are we going to do this, and when?" Moreover, the development of
mature support technologies—such as directory services, practical
encryption and a PKI to support digital certificates—improves the chances
of simultaneously achieving true SSO and improving security. Deciding how
and where these technologies fit into your enterprise requires careful
planning and a thoughtful implementation strategy (see sidebar). 

In the past decade, dozens of products have emerged. Many of those,
however, proved too limited or unworkable, and quickly disappeared. Today,
there are 10 to 15 major players in the game, including Schuman, PassGo
Technologies (formerly CKS), HP, Sun, Memco, Security Dynamics, Computer
Associates and IBM, among others. The GartnerGroup and other industry
analysts believe that SSO is one sector of the security product market
that will continue to mature into the first decade of the 21st century.

SSO is not and may never be a one-size-fits-all solution. Every
organization’s platform and application mix is different, and the
complexity of this mix will continue to increase as new technologies arise
and make their way into the market. The need for SSO is no longer in
question. Achieving it will require the continued cooperation of vendors
and their customers. Can we get there? I think so, and so do a lot of
vendors, or they wouldn’t be playing. 

Fred Trickey is information security officer for Administrative
Information Services at Columbia University in New York City. He is a
frequent author and speaker on SSO. 



-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]