Opinion from Community

[Aergad]

also setpass is for the account table for worldserver ONLY it isnt connected to the LS in any way

[trevius]

Aergad, did you read my post at all, or did you just not understand what I was talking about?

The old mini-login that is IP based uses the server's accounts table to authenticate, only it uses IP instead of any sort of password. That is the exact thing I am talking about that we could do with a new Private LS that could authenticate via passwords instead. It would run locally on the individual server's network (or even on the same server), and would have direct access to the accounts table for authentication exactly like the IP Mini-Login does now. It is a simple concept. It also has nothing at all to do with running some centralized account database, as that would be one of the worst security risks possible, LMAO. I don't think you quite understood what I was talking about. And yes, #setpass would set the password in the correct place for this idea to work.

Now, if there are some password authentication issues with Login Servers, then that is news to me. I couldn't come up with a good solution without knowing all of the details. But, I can't really imagine that the client would ever not send the password for authenticating unless there was a hack around it. And if there is a hack around it that compromises accounts, then I don't see what that has to do with this particular idea that doesn't also effect all Public and Private Login Servers already.

[image]

so you are saying they create a command to set their login password to be used on said private server which is the world server owner? Just making sure I understand.

[Aergad]

whati am saying is that the new minilogin doesnt touch the accounts table it uses login_accounts its two totally different forms of authentication

[Aergad]

the setpass command is used for the worldserver only for access to the web interface and telnet the two tables are apples and oranges the ls doesnt touch the accounts table and idealy the ls uses a seperate database entirely for the login accounts they dont interact worldserver handles all the interactions with accounts table so doing it how you said would make no sense

[trevius]

Originally Posted by image

so you are saying they create a command to set their login password to be used on said private server which is the world server owner? Just making sure I understand.

Sorry, Image, I am not clear on what you are saying there.

Here is an example of what I think would work very well:

1. PlayerA logs into the Public Login Server with their account "player1" and connects to their favorite server.
2. If that server is up-to-date and configured to use the Public and Backup Private LS at the same time, they can enter the game on that server and type "#setpass mypassword". That will save "mypassword" in an MD5 hash into the accounts table for their account "player1".
3. They can then log out and exit EQ completely. And then change their eqhost.txt file to point to their Private LS for that particular server.
4. This time, they log into EQ and hit the Private LS for that server. When they log in, they use the account name "player1" still, but then they use the password "mypassword" that they set while they were on their public account.
5. Since the Private LS would have direct access to the accounts table (just like the IP based mini-login one does now), they would authenticate to that account and have access to their own characters from the Public account. Since they set the password while logged into their Public account, it verifies that they do own that account and should be just as secure as using the Public Login Server.

The only issue with this option is that a determined admin could crack the password that the user set in their accounts table if they wanted. So, it would be a good idea to use a different password from what they might use for other servers and for the Public LS. But, the MD5 should at least reduce the likeliness of admins snooping through passwords. If you are playing on a server where you trust the admins of it, this shouldn't be an issue at all anyway.

Does that make sense? I can picture it working perfectly like that, but it probably sounds a bit confusing.

[image]

I understand what you mean, if the login server were setup to use the same database as the world, yes.

[trevius]

Originally Posted by image

I understand what you mean, if the login server were setup to use the same database as the world, yes.

Using the same database as world works fine for the IP-based mini-login. Is there a reason why it wouldn't work for the password-based one?

[image]

Originally Posted by trevius

Using the same database as world works fine for the IP-based mini-login. Is there a reason why it wouldn't work for the password-based one?

I just said you could :P

[Cripp]

ok.. I didnt read the last few posts yet but heres my 2cents..

I think all we need to do is change the LSID for the accounts to either the lsid for your LS or isid for eqemu LS..

so like if your changing from eqemu LS to private, set the LSID to the same account to the private LS LSID.

shrug lol.

[Aergad]

ok butyour not listening here the LS doesnt TOUCH the account table what your talking about would require a total rewrite of how the ls works AND a rewrite of how world authenticates...

Ontop of that the lsacctid value wont match so world wont let the user in if they switch between loginservers each ls would assign its own loginserver id.

World is the only thing that touches the accounts table the login server runs off a different database

minilogin the official one doesnt even touch the account table look int he worldserver code worldserver handles the authentication minilogin jsut sends the ip to the worldserver

[Aergad]

