0.5.7 Minilogin, and LS release - Page 3

Elkay · #31 09-17-2004, 10:25 AM

Quote:

Originally Posted by Doodman

Oh, you'll need to pull the new CVS dump (when it gets out) and use the login server at 5994 instead. (see my link posted earlier)

That is the IP/auth work around to the random account bug.. Now that crypto is broken, we don't need it.

After that, you'll work okay.

Awesome, thanks for the info.

giulietta · #32 09-18-2004, 01:54 AM

Guess I do have the 5.8 client although I dont remember patchign up to i t. Oh well I guess I just have to wait for the mini login update......

/fish

/fish

/drink

/fish.....

KhaN · #33 09-18-2004, 02:07 AM

Quote:

Oh well I guess I just have to wait for the mini login update......

Wont happen tomorrow, this LS is the result of Smogo work for "World of Alkora" LS, and he decided to make it public so it would maybe be the start of an opensource LS.

We could spent time like Doodman did to break crypto to release a 5.8/live version of the LS, but we have other priorities on our task list and also because "World of Alkora" use 5.7 client, and we dont intend to be live compatible during the development phase, so i dont think LS live version will be made for the next months, since our first objective for the LS is attained, aka make a LS allowing peoples to login.

We are actually fixing some minor bugs, moving LS to C++. From time to time, new version will be posted, since we really want it to be opensource.

This LS instead EQEmu LS is intend to be opensource, but as its only a small part of the "World of Alkora" project, we cant fully work on it, if any of you made fix, made a live version, i would suggest to post them here, or PM smogo, and it will be added to the next versions.

Elkay · #34 09-18-2004, 04:17 AM

Thanks for the update, will just have to be patient and wait as usual hehe.

giulietta · #35 09-18-2004, 04:38 AM

Thanks for the update...

Guess I will byte the bullet and learn the one area of computers I swore I would never learn in detail.. programming.

Take me a couple months to bring my basic skills up to speed and then I'll try to contribute back to this community.

P.s. Any needs in any Networking areas...software....permissions etc I can assist in almost all with mroe than 10 years exp...just swore I would let others do the zeros and ones thing until now

daeken_bb · #36 09-18-2004, 04:41 AM

I think the problem here is the same as why we aren't including official LS support in OpenEQ... the crypto is DES-derived and depends on the key and algo being hidden to protect the data. If the algorithm gets out, it's no stronger than plaintext. I'd really like to work with you to get this to support OpenEQ clients when the time comes... we plan on using SSL, so there's no problem with opening the source as long as we don't distribute private keys to people hehe.

giulietta · #37 09-18-2004, 05:30 AM

Thought... would it be possible to re-encrypt after decryption?

I am assuming the eq client uses DES so we need to do the same to get communication back and forth... but once the DES is recieved by Login-server can we not re-encrypt? differently and then put back to DES on the return signal to client?

I know there are encryption algorithms like .net ones that take variable information as part of the key based on computer settings from clients machine which make knowing the algorithm itself useless to people because they would also need information about the clients machien such as computer name or the like.

daeken_bb · #38 09-18-2004, 05:43 AM

We don't have a whole lot of room to move though while keeping compatibility with the official client. you either use the crypto or you don't... can't change what the crypto is or how it's used, really.

tcsmyworld · #39 09-18-2004, 05:07 PM

KhaN · #40 09-18-2004, 07:31 PM

Daeken_bb, i would be for an MD5 encryption, here, lots would wonder why ? Because PHPBB forums use MD5 encryption, and it would be a good way to a cross user DB for forum / website / server.

sotonin · #41 09-19-2004, 04:01 AM

You do know that md5 is one way right? Once it's encrypted there's no going back.

daeken_bb · #42 09-19-2004, 04:30 AM

The problem with that is that if they sniff packets they can pull out the md5, and even though they can't get it back out, they can send it already hashed. Of course, we could defeat that with a salt, but SSL would still be far more secure.

Elkay · #43 09-20-2004, 05:45 PM

I say, as long as it's compatible and secure, the method does not matter to me.

FYI: We used DES3 with our software, though I had nothing to do with that part of our projects.

RangerDown · #44 09-21-2004, 04:58 AM

Quote:

The problem with that is that if they sniff packets they can pull out the md5, and even though they can't get it back out, they can send it already hashed. Of course, we could defeat that with a salt, but SSL would still be far more secure.

No, don't try to make the client hash the password before sending it up. Send the password encrypted, but using something that can be decrypted. SSL would be perfect because the keys are dynamically generated, and the server would be able to decrypt the block once it got it. Then, using the (now decrypted and now plaintext) password, the server compares a hash of it to the hash you have in the user database, to see if the password is correct.

Elkay · #45 09-23-2004, 04:34 AM

That sounds like it would work. I do have one question though, well a few. First, who on here actually runs the EQEmu LS? And second question, what is not secure about the code in it that disallows it's distribution, or is the EQEmu LS code not compiled code? I know that the recent but currently defunct Minilogin was written in Perl, and I do know of utilities out there that compile Perl code into a standalone executeable.