Authentication Kypros Ioannou Professor: Elias Athanasopoulos - - PowerPoint PPT Presentation

Authentication

Kypros Ioannou Professor: Elias Athanasopoulos

Passwords (1/3)

A password is weak authentication mechanism. Use Brute Force to find the password. We are using Hashing and Salt to protect the password.

Passwords: Two factors authentication(2/3)

• Require an addition password from the user when log in.

Two factors authentication is a good option to secure an account. Cost and effort to deploy and maintain such a system. Use only by high-value service (e.g. Google). May push the user to put even weaker password because of that.

Passwords: Salt (3/3)

• Salt is string that is been added to the password before we hash it.
• Defeats rainbow tables.
• Precomputed table for reversing cryptographic hash functions.

We are using salt to produce different hash values for the same password.

Weak Passwords

Attack Scenarios

Guess the password. Shoulder-surfing. Use same password for many system services. Attacker install a malware or use phishing attack. Compromise the mechanism for changing password.

Honeywords

A TECHNIQUE IN WHICH IT SETS MULTIPLE POSSIBLE PASSWORDS FOR EACH ACCOUNT. ONLY ONE IS GENUINE. THE OTHERS ARE THE HONEYWORDS.

How it works?

Honeychecker is server that can distinguish which password is the genuine from the honeywords. Honeychecker is a separate hardened computer system that can store secret information. Secretly inform an administrator that someone use a honeyword to log in. May allow access, and inform secretly the attack.

Aim and Protection of Honeychecker

Store the position of the genuine password of each user. The index for each for each user is stored in a table and is encrypted and authenticated under keys stored. Place the computer system and honeychecker in separate administrative domain Use different operating system for the computer system and the honeychecker.

Failover

When the honeychecker failed. Unable to reach the honeychecker. Honeyword is accepted as genuine password. Prevent Denial of Service by let access to the account.

Approach: Setup

Generate for each user distinct passwords. Correct password is called sugarword (k-1) Honeywords. Can generate a tough-nut password which is really strong password and is impossible to invert it hash. Store them on honeychecker

Approach: Login

SETTING OF AN ALARM LETTING LOGIN PROCEED AS USUAL TRACING THE SOURCE OF THE LOGIN CAREFULLY SHUTTING DOWN THAT USER’S ACCOUNT UNTIL THE USERS ESTABLISHES A NEW PASSWORD SHUTTING DOWN THE COMPUTER SYSTEM AND REQUIRING ALL USERS TO ESTABLISH NEW PASSWORDS MONITORING THE NUMBER OF ATTEMPTS OF WRONG PASSWORD

Approach: Change of Password

Update Update the user table. Notify Securely notify the honeychecker for the new index. Set Set the index of the sugarword. Generate Generate the hashes values of each honeywords. Create System need to create another list of honeywords.

Honey Generation

• The Password-change UI is unchanged.

Legacy-UI

• The password change UI is modified to allow for better password/honeyword

generation.

Modified-UI

Legacy-UI: Password Changes

Does not inform the user of honeyword existence Ask again the password for confirmation.

• Chaffing by Tweaking
• tail tweaking
• tweaking digits the last t position that contains digit is change.
• Chaffing with a password model
• Chaffing with “tough nuts”

Chaffing Technique:

Chaffing by tweaking

Syntax No password syntax except from length. Change Change each character with the same type. Set Set position for the characters that will change. Set number of honeywords.

Chaffing by tail tweaking

Split the password to Head and Tail. The value of t for the tails same for all users. By randomly choose tail digits the attacker find it very difficult to find which password is the real.

Chaffing with a password model

Generates honeywords using a probabilistic model of real password. Based on a given list L of thousands or millions of passwords. List may also be available to the adversary. Does not need help from the password.

Password Model-2: Model Syntax

• Depend on the password

Generated using the same syntax as the password.

Decomposed into a sequence of tokens.

Modified-UI Password changes

Take-tail method. The UI change a little bit. The system add the tail(randomly generated).

“Random pick” Honeyword Generation

Generate a list

• f k words.

01

Pick one of them as a password.

02

Set the others as honeywords.

03

Hybrid Generation method

Comparison between honeyword methods

Attack Scenarios

General Password guessing. Target Password guessing. Attacking the honeychecker. Likehood Attack. Denial of Service. Multiple Systems.

General and Target password guessing

Legacy-UI has no good effect preventing common passwords. Modified-UI by putting the extra tail can reduce the chances of finding. An attacker can collect personal information and based on them identify the correct password or guess the password of the user. With chaffing with a password model the attacker can’t use any information. The passwords and honeywords are random.

Attacking the honeychecker

Can attack directly to honeychecker. Can attack the communication between computer system and honeychecker. Need authenticate before update the database. Need to authenticate the queries from the honeychecker.

• Different operating system for both of them.

Possible Solution: Separate computer system and honeychecker in different administrative domain.

Likehood Attack

