?

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

lj_clients

[krolain]
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?
linkReply

Comments:
[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)