[ISN] Secure SSO: Dream On?

From: mea culpa (jerichot_private)
Date: Thu Oct 15 1998 - 02:08:04 PDT

  • Next message: mea culpa: "[ISN] New Defence Computer Keeps Hackers Out and Secret"

    Forwarded From: phreak moi <hackerelitet_private>
    Secure SSO: Dream On?
    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
    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
    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
    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
    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
    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
    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. 
    Subscribe: mail majordomot_private with "subscribe isn".
    Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]

    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:07:44 PDT