Sim-Eth-Basic password

Want to make sure I am implementing passwords in the right place.

For Sim-Eth-Basic, as I am reading things, we execute login from here,

after doing basic checks for user name and password.

Which calls on the delegate that was returned from the server upon initialization.

This AccountSession is implemented on the GameServer via AccountHostedService in a private class here.

I take this to be where I am to implement the code for password checks and where line 152 shows as

getCallback().notifyLoginStatus(true);

send this back as true or false, depending on the results of the check.

Then from here decide what to do with the client.

Yep. Looks good.

Ok, thanks.

The only thing to really add is that you check login attempts and reject if they have failed x times in 5 mins or whatever. This circumvents brute force attacks where they spam possibles until successful.

This actually causes an issue where someone can lock you out of your account just by using wrong passwords, so generally a notification email is sent to the owner with a verification link so they can remove the restriction.

I hadn’t thought about them doing it on purpose, just forgetting.

Yeah, you got the workflow right.

Note: I only implemented the minimum necessary to have a complete workflow. You may end up wanting to add parameters, add steps to the workflow, etc… depending on your use-case. (For example, maybe the server sends a challenge to the client before expecting a password.) But the example shows how the back and forth can happen.

Something that verifies its my client?

Edit: Or like send username before asking for password?

It can do lots of things. It can indicate which forms of password it expects, a message to users about to login, etc…

Presumably if the client send the login(user) request already then you know that it’s at least that much “your client”.

But for example, for Mythruna I was originally using MD5 passwords and switched to SHA-256. During the challenge I could send information about what password forms I accepted so I could still allow MD5 if they hadn’t reset them yet (but also trigger a resend as SHA-256 so I could update their user info).

I could also have done silly things like public/private certs, etc…

I guess the real “Java security” model is to say “I want to login” and then it calls you back for actual credentials using a provider.

Incidentally, that’s why I don’t have a dummy password argument on the login() method. In 100% of my own games, I’d never have a password argument.

Rather than ask more questions I am going to get the basic authentication setup because that last remark ,

is exactly what I was thinking myself. I need to understand SimEthereal better first though and this will help with that.

Yeah, when the app is 100% handling its own logins then it’s usually something like:
client: login(user)
server: challenge(message, list of auth types, additional info like one time salt or something)
client: authenticate(hashed password)
server: notifyLoginStatus(true)
…which could also include error information.

The “message” in the challenge can be used for user-specific prompts like “Your account will expire in 10 days” or whatever… or any “you should really read this” prompt that might be necessary “Server will be going down in 4 minutes.”, etc… that they might have ignored on the main screen.

Edit: when the app is not handling its own logins and shelling out to a separate server then it might be passing auth tokens around instead.

I think I am going to write another spring server that will connect to the vault and handle authentication. This way I can manage creating credentials and tokens, resetting passwords or lost passwords, etc and I can send them web page links and stuff like that like the big boys do.

Challenge will fit right into that type of system. The GameServer would only have a small method for connecting then as the authentication server would be doing all the work.

Yep, exactly.