Discussions About MOSS (Myst Online Server Software)
I use very strong passwords for things. Is there a limitation? MercAngel gave us a test account with a very simple password and I can use that fine.
Perfect speed is being there.
DirtSand probably assumes the SHA-1 in the database contains the username when required. Not the the current account adding code handles that correctly - it just stashes the password SHA-1. It's unlikely email usernames have ever actually been tested in DS, to be entirely honest. I'll fix the account add function anyway, though.a'moaca' wrote:Okay, I just posted something, but it was missing something. I will try again in a few minutes.
I'll be editing my original post to contain the correct info about email hashes, just for the sake of having it be correct.
EDIT: oh, wait, now I remember why it does the SHA-0 second. That SHA-0 includes the client and server challenges, so it must be done at runtime.
Last edited by branan on Tue May 03, 2011 11:09 pm, edited 1 time in total.
Well, it is relevant information, except for the part about it being wrong.branan wrote:I just saw that the script is using the MOSS tool for this, so I'm going to assume that was written correctly. I'll post this anyway for the sake of it being relevent information to account management.
It is interesting to know there are other special accounts like @gametap -- we did not think to test that one. Direct from MOSS's documentation, I have:
This isn't the whole story: this description is only about the secret shared by the server and the user. The other part of the story is what happens at login. With the "special" account the client sends this 4-byte-wise little-endian version of the SHA-1 hash. (This is not the same as little-endian, which would swap all 20 bytes.) But for the "normal" password, the server sends a nonce. The client SHA hashes the server nonce with a nonce of its own along with the shared secret and sends *that* hash, big-endian (in other words, in the normal order defined for the hashes).
Code: Select all
- Usernames of the format "email@example.com" where x is one or more characters, called here "email-address usernames", use an algorithm with SHA on the password concatenated with the username. The strings are widestrings, and the last character of both the password and username is replaced with nul. The "compute_auth_hash" program will generate the correct hash for you. - Usernames not of the format "firstname.lastname@example.org" instead simply use a SHA-1 hash of the password. (Not as a wide string.)
There's no "weird Cyan-hash". The "normal" login is a CHAP-style authentication which prevents replay attacks on the password hash.
Given that the "normal" authentication is SHA and not SHA-1 I cannot see how anyone could possibly start from a SHA-1 password hash and get to the plaintext necessary to get a SHA hash later. If that were possible, it is not much of a password hash. DirtSand would have to store the password unhashed. And so I think that is what it does, if it does what you describe.
But I think it is more likely that it is storing the shared secret part, just the same as MOSS. Since your username does not typically change all the time, MOSS just assumes you put the correct type of hash in the DB.
Regarding restrictions on characters: I don't know for sure. That is a good question to ask those who know the client code. I would warn against using non-ASCII characters in your password, though. If the client lets you use them, it might toss them, shave off bits, or do the right thing. In any of those cases, you won't be able to log in. In the latter case, it's because compute_auth_hash does not do proper full-on conversion from xyz to UTF-16. It assumes your input is ASCII.
Last edited by a'moaca' on Tue May 03, 2011 11:10 pm, edited 1 time in total.
Reason: fix broken formatting
Reason: fix broken formatting
It's weird in the sense that it's unneeded. If the net protocol was unencrypted, it would be fine, and CHAP would be the right thing to do. 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.a'moaca' wrote: There's no "weird Cyan-hash". The "normal" login is a CHAP-style authentication which prevents replay attacks on the password hash.
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. 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).
So in short: Server should always have an SHA-1 hash. For normal/email usernames, this is a hash of username+password, for other usernames, it's just the password. For normal/email usernames, a SHA-0 CHAP is also done.
Who is online
Users browsing this forum: No registered users and 1 guest