OpenUru.org

branan wrote:But at this point in the connection DH has been completed, so it's unnecessary and redundant. It might be a normal thing in some systems, but it's "weird" in the overall architecture of MOUL's network code. Beyond that, It's SHA-0 which no one should be using for anything ever.

I agree about the SHA-0 part, but..... you can disable the connection encryption. I don't think an extra layer of protection is a bad thing.

branan wrote:As for other things: I've verified in Cyan's client code that the initial hash is always SHA-1, regardless of normal or special.

If that were so, nobody would be able to log in with "normal" email addresses after using compute_auth_hash. It's tested, it works. Except for whatever verboten character JW used. The use of SHA is even in libPlasma.

branan wrote:The username is part of the hash for email usernames, and not part of it for other special usernames as you said. (that's another one of those special/weird cyan netcode moments).

Things develop by accretion, you know. Now, me, I would have called putting nul in place of the last character of the address and password the weird part.

- a'moaca'

a'moaca' wrote:

branan wrote:As for other things: I've verified in Cyan's client code that the initial hash is always SHA-1, regardless of normal or special.

If that were so, nobody would be able to log in with "normal" email addresses after using compute_auth_hash. It's tested, it works. Except for whatever verboten character JW used. The use of SHA is even in libPlasma.

OK, you're right. I checked again, and I misread the code the first time . In my defense, all the hashing code is hand-rolled, instead of using an existing library (like OpenSSL)

branan: I'm sorry, but check again. It's using OpenSSL SHA and SHA1. There are just lots of wrappers.

JW: I have not found any special treatment of characters in the client. I'm afraid I must suspect your password has something like ' or " or something else in it that has not been quoted properly by the PHP script. This needs more debugging, but so long as your characters are all printable ASCII as you put it, I don't think it's the client or compute_auth_hash.

I need to get back to my paying job now for a while.

- a'moaca'

A semicolon was the offender.

So does this script need some work and testing to quote everything correctly?

- a'moaca'

Was there a conclusion here? What I'd really like to know is whether MOSS (and the client) have any expectations about what characters should not be used in a password? It sounds like any printable character ought to be OK with a few exceptions that might need to be escaped in the PHP script to be handled properly.

Mac suggested to me that Merc was cleaning/stripping some characters from the pw. So it removed the semicolon in my pw, but I was still typing it. If I had not tuped it, it probably would have worked.

I think I was "misremembering" MercAngel's code. Looking back at what was posted at the top of this thread, that cleaning was only on the username and not the password. There's nothing in PHP or the HTML form handling that'd cause a semicolon to be dropped and I've established that a semicolon will survive right up until the hash is evaluated. Then, once the credentials are hashed it's largely irrelevant what symbols were used. So maybe it's the user input handling at login that's discarding some characters and causing the hashes to mismatch?