[clug] A Question About Password Handling and Authentication Mechanisms

[jm]

The mailing list seems to be chosie about which messages of mine it 
accepts. This is the third time I've tried to sent this reply.

Just below the Wikipedia reference you provide is the Examples section ( 
http://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication#Examples 
). Some of the protocols there look to written to address similar 
concerns. I don't have time to read these today though. If these 
protocols do avoid storing usable password information on the server or 
disclosing it on the channel, then one must ask why these protocol 
aren't getting wide use?

To take one example (rfc5802), SCRAM provides the following protocol 
features:

    *  The authentication information stored in the authentication
       database is not sufficient by itself to impersonate the client.
       The information is salted to prevent a pre-stored dictionary
       attack if the database is stolen.

   *  The server does not gain the ability to impersonate the client to
       other servers (with an exception for server-authorized proxies).

    *  The mechanism permits the use of a server-authorized proxy without
       requiring that proxy to have super-user rights with the back-end
       server.

    *  Mutual authentication is supported, but only the client is named
       (i.e., the server has no name).

    *  When used as a SASL mechanism, SCRAM is capable of transporting
       authorization identities (see [RFC4422], Section 2) from the
       client to the server.


Jeff.



On 26/11/2014 5:32 pm, Tony Lewis wrote:
>
> On 26/11/2014 1:57 PM, jm wrote:
>> There is an area of crypto where it is possible to carry out
>> calculations on encrypted data such that the "person" making the
>> calculation is unable to recover the initial data. ie, it's possible to
>> encrypt to numbers and have a third party add those numbers without
>> being able to find out what those numbers are. Roughly,
>>
>> if E() is encrypt, a and b are numbers, '+' is the appropriate addition
>> method it's possible to do,
>>
>>      E(a) + E(b) = E(a + b)
>>
>> which is what got me thinking down this path in the first place.
>
> I know not of what you speak, but am curious if anyone knows any more 
> about this.
>
>>
>> Now my notation is a little wonky as i don't know what the correct
>> notation is, so let me describe what I'm thinking in hopefully a better
>> way. I'll do this as dot points so you can highlight any problems in my
>> logic,
>>
>> * I said hash, but simple mean a one way function not necessarily a
>> standard hash like sha1.
>
> That's the definition of a hash function: a one way transformation 
> that is collision-resistant (and other stuff)
>
>>
>> * The functions Hserver(), Hclient(), Verifier(), are not  the same
>> function.
> Why?
>>
>> * If project this into one dimension graphically I'm thinking something
>> like this, (Looks a lot better when I scribed it on a bit of paper)
>>
>>             |              |
>> |
>> |
>> server: password--> Hserver(password)------->
>> Verifier(Hserver(password), challenge)->|
>> client:  password----------------------> Hclient(password,challenge)
>> ------------->|
>>
>> * Each application of a function moves you further to the right with no
>> way back.
>>
>> * Reading your email more closely the second time. Your right
>> Hclient(password,challenge) == Verifier(Hserver(password), challange),
>> so given a stolen hash Hserver(password) and the challenge it's possible
>> to calculate the response.
>>
>> * What about
>>      Hclient(password,challenge) != Verifier(Hserver(password), 
>> challenge)
>>
>>    instead either make these a propablistic match and do multiple rounds
>> (similar to a zero knowledge protocol if I remember correctly)
>>    or  introduce a Compare() function that takes the response from the
>> client and the Verifier() function to give a boolean value of 
>> equivalence?
>>
>> So, assuming that such functions exist is there a hole in my logic? And,
>> if my logic is correct are such function known to exist? And/or, is
>> anyone researching this?
>
> I'm a little lost, but I think your argument is self-fulfilling. If 
> such functions exist, then there is no hole in your logic. Otherwise, 
> there is.  I don't know of any.
>
> And I'm at a loss as to figure out what problem you're trying to solve 
> that existing password authentication schemes don't solve for you.
>
>>
>> Finally, thanks for taking the time to wade through this.
>
> Not sure I helped this time.
>
> Tony
>


!DSPAM:54759c7212414610270585!