The attacker want to maximize the chance of getting the correct password. When the Honeyword generator can’t produce all the possible passwords. The attacker can recognize the password that can’t be produce by the generator.

Denial of Service

• If the attacker know the password can then use a honeyword to produce Denial
• f Service.
• Password from tweaking are similar.

Problem with chaffing by tweaking

If the system is very sensitive can force global password reset. Possible solution: Select random honeywords from a large list of possible honeywords.

Multiple Systems

• Both system use honeywords.
• Same password.
• But they different list of honeywords
• Attacker can easily find the password.
• Prevent by: take a tail that the tail for each system will be different.

Intersection Attack

• If two systems use same password.
• On of them doesn’t support honeywords.
• The attacker can find the password easily.

Honeyword-submission Attack

What is SAuth?

Protocol which employs authentication synergy among different services. Sauth is an extension and not a replacement of existing authentications methods. Employ passwords decoys to protect the password of the user that share across services. SAuth operates above SSL.

SAuth Architecture

Protocol Details: Security an Trust

• V service don’t allow some other user to generate the same vouching token

while interacting with V.

Service S trusts that V has indeed authenticated the user If V fails the service S operates alone.

Protocol Details: Activation

We need to connect those services together.

• Use SAuth to authenticate with he/she own account to the voucher service.

Before enabling SAuth someone can access to user account and then:

• Upon registration or enabling SAuth the service that the user want to access

generate an anonymous alias.

• Provide that alias to the vouching service and associate it with the account of the

user.

• Return the alias as part of authentication proof of service S and if the match give

access.

Solution to that problem:

SAuth Association between services

Protocol Details: Authenticity

We assume that the secrecy of the messages is preserved as long as the user agent maintains SSL connections with the two services. Service: Identify the sender service and retrieve the necessary information for verifying the signature. Signed_fields: Specifies which parameters are contain in the signature.

• Each protocol message is required to carry this parameters:
• Service
• Digital Signature
• Signed_fields

Ensure the authenticity of protocol message exchanged.

SAuth: Resetting password

• May be asked a few security question

Without SAuth the user change password by requesting to reset it

• First we go to the vouching service put credential to confirm that we are

actually the user.

• Then we can reset password to the service that we want to be reset.

With SAuth:

Implementation

• Registration
• Authentication

Group the message to two categories: Define the SAuth protocol messages as a set of URIs. Can be applied to any other application-level protocol provided it supports the concept of end-point redirection. The two services will cooperate to provide authentication to one of the two services need to be aware of each other’s endpoints.

Implementation: Registration (1/3)

• Put name, password and select vouching service or domain of a different service.
• Response of service S is redirection to the end-point of voucher service.

User visit target service S:

Implementation: Registration (2/3)

Action set to instruct the vouching service to first authenticate the user (service V) and then associate with account V with an anonymous alias that has been just generated.

Implementation: Registration (3/3)

Service V then redirects the user’s agent back to service S while setting parameter action to signal service S that it should bind the generated alias to the current user’s account (S service). This conveys to S that the alias has been associated with the user’s account on V and it will be part of future vouching authentication process

Implementation: Authentication (1/2)

Visit the service that he wants to access labeled as target S. Enter name and password and also the vouching service V. The target service S then redirect the user’s agent to V while setting the parameter action to signal that a vouching for current user is expected from the remote service

Implementation: Authentication (2/2)

User then present his credentials in an authentication request towards service V.

• Set action parameter to signal that current user has successfully authenticated with some

account, that the associated foreign alias is included in the response.

• Service should verify this vouching response and decide whether the return foreign alias

matches alias bound to the user’s account on S

After successful authentication with V, the service's response to the user agent redirects it to the target service S.

Decoys

Any of the decoys can successfully authenticate the user to the service. Different from the honeywords that don’t allow access. They don’t receive special treatment.

Decoys Generation (1/2)

Identify the context of the passwords Randomly produce tokens that match it.

• No possible way to describe the structure of all decoys by looking a small subset of all the set

Requirement for generate decoys: Random generation may produce password that are unlikely to be chosen by a user.

Decoys Generation (2/2)

Grammatically decomposed and generate new passwords by applying transformations to the core parts of the genuine password. With natural language processing we can tag specific parts of the password. When can’t use NLP and cant identify presence of human language we can apply something similar to chaffing with tweaking.

Security Evaluation

Gb: guessing both passwords in a two entity enhanced. Gs: guessing the second password given that the first is stolen. Gb: decoy set to be small as possible. Gs: decoy set to be large as possible. Ds: all the user that share same passwords for both services.

Security Evaluation Without Decoys (1/2)

Security Evaluation Without Decoys (2/2)

Original design can’t improve the security of the accounts that use the same password SAuth is able to improve the security in the cases where different passwords are employed and there is no site of compromised.

Security Evaluation With Decoys

Introducing K1 and K2 decoys Assuming that there is no overlap between K1 and K2.

Security Evaluation

Thank you