Authentication in Modern Computing Environments - PowerPoint PPT Presentation


PPT – Authentication in Modern Computing Environments PowerPoint presentation | free to view - id: 12f5d0-Y2Y4Z


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Authentication in Modern Computing Environments


We assume the system tries to prevent impersonation with some high probability. ... Prevention: Impersonation (by dishonest parties) has low probability from basic ... – PowerPoint PPT presentation

Number of Views:58
Avg rating:3.0/5.0
Slides: 54
Provided by: bgr81


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Authentication in Modern Computing Environments

Authentication in Modern Computing Environments
  • Moti Yung, Columbia University

  • We have been very successful in Cryptography in
    designing authentication
  • Kerberos building on the NS model
  • IPSEC building on various authentication protocol
    works (I had some contributions in Crypto 90
  • SSL/TLS (I had some contributions suggesting the
    server only public key model in Crypto 85)

User Authentication starts at the User
  • While, IPSEC, SSL/TLS, etc. are major
    authentication tools, in reality, user
    authentication starts at the user level (web
    computing, user sign-on, etc.). Thus, PASSWORD is
    the most prevalent tool.
  • Many issues in authentication are open and simple
    concepts have been left out and ignore
    advancements in computing environments.
  • Phishing for example, exploits the look-alike of
    a phishing site and original bank site (uses
    social engineering).

The Three Traditional Factors Evidence in
  • Something you know
  • Password / PIN
  • Knowledge-based authentication Answer
  • Something you have
  • One-time password token
  • Smart card / USB token Signature/ mobile phone
  • Something you are / can do
  • Biometrics Fingerprints, voice

  • All the factors are bilateral (usersystem)
  • Observe No other parties are involved.. !!!!
  • But in modern computing environment the user is
    rarely alone (user and PC). There is Internet of
    people and machines around!
  • Fundamental Issue Can we use this fact?

What we Claim
  • The 3-factor is based on bilateral relationships
    typical of time-sharing machines
  • In modern Internet time we can exploit other
    computing devices and users in designing factors.

From FFIEC 2005 Guidelines
  • Regarding user authentication
  • "The agencies consider single-factor
    authentication, as the only control mechanism, to
    be inadequate for high-risk transactions
    involving access to customer information or the
    movement of funds to other parties.

? Password Not Enough
  • US Government asked for compliance by year-end
  • US banks were required to enhance one-factor

Authentication in real life comes in many
shapes and forms
  • User Type (enterprise employee, client)
    flexibility, usability
  • System Setting (internal, open commerce, Internet
  • Type of Action (Financial/ non-financial/
    Financial value)
  • Parties Trust relationships I am not even
    talking about two-way auth., phishing, etc.

  • Most authentication issues are a result of (1)
    poor computing and networking infrastructure that
    has no security (2) ultimate solutions are
    costly (3) usability and business needs are not
    necessarily security-friendly (4) financial
    transactions are controlled by risk management
    not elimination of all fraud (5) users are not
    the most trusted entity.

User Authentication Model
Auth. Factors
Users Devices
  • Forward Authentication Steps
  • User and Users Devices present Evidence to
    Agent demonstrating possession of Authentication
  • Agent conveys Evidence to Resource in
    Authentication Protocol

Variations on the Model
  • Local authentication User authenticates directly
    to resource, without agent
  • e.g. Log into PC Unlock smart card
  • Authentication server User authenticates once
    to authentication server, which relays ticket or
    authentication assertion to resource
  • e.g. Kerberos Identity providers
  • Validation server Resource relies on separate
    validation server for part or all of
  • e.g. Credential federation

Describing an Authentication Mechanism
  • An authentication mechanism is a ceremony
  • Selected authentication factors
  • Particular evidence about those factors and a
  • Specific protocol for conveying the evidence

Ceremony by Carl Ellison / Jesse Walker
protocol model involving human users, their
systems, machines, etc. .
In This Talk
  • I will cover two scenarios
  • User of on-line banking with no special
    authentication device (no smartcard, usb token,
  • User in an organization with a separate hardware
    token that lost/ forgot the token

Casual User a client of a bank
  • Financial Institutes have consumer who engage in
  • Consumer usage of hardware tokens/ smartcards in
    their many banks is a problem (in the US market
    and others, less of a problem in Asia)
  • Not all transactions need high level of

  • Many ways to authenticate the
  • users computing environment,
  • user, knowledge of the user
  • User mobile device, etc.
  • Users computer IP address/ A cookie in browser
    as examples
  • If not the usual IP address then extra auth call
    the users mobile phone, or ask him from a list
    of questions.

This means
  • If a user gave away his/ her usual credentials
    like password, account number and all details to
    a Phishing email attack in an attackers Phishing
  • Then Still, the security is not lost for
    off-line Phishers (only man in the middle
    remains and needs more efforts)

  • Increase Authentication Factors (using the
    computing environment, knowledge about user) for
    flexibility and usability and minimizing extra
    efforts of consumers in particular no need for
    hardware token devices etc. USE PASSIVE FACTORS
    of the environment
  • Now collecting credentials by faked sites
    (regular phishing) may not be enough for
    attackers and they will attack elsewhere...

Second Idea
  • Connect authentication method to risk-value of
    the transaction based on model of fraud (adaptive
    authentication). Use more authentication factors
    as needed.
  • This will balance the needs of authentication
    against usability and will make reactive
    authentication based on risk level as the bank
    manages it.

Possible Approach I
  • Risk Assessment Tool to
  • Monitor Transactions
  • Keep track of bad transaction
  • Run a model of transactions performed by
    fraudster (from various sources) and learn
    their behavior as in anti-fraud systems in general

Possible Approach II
  • Authentication Tool
  • Assess a given transaction against model and
    determine level of risk
  • Based on risk decide let transaction go on or
    invoke extra authentication methods
  • Overseeing Tool
  • Coordinate actions across different locations,
    from different sources (global effort)

Overall secure the user
  • Based on PC device and user profile, assesses
    risk of all transactions and invokes additional
    authentication for risky transactions. Invisible
    to majority of users most of the time
  • Above is increased by action based on learned
    fraud pattern.
  • This tools and methods are employed in industry
    (RSA is a leader in this space)

What is achieved
  • New methods to assess risk in transactions
  • It is working in a world of active and adaptive
  • It requires constant learning of model of
    attacks/ fraud (even across various banks)
  • Integration of credential methods and risk based
    authentication/ protection is an adaptive
    solution that can be merged with risk management

First Scenario Morale
  • Exploit users machines as factors
  • Have graded authentication levels taking into
    account risk vs. applicability/usability

Second Scenario
  • User in an organization a company where users
    are in groups, and there is well defined
    relationships among users (organizational chart).
    Based on paper published in ACMs CCS 2006

Primary vs. Secondary Methods
  • Credentials or credential processing unit may not
    be available
  • - our motivating example user forgets
    her authentication token, or the biometrics
    reader is out of service
  • Users need an a backup alternative to log into
    the machine productivity and usability may be
    more important than security alone!

Backup Methods
  • Common Alternatives
  • - E-mail (the security relies on email security
    an having an alternative account)
  • - Life questions (security in answer entropy,
    over time degradation)
  • - In an enterprise call a help-desk (social
    engineering backdoor) typically the user and the
    help-desk operator do not know each other

Social Relationships and Authentication
  • Break also here the bilateral constraint at the
    very basic factor level!
  • Relying on Somebody You Know isan age-old
    mechanism for humanity (people used introduction
    letters in old times), a relatively new tool for
    user authentication .

  • The notion has been used to rely on other
    credentials based on human relationships
  • - Credentials are trusted (in PGP SPKI/SDSI
    PKIs (relying on web of trust), Trust Management
    Systems and reputation systems based on social
  • - Here How to employ the notion as a factor
    by itself (formalize the notion and employ in

Steps I
  • We Formalize a Model for claiming correctness and
    security of authentication ceremonies, based on
    simple probabilistic assumptions about the
    ability of Entities to present Factors. The model
    use simple probabilistic assertions
  • It has helped in verifying and defining the
    goals, and reviewing the design of the protocol
    and assumptions about components

Steps II
  • Our goal was exploiting social relationship in a
    simple, usable way, so we designed and
    implemented (assuming formal properties of
    communication channels)
  • We then look at systems and attack variations
    beyond the formal model, to assure the factor has
    right properties for deployment in an extended
    systems setting

Basic Idea Voucher Systems
  • Users authenticate themselves to the system via a
    ceremony session where they simply present their
  • -- Example User presents password and, for
    example, a token-code the one-time value for
    evidence that his token (device) outputs for the
    session but can also be a signature from his USB

Basic Idea Voucher Systems (ii)
  • If a user does not have his token (device), then
    there are pre-assigned group of other users who
    may vouch for that user. Namely, there is an
    alternative ceremony by which a user contacts a
    helper who interacts with the system and aid
    the user in its authentication.

Define properties
  • Correctness and Security properties will be
    derived from differences between the probability
    of the correct claiming by presenting a factor
    X(x) and that of an impersonation attempt,
    namely X(y), where y is not x.
  • Correctness defines the fact that a honest entity
    can claim its own identity at all times with very
    high probability (1-epsilon)

Security Properties
  • We assume the system tries to prevent
    impersonation with some high probability.
  • We also assume independent logging/ audit trails
    (not under the user control) and thus detection
    of small probability bad events is possible.

The properties
  • Formalizing the events, probabilities,
    interactions, system components and ceremony
    actions we now realized that Security has to do
    with two properties
  • Prevention Impersonation (by dishonest parties)
    has low probability from basic assumptions about
    factors and success of events.
  • Detection If the low probability event do occur,
    the log reveals it if checked w.v.h. probability.

Voucher System
  • We have users presenting passwords and
    token-codes as the basic factors in their primary
    authentication sessions
  • If token device is not available, we allow users
    to get helped by other users vouching for them
  • (I will not further use the formal notation, if
    interested see the paper)

Voucher System Enrollment
  • For a vouching to take place, the helper Harry
    has to establish relationships with the user
    Alice, thus there is an enrollment process where
    Harry meets Alice. and the mechanisms/ policy
    by which help will be asked are established as
    well (i.e., Alice may call Harry from her office
    phone or mobile phone).

  • Which users can help whom is a system policy (in
    an enterprise it can use the organizational chart
    to determine the relation).
  • Users are carefully notified of their
    responsibilities (e.g., getting an independent
    email from the system) and the policy regarding
    vouching e.g., You must identify by phone the
    voice of the user asking for help and verify the
    caller id..
  • Policy is driven by probability of identification

Voucher System Ceremony
  • 1. Alice Contacts Harry out-of-band call, say,
    asking for help
  • 2. Harry authenticates Alice verifying her
    identity (system must assure the method gives
    high enough probability p1)
  • 3. Harry authenticates to the System Using a
    specific and separate authentication session
    where he is designated as a helper.

  • 4. Harry obtains a Vouch-code the system
    verifies that Harry and Alice are indeed a
    designated helper-user pair, if so a user
    specific large enough value is given as a
    vouch-code (so it is hard to guess, only with a
    small probability p2)
  • 5. Vouch-code is delivered to Alice
  • 6. Alice enters vouch-code It is delivered to
    the system in a session from Alices own

Voucher System (cont.)
  • 7. System authenticates Alice Checks the factors
    (e.g., password), and checks the vouch-code
    against a database of recently issued codes.
  • 8. Alice chooses Temporary Password If step 7 is
    successful the system accepts from Alice a
    temporary password, to be useful for the day, say
    (this neutralizes the fact that Harry knows the
    vouch-code, and makes it easier for Alice to sign
    on during the day based on memorizable value).

  • 9. Logging Events are audited (audit is
    available and under the systems control) and
    notifications are sent to involved parties.

What is achieved
  • We show correctness
  • We show Security (low probability of
    impersonation based on basic probability of
    getting the token code, vouch-code, and
    password), considering all attacks we extracted
    from the system and its structure --
    Outsider, --Unregistered Helper, --Helper against
    User, and --User against Helper
  • We show detection of all bad (low prob.) events
    in the logs.

  • The formal tools were used to reflect carefully
    on requirements, assumptions, needs and design
    decisions (interactive design and analysis,
    moving between protocol and claims). The final
    claims of properties validates the design under
    the assumptions (see the paper)

Further Pragmatic Considerations Beyond the
  • Always in design of systems there is residual
    analysis left due to the gap between the formal
    setting and the deployment setting since the
    model only captures part of the actual setting
    we considered such issues here

Pragmatic Considerations
  • - Investigated pragmatic channels for delivery of
    requests/ codes e.g., how to discourage the
    helper from using the users machine in the
    session! (keyboard-logger on user machine can get
    helpers password!)
  • Social engineering issues e.g., how to design
    the system so that undesirable channels are not
    easy to employ (asking for help over a gmail
    account on something that looks like the users
    real name)

Even Further Voucher Demo
  • Simple Web-based Application
  • Performed also usability study with 12 users.

Second Scenario Morale
  • Exploit multi-user relationships for
  • Have backup methods since authentication is not a
    goal but rather a means.

  • Formally looked at non-bilateral factors of
  • Demonstrated using passive factors of computer,
    mobile phone, etc. and also introduced the notion
    of vouching in user authentication, again
    breaking the strictly bilateral nature of
    authentication factors
  • Designed simple working tools for risk based
    authentication by mixing factors
  • Designed vouching tool for emergencies

Conclusions II
  • Security considerations formally and carefully
    in the model getting what we need to achieve
    (using probability), and further issues in the
    systems setting (where components are not
  • Extensions of both risk-based authentication and
    vouching are possible , e.g., in a vouchcode or
    risk-level mode where user gets restricted
    privileges, richer policy
  • Further exploiting the notions and the tools is
  • Morale Always room to think about new simple yet
    highly effective issues, concepts and solutions
    (non bilateral factors in this case and their
    analysis for a specific factor)

  • As computing environment evolve we cannot and
    should not stick by old paradigms (here that
    there are three basic factors)
  • When looking beyond bilateral relationships there
    are plenty more factors.

Thank you!