Log in

No account? Create an account
LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Challenge/Response Protocol [Apr. 19th, 2004|01:03 am]
LiveJournal Client Discussions


Greetings everyone,

I've been trying to use the new Challenge/Response protocol to log in, but everytime I use it, it returns invalid password.

From what I gather from the document, it seems simple enough, but I cannot get it to work. Has anyone else gotten that to work successfully?

The pseudo-code I'm doing is basically this:

  1. MD5 HEX the password, then convert to string
  2. Append the converted password string at the end of the challenge string from server
  3. MD5 HEX the resulting string and send that to the server.

I've also tried not converting the MD5 HEX password to string, but keep it in byte format, and just append that to the end of the challenge string (converted to bytes), then MD5 digest the resulting byte array, but that also fails.

Granted, debugging does make many of the challenge expire, but I know it's not an expired problem. I actually get 'invalid password' from the server.

I've even tried to force the password string and challenge string to be in "UTF-8" byte format, but it doesn't work either. So, I am now wondering if this Challenge/Response protocol is working properly on the server, or am I missing something?

I am using the flat protocol, though I don't think that is the issue? I can get the MD5 plain password to work.

Help please?

[User Picture]From: marksmith
2004-04-19 08:17 am (UTC)

That has some Perl code to use the challenge response mode. Check it out and see if that works for you.
(Reply) (Thread)
[User Picture]From: krolain
2004-04-19 09:10 am (UTC)
I already looked at that link and that's where I got the basis for my own code and all. Unfortunately, it didn't answer my problem. Even with that link I spent a good few hours trying to figure it out. Now, I think I figured out the problem.

I managed to change a few things in my code, and I think what the main issue was is that the MD5 digested password string had to be in lower case. My MD5 digested password was generated in upper case, and when I merged that with the challenge and digested that, it generated the wrong response I guess. I got the hint from avva.

So, it now works, and all because of wrong case.
(Reply) (Parent) (Thread)
[User Picture]From: avva
2004-04-19 08:21 am (UTC)
  1. Do you remember to send they key auth_method, sent to value 'challenge'?
  2. Are you sending back both the challenge string you received (in key auth_challenge) and your response (in key auth_response)?
  3. Always use the MD5 digest as a string of 32 ASCII bytes. MD5 the password to get such a string, append to the challenge, MD5 again, and send the resulting string (not sa "byte format", whatever you mean by that, but as an ASCII string of hex digits) to the server.
  4. Make sure the hexadecimal letters a-f are in lower case when you MD5.
  5. Check the two specific MD5 values you're generating (the intermediate one for the password and the final one you're sending). Are they both 32 characters long? Perhaps your implementation of MD5 omits leading zeroes when they accidentally appear in the result. That's incorrect behavior. In that case, pad the result with leading zeroes to make sure they're precisely 32 characters long.
  6. Yes, challenge/response does work. People have gotten it to work successfully.
  7. Good luck!
(Reply) (Thread)
[User Picture]From: krolain
2004-04-19 09:20 am (UTC)
Thanks for your comments.

  1. Yes, I remembered that. Based on the docs, I had to send that :-)
  2. Yes, I was sending both the challenge string and the response.
  3. I did send the MD5 digest as ASCII. What I meant was when 'digesting' I had a few option to merge the challenge and MD5-password together to then digest. I could merge them as string, then digest, or merge their byte value equvalent then digest. But, I've always sent the resulting MD5 code as ASCII
  4. This is something I didn't know. My MD5 API engine always returned the digested string as upper case. This seemed to be the issue. As soon as I had convert the MD5-password string to lower case, it seemed to fix the issue. Is this an MD5 standard thing, or is that something LJ requires to be done? If it's for LJ, then I think the docs should mention that in case some MD5 API's (like mine) always spitout upper case HEX strings. This didn't seem to matter when using hpassword.
  5. Yup, now that I fixed the lower string issue, I see that it works.
  6. Thanks :-)

Thanks for the tips. With those pointers, I managed to find out that it was all a improper case conversion issue. Though I also ended up changing MD5 API library, so that may have also affected it. But I think it was the upper/lower case issue.

Again, thanks for your help. Solved my issue! :-)
(Reply) (Parent) (Thread)
[User Picture]From: avva
2004-04-19 09:39 am (UTC)
The MD5 RFC doesn't define the case in which a digest string is printed, but the accompanying example uses lower case. In LJ, lower case is used simply because that's what the Perl module we're using for MD5 is produced. In hpassword, either case works because we lowercase the digest before checking, but in challenge/response, one digest is used as part of the input to another, and here it becomes necessary to use the correct case. I agree that this should be documented more adequately; we'll make sure it is.
(Reply) (Parent) (Thread)