[clug] A Question About Password Handling and Authentication Mechanisms

[jm]

Yeap definitely agree that the password should not be stored in a
recoverable form anywhere. Add to this that there should not be
transmitted any information in any form that would allow an eavesdropper
to either recover the password or fake knowing the password.

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.

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.

* The functions Hserver(), Hclient(), Verifier(), are not  the same
function.

* 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?

Finally, thanks for taking the time to wade through this.

Jeff.

On 25/11/2014 9:43 pm, Tony Lewis wrote:
>
>>   Upon connection from a client a
>> challenge is sent to the client and using the plain text password
>> entered by the user the client carries out a one way calculation, call
>> this hash Hclient(password, challenge) which is then sent to the server
>> for verification. To do this the server performance another calculation
>> on the hashed password, Verifier(stored_password, challenge), and
>> compares it to the client supplied hash. In other words,
>>
>> 1)  Server stores password
>>    stored_password = Hserver(password)
>>
>> 2) Client connects.
>>
>> 3) Server send challenge to client, challenge.
>>
>> 4) Client calculates response to challenge with a one-way function
>>    response = Hclient(password, challenge)
>>
>> 5) Client sends response to server
>>
>> 6) Server calculated verifier code
>>     verifier = Verifier(stored_password, challenge)
>
> Here's where things break in this example.  Server has
> Hserver(password), and has no feasible way to calculate
> Hserver(password+challenge) because it cannot (easily) recover
> 'passsword'.
>
> It could do Hserver(Hserver(password)+challenge) but that effectively
> treats Hserver(password) the secret (i.e. as good as the password) -
> an attacker would only need to know Hserver(password) from the
> database, plus intercept 'challenge' in order to authenticate.  If you
> use TLS then the channel is protected, and so this looks like it would
> work at first glance.
>
> Oh yeah: they say that here:
> http://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication#Password_storage
>
> And OWASP have some stuff (though not enough on challenge-response):
> https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Store_Passwords_in_a_Secure_Fashion
>
> Tony
>



!DSPAM:5475422512411246814222!