Re: public key vs passwd authentication?

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 10/04/03 

Date: Sat, 04 Oct 2003 15:11:23 GMT

Michael Sierchio <kudzu@tenebras.com> writes:
> Here's the thing -- OTPs aren't really a challenge-response
> mechanism. The challenge is entirely predictable, it's the
> original salt and the sequence number. Salt is used only
> to permute the algorithm in the case of dictionary attacks
> against the passphrase.

There have been claims that the sever-side "salt" can also be
different/unique with different servers ... allowing a client to use
the same client-side secret for all servers. Although, in that case,
the client might possibly want to keep a log of all server "salts"
... to guarentee that they are all different.

The vulnerability in the whole OTP scheme with iterative hashes ... is
if any client hash value leaks that is for an iteration less than
currently be used by a server.

the OTP description in the RFC ... has the client with a secret
.... which is combined with something (salt) from the server to form a
kind of password. The idea is that the client can use their same
secret with lots of different servers ... each server providing unique
server salts. The combined client-secret+sever-value is hashed
repeatedly, the secret isn't used as a password ... each hash
iteration is used as a password, just once.

On initialzation, the server provides the server side salt ... and
gets back from the client, the value of the Nth hash. The core of this
is that hashes are one-way functions that can't be reversed.

In the RFC, the description is that the server provides a predictable
challenge, the server-side salt and the count N-1. The client can
have the original client-secret sitting in an encrypted file that is
available by decrypting with a client known passphrase.

Getting the server challenge, the client decrypts the file to obtain
the client-secret (using a client passphrase), combines the
client-secret with the server-side salt, and runs it iteratively thru
the hash function N-1 times. The client then returns the N-1th
iterative hash value as the (unique) response. The server gets the
response, runs the hash function one more time and compares it with
the Nth-iterative hash previously recorded.

If HASH(client response) == recorded hash .... then the server accepts
the client as valid. The server then updates the recorded hash value,
with the n-1 hash value and saves the client's current iterative value
as n-1.

The threat scenario on OTP is to impersonate the server and get the
client to cough up the first iterative hash value (or any iterative
hash value that is lower in sequence than that already being used
between the client and server).

While the original value is dependent on the combination of the
client-side secret and the server-side value .... each OTP is only
actually dependent on the immediately preceeding hash value (as
demonstrated by the mechanism that the server uses to verify the
response). Given that the attacker is able to obtain any ealier hash
value in the sequence ... it never needs to find out the original
client-side secret.

The attack is to impersonate the server and serve up a predictable
challenge to the client with a count of one and the server-side value
(obtained from previous evesdropping). If a server is using the same
server-side value for all clients ... then it only needs to obtain
that value once from a single evesdropping ... and be able to attack
all of that server's clients thru server impersonation ... in each
case spoofing a challenge with a (hash interation) count of one.

As in the previous post:
http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication

* client doesn't keep any state (other than encrypted client-side secret)
* server might use the same server-side salt for all accounts
* challenge is predictable (hash iteration count & server-side salt)
* attacker can both evesdrop and impersonate the server

if the server uses different/unique server-side value for each client,
then the attacker will have to evesdrop at least one transaction for
each client .... otherwise it only has to evesdrop a single client
transaction to get enuf information to impersonate the server for all
that server's clients.

The server impresonation attack is to send the client a challenge with
the server-side value and the hash iteration count of one. Once it has
the client's response for hash-iteration-one .... it can impersonate
the client and provide a valid client response for any valid server
challenge involving a hash iteration count greater than one.

If the client isn't keeping any state .... other than the originally
encrypted client-secret ... then it may never realize that it has been
attacked and spoofed into giving up the first hash iteration value (or
any hash iteration value less than currently being used by the valid
server).

The RFC described OTP such that the client only has to keep the
original client-secret ... and an OTP infrastructure where the same
client-secret can be used with an arbritrary number of different
servers w/o divulging information.

However, if the client isn't keeping any state information, a
questionable server can attack another server (if it has evesdropped
and obtain that server's salt). Instead of sending to the client, its
server-salt and the current count ... it sends the client a different
server's salt and a count of one. It gets back the first iteration
count for the server it is attacking and then signals the client a
transmission error and repeats the challenge/response with its own
salt/count. You might even imagine a black market in (stolen) first
iteration hash values.

The attack is the same whether the client is using the same
client-secret or different client-secrets for all servers .... since
the attack is not dependent on the attacker ever finding out the
client-secret; just the first iteration hash value (or any hash
iteration value, less than the current iteration value used by the
server). 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Relevant Pages

  • RE: Good salt practices, references?
    ... Subject: Good salt practices, references? ... A static salt is all but worthless; all it does is prevent an attacker from ... > It's then stored on the server, ... > When the user authenticates, the client takes the user's input, ...
    (SecProg)
  • Re: Iterative Password Hashing vs Strong Salt
    ... a "salt" is something that is assumed to be known to the attacker ... Iteration slows down brute force attacks. ... server or your application and gets access to the password file, ... if your web application happens to require client ...
    (sci.crypt)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)