minilogin doesnt use the database at all though thats wht you dont understand look in the code the worldserver handles all that all minilogin does is transmit the ip to world.exe thats why it works that way with minilogin but here is the catch the new minilogin uses a totally seperate table called login_accounts

[trevius]

What exactly are you proposing as the ideal solution, Aergad? To make everything 100% privately handled? I am sure that could be done very easily with the mini-login image wrote just by him removing the restrictions he set on it. Everything else is already in place for that.

All I am proposing is a solution that would work for everyone in almost any scenario. Sure, that would require some rewrites to the current code, but is it all that hard to change the table that it interacts with?

Also, the LSID shouldn't really matter at all. The Public LS uses it because it runs from it's own database and should always match up fine. Since it doesn't send a password to the server when an account logs in, checking the LSID should just be another way to verify that it is the correct account that is trying to connect. In the case of a private LS, you shouldn't even need to verify LSID, since you get the account and password, which should be plenty to authenticate securely with.

I am fully aware that the mini-login Image wrote uses different tables. But, since the Login Server and Server code both have the ability to be changed, anything is possible. If the issue was a limitation of the client, that would be a different story, but in this case, it isn't.

I am not trying to get anyone to do anymore work than they want to do on getting a solution created. I just wanted to mention what I consider to be the ideal permanent solution.

[Aergad]

one thing you are forgetting is that SOE made this to work a certain way eg the client for their use on one login server not 50 or 100 loginservers all sharing and transfering information. all it would take is ONE person with ill intentions and the skills to pull it off and what you propose would put everyone at risk because, and this is the key all the loginservers would have to communicate with one another. It is the only way to transfer lsaccount ids and so forth and edit them automaticly. ontop of that we cant make the client transmit anything it doesnt already transmit.

the more things connected to the loginservers the more insecure they are, hell look at the current public ls and what someone is doing bringing ti down, now imagine if all loginservers were connected to each other imagine what that one person could accomplish.

Along with THAT risk there is the risk of all that account info just floating about cyberspace its just a bad idea no matter how you slice it.

I think images original plan is the best ONE public loginserver and the private ones listed in a central place where people can pick and choose which they want to play on.

Hell you cant even transfer accounts between servers on live without paying them a hefty fee and when you do pay them it takes them a while to do it dont you think the reason for that is the fact that its not a simple thing to do?

I would NEVER condone a system in which if someone compromises one ls all would be at risk because they are all located centrally sharing account information and so forth. its just too dangerous

Not only that but there is no reason for it the minilogin users use minilogin to NOT be on the public loginserver for their own reasons i highly doubt they want their own login server connected to the puclic loginserver. what you are proposing doesnt make sense, and im sorry for saying that but it just doesnt.

Why go through all that work why put EVERYONES supposedly private ls at risk by them all being connected to the already massivly insecure public login server when the people who DO use minilogin dont WANT to be connected to the public LS anyway.

and please dont say its best that everyone is connected and sharing the public ls because shards of dalaya disproved that long long ago they are private and have a far far bigger userbase then any one server on the public ls heck probably all of them put together dont come close to the ammount of players SoD has at any given time most ive seen on PEQ the most popular server on the public LS is about 200 or so

the LSID IS in the NEW Release of minilogin your talking about totally reinventing the wheel. and yes we can put anything we wnat in any hunk of code but the questions are one will it actually work properly TWO how secure will it be cause i sure as hell dont want my server compromised because its connected to another server that gets hacked like the public LS Does DAILY. nor do i want my users in a possition to have their accounts hacked because someone compromises their account through someone elses server.

not only is your idea an enourmous ammount of work for the develpers but then the users are gunna have to keep track of the ls password then the password theyt use on each and every worldserver they connect to...


Its full of more holes then swiss cheese security wise. images method is best in this case all loginservers standalone listed in a central location not interacting with all thee other loginservers plus one that getshacked every day and brought down that is the most secure way.

again MOST people are going to use the public LS anyway the people who DONT use it already are the ones who are going to be using this the most.

and yes there are client limitations why do you think you cant have an eqhost.txt file full of loginservers to choose from. remember this system was made by soe yes it was reverse engineered by the emu staff past and present but the way its got to work with the client is the same and that setup is only for ONE login server the way they designed the client thats how it works.

but all that aside the worst part of your idea is the huge security risks to EVERYONE that it poses