RE: Thoughts on shared-key authentication

[Dan Simon <dansimon@xxxxxxxxxxxxx>]

The problem with Charles' proposal is that it does not protect passwords
against off-line attacks.  If I can obtain a challenge-response pair
(say, by cracking the 40-bit encryption used to encrypt it), and the
client's password is poorly chosen (or is nothing more than a 4- or
5-digit PIN), then I can simply do a dictionary attack on the
challenge-response pair, obtaining the original password by exhaustive
search.

Our shared-key authentication proposal is designed to thwart this
attack, by incorporating a long key derived from the master secret into
the authentication response.  Since the master secret is exchanged using
public-key cryptography, the derived key hashed into the authentication
response is not available to the attacker regardless of the strength of
symmetric encryption used.  Hence even a 4-digit PIN is effectively
invulnerable to off-line attacks (on-line attacks can of course be
restricted in number by a properly designed server).

				Daniel Simon
				Cryptographer, Microsoft Corp.
				(dansimon@xxxxxxxxxxxxx)

>----------
>From: 	Charles Watt[SMTP:watt@xxxxxxxxx]
>Sent: 	Friday, October 11, 1996 2:58 PM
>To: 	ericm@xxxxxxx
>Cc: 	marcvh@xxxxxxxxxxxx; tomw@xxxxxxxxxxxx; ietf-tls@xxxxxx
>Subject: 	Thoughts on shared-key authentication
>
>-----BEGIN PRIVACY-ENHANCED MESSAGE-----
>Proc-Type: 4,MIC-CLEAR
>Content-Domain: RFC822
>Originator-Certificate:
> MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
> A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
> dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
> MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
> Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
> DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
> AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
> 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
> A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
> aTxjgASxqHhzkx7PkOnL4JrN+Q==
>MIC-Info: RSA-MD5,RSA,
> BwP+eZsNFRAvH/278pFEFxJYn4qugayrKLxU0mEYckY5DDWVTbDex6Dpjq8jAncW
> 1ydDgePOn0MDaLcb6Er+czg=
>
>There are many applications that have a much stronger requirement for
>data authenticity than for confidentiality.  As an example, retail
>banking over the Internet.  (Please hold any comments on the specific
>example.  If you do not like it, think for a while and you will be able 
>to find an example that your prefer that meets these criteria).  40-bit 
>keys for encryption are adequate for things like viewing your check 
>register -- there are MUCH easier ways for an attacker to gain access to 
>your transaction data than breaking a 40-bit key (e.g., if in the US the
>odds are pretty good that your bank supports telephone banking where all 
>I need is your account number from your check and your SSN, which I can 
>look up on the Web).  However, the authorization of bill payments requires 
>a full 128-bits of authenticity -- definitely not cool if an attacker can 
>pay your bills for you.
>
>When servicing a customer base of > 1 million account holders, it is:
>
>	1) an onerous administrative task
>	2) a horrendous performance hit on the server
>
>to use client-side certificates -- particularly in light of the fact 
>that most banks have already distributed via manual methods sufficient 
>information to authenticate customers (e.g., ATM cards and PINs) that 
>could be used in an automated fashion by an on-line bank server.
>
>It is quite possible to build into TLS a shared-secret authentication
>mechanism that is exportable and whose strength is independent of the
>strength of the encryption.  We run an example of such a mechanism in 
>our lab:
>
>	a) modify a public-domain implementation of MD5 or SHA to add
> 	   procedures for saving and restoring the internal state
>	   registers -- an easy task.
>
>	b) on the server, create a one-way hash of the customer password
>	   by running your modified hash function over the password.
>	   Save the internal state registers of the hash function and throw 
>	   away the password.
>
>	c) when the customer logs in, have the server send a one-time nonce
>	   to the browser.
>
>	d) have the client prompt the customer for the customer's password.
>	   The client calculates the one way hash of password + nonce.
>
>	e) send the resulting hash value to the server.  Note that a standard
>	   version of the hash function is all you need on the client.
>
>	f) server verifies customer password by restoring the hash function
>	   registers and performing the final hash cycle over just the
>	   nonce.
>
>Charles Watt
>Security First Network Bank
>www.sfnb.com
>
>P.S:
>Even though we built this in the lab with the intent of providing it for
>our international banks, we were never able to deploy it due to a security
>flaw in all SSL-capable Web servers that were available at the time -- no one
>provided an interface by which the application running on the server could 
>access the SSL session ID.  Without access to the session ID to link 
>successive connections into a login session, the 128-bit keyed hash provided 
>by SSL is worthless to the application.  Instead the app must fall back on 
>the cookie mechanism as a way to link a login session.  But cookies are
>protected using 40-bit encryption, reducing the assurance with which you can 
>link successive connections from 128 --> 40 bits.  
>
>In the end it was easier to find an off-shore solution to the crypto problem 
>than to get the big name server vendors to support secure applications.
>
>-----END PRIVACY-ENHANCED MESSAGE-----
>
>