||[Apr. 19th, 2004|01:03 am]
LiveJournal Client Discussions
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:
- MD5 HEX the password, then convert to string
- Append the converted password string at the end of the challenge string from server
- 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.
2004-04-19 08:21 am (UTC)
- Do you remember to send they key auth_method, sent to value 'challenge'?
- Are you sending back both the challenge string you received (in key auth_challenge) and your response (in key auth_response)?
- 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.
- Make sure the hexadecimal letters a-f are in lower case when you MD5.
- 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.
- Yes, challenge/response does work. People have gotten it to work successfully.
- Good luck!
Thanks for your comments.
- Yes, I remembered that. Based on the docs, I had to send that :-)
- Yes, I was sending both the challenge string and the response.
- 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
- 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.
- Yup, now that I fixed the lower string issue, I see that it works.
- 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! :-)
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.