I am creating a multiplayer game, and i need (it would be better) to have an authentication on it.
I am not talking here about account creation or anything like that, i just need to transport through the network and encrypted version of the password (+ the login, if possible, but this one doesn’t NEED encryption).
The only thing i found with spidermonkey and encryption was an old discussion on the topic of the spidermonkey. The discussion is interesting, but it doesn’t explain to me if it’s possible and how to do it if it actually is, possible.
I know that using a ssl for every messages would be too much, but there is ways to encrypt only some messages.
Without encryption, it will be hard to do networking with jme. But i know that librairies like bouncycastle are huge
…
well, i wrote these lines, checked the size on the website … ok, the jar is 615 ko. A bit huge, but maybe acceptable.
SpiderMonkey does not offer encryption at the moment. Adding an SSL connector would add a whole mess of trusted key store complexity and so on when web servers already do that very well. From experience, this gets to be kind of a mess and I couldn’t think of a good way to clean it up.
Putting certs in a web server is pretty straight forward, on the other hand, because they are already written to deal with this. It can still be tricky to get Java clients to play nice with this (though that wouldn’t really be any easier if SpiderMonkey added it.)
For Mythruna, I’ve opted to use HTTPS for authentication and I went ahead and purchased a cert so I didn’t have to deal with the local keystore crud. I login to the web server to get the user info and then use that to connect to SpiderMonkey. It works in my particular environment where I already planned to have a central user management but I recognize it will not work for all games.
Alternately, you can do your own SSL networking with your server, unmanaged by SpiderMonkey itself but still in your process. Nothing prevents you from taking this on yourself and the hardest parts are all of the “stuff I tried to avoid” above. The networking bit is not particularly hard.
That being said, SpiderMonkey was designed with SSL in mind (or any type of connector really) so it would be possible to add it if anyone ever comes up with a nicely done SSL solution. It could just be another channel from the game’s perspective. Implementing SSL is even easy to do without actual full SpiderMonkey integration as it would be done at the message kernel layer that can be tested in isolation.
Also, for your purposes… if your server will be private and you think you can keep a private key private then you could go with some asymmetric encryption. Public key in the game client, private key on the server. Only the private key can be used to decrypt the message.
This could be done with regular SpiderMonkey messages to just send your encrypted block of data.
Encription for login howIdo
Client sends authentification request to server
server answers with a random string and stores it for the pending client
client concates it with password, hashs it with sha256 or md5 or ect. and clear username sends to server
server reads via username the stored password, concats it with the saved random string and hashes also
if both hases match, the client used the same password as the server.
This basic concept can be extended for hashed and salted passwords in the database quite easy.
If you just need to authenticate the client (as opposed to encrypting all client-server communication). You do not need SpiderMonkey for this.
Java’s URL class will suffice. E.g.
[java]
URL url = new URL(“https://yourserver.com/auth?user=abc&pass=def”);
HttpURLConnection conn = url.openConnection();
if (url.getResponseCode() == 200) {
// Login OK. (Retrieve auth token here)
} else {
// Login FAIL
}
[/java]
The important part is the https - it makes sure the connection to the server is encrypted so that the credentials that were sent cannot be intercepted. The server will send back an authentication token that you will need to use when you make your SpiderMonkey connection with the server. Since others on the wire can intercept this token, the server must only allow it to be used once. Once the connection is closed, the server must discard the token and never use it again. It is recommended the token is generated with a class like SecureRandom which makes it hard to predict the token data.
@Momoko_Fan it seems to be a pretty nice solution. I am a computer scientist and specialized in security but for this reason i am too much in complicate solutions when easy are good enough (at least for now).
However, this will not prevent from man-in-the-middle attack : once i start to use the token, the mitm can intercept this message, and start himself a discussion with the server with this token.
But your idea is good enough for me. I needed a secure connection to allow some player to create a new game (think about ut2004, where you can create a game vs join a game). I can put the creation action server side, but i prefer to have it through a protocol (so someone can host many game, as long as he give to his friend the right to create a game on his server).
I can use a connection through https and put datas in POST (like the number of players, the map, the mutators etc.) and the answer can be yes/no, the id of the created game etc.
@bubuche said:
once i start to use the token, the mitm can intercept this message, and start himself a discussion with the server with this token.
@Momoko_Fan said:Since others on the wire can intercept this token, the server must only allow it to be used once. Once the connection is closed, the server must discard the token and never use it again. It is recommended the token is generated with a class like SecureRandom which makes it hard to predict the token data.
I would go further and discard the token when the token-using connection is first established. A man in the middle attack is not possible. (And really the server should have been checking for duplicate tokens but this makes it easier.)
if the man in the middle intercept the first connection message (the message with the token) then ->i<- cannot log in, but he can. If i use some kind of broadcast to talk to the server the mitm can only try to go faster than me for the connection, but even in this case, what the server should do ? Close both connections ? So a mitm can just close every discussion just by emiting a message with the same token ?
And, if i don’t broadcast the mitm can just drop my message (not follow it) and then he will have a connection while i will not have it.
I guess if you’re making a game with character progress, in-game purchases, player chat, etc. you would want to have a separate “SSL stream” for those sort of messages, or just have everything go through SSL, since the most expensive part of it is the handshake you’re not gaining much by splitting the two.
Otherwise, I think just avoiding sending the credentials in the clear is fine. If they MITM you, it won’t matter much since its just a game…
And you’ve limited the MITM attack to a DOS for the player. The best you could do is keep him from connecting over and over but given the nature of the speed of connection, the originally connecting player will always try to connect with his token and dump himself and the attacker.
@Momoko_Fan: i would accept to send everything through ssl, but the fact is : i didn’t found a way to enable ssl in spidermonkey.
In my mind, message should have a boolean just like the “isReliable” but for the confidentiality : “isSecured” or something like that.
You got a point about “it’s just a game”, but even in games you need to have moderators and admin. Hey, even in irc you need that. If nobody can connect in a secured way, nobody can be a moderator/admin cause any hacker will be capable of kick/ban whoever he wants. And not talking about “client update” message from the server. You can connect a trusted server and accept to download & install updates from it, but not without a secured connection - otherwise it’s a breach for virus.
Maybe i am too much on this, but it’s like sex : it’s better when it’s safe
You can always think that it only happens to other people but when you are in trouble it’s too late.
@bubuche said:
@Momoko_Fan: i would accept to send everything through ssl, but the fact is : i didn't found a way to enable ssl in spidermonkey.
In my mind, message should have a boolean just like the “isReliable” but for the confidentiality : “isSecured” or something like that.
You got a point about “it’s just a game”, but even in games you need to have moderators and admin. Hey, even in irc you need that. If nobody can connect in a secured way, nobody can be a moderator/admin cause any hacker will be capable of kick/ban whoever he wants. And not talking about “client update” message from the server. You can connect a trusted server and accept to download & install updates from it, but not without a secured connection - otherwise it’s a breach for virus.
Maybe i am too much on this, but it’s like sex : it’s better when it’s safe
You can always think that it only happens to other people but when you are in trouble it’s too late.
See my original response above.
On the other hand, play with getting an HTTPS connection working with regular Java code. Unless you buy a cert there is a lot of stuff you have to do to get a self-signed cert working.
If your game needs a secure connection then you can use HTTPS outside of spider monkey. It has all of the infrastructure you will need. Otherwise, someone (not me) will have to develop a connector for spider monkey’s kernel that somehow solves all of these configuration issues (difficult).
And then I will incorporate it as a separate channel type. I already hate the isReliable thing that I kept from old SpiderMonkey and SSL would have to be optional because of the extra setup required.
SSL isn’t really a great protocol, it has inherent weaknesses (too many ways to compromise its security without noticing the problem, sometimes misguided reliance on the OS getting everything right).
I’m not sure what a good alternative would be though. Designing one’s own protocol usually means reinventing well-known security holes.
OTOH Java does come with a crypto library. OT3H that crypto has been harboring security-relevant bugs for more than a decade, so its quality is of dubious value. And Oracle is only starting to pick up momentum on security.
OT4H, if your game isn’t near the release, I’d stop worrying about that for now.
Given the current buzz about government-endorsed spying on everybody and their grandma I’m pretty sure that easy-to-use, reliable, secure crypto is being worked on by many people. Maybe one of these efforts can deliver something before you’re going public
Hey guys, I’ve recently started using JME to create a game with my son. I’m starting with a basic game which gets me through the hurdles of importing blender models with rigging/animation, has a basic Nifty UI, allows multiple game clients to connect to a game server and supports authentication, authorization and session management. At that point, I’ll be comfortable trying to take his ideas and working with him to morph this basic framework into what he wants to create.
I’ve been able rig a robot model from BlendSwap in Blender, add a walk cycle animation and successfully import it into JME. The robot can be controlled to move around and play the proper animation. We’ve put a basic Nifty GUI in place to enter server name, port, login and password plus some basic buttons to connect, quit, continue etc.
I was looking at using Apache Shiro for the security management. Has anyone here looked at Shiro?
I definitely need to understand the existing JME/SpiderMonkey support better as well as Shiro but I hope I can make it work…
While nothing to do with the original question, shiro looked fine when I took a look at it.
However you seem to be confuseing transport security for authentification/verification. Shiro will help you with login stuff role management ect. I’m not sure how much it will help you with transmitting stuff ofer the internet in an encrpted way.
SSL is your friend for encrypted transport. Java has pretty solid support for that.
(I’m not sure whether SpiderMonkey offers SSL support though.)
Authentication and encryption are independent features, you can implement either without doing the other.
Of course, auth without enc is usually pointless; what I mean is that you can implement them one by one, they don’t interfere with each other.
The easiest way to do this would probably be to make any login and handshaking messages only pass a byte array, and then populate this with pre-encrypted information using java’s standard encryption api. I would recommend hardcoding a 1024 or 2048 bit RSA public key into the client. The encryption only really needs to be one-way as login details should never be sent back to the client.
@fabsterpal said:
The easiest way to do this would probably be to make any login and handshaking messages only pass a byte array, and then populate this with pre-encrypted information using java's standard encryption api. I would recommend hardcoding a 1024 or 2048 bit RSA public key into the client. The encryption only really needs to be one-way as login details should never be sent back to the client.
Which only really works if you never distribute the server…like an MMO. Otherwise if you expect players to have their own servers then they’d have to somehow set their own keys also.
It’s nice in that it prepackages all the authentication and identification aspects, and you don’t need to be a rocket scientist to correctly assemble all the components of a secure protocol.
It’s limited in that it cannot handle UDP. And you want UDP if you’re doing anything remotely time-critical outside your LAN.
A somewhat less relevant limitation is that it assumes 100% trustworthy certificate authorities, and theory has predicted and practice has confirmed that that is not the case - several CAs have been hacked, and many CAs have been forced to serve local authorities by law.
This is not a problem if you just want to keep script kiddies out.
If you handle low low-level monetary amounts (subscription fees for an indie MMO etc.), this can work but your business might become collateral damage.
If you handle high monetary amounts (successful MMO with millions of players, gambling or betting games), organized crime and possibly multinational corporations will start to target you, and tiny security holes will be a problem. Make sure to hire a security expert before you move that kind of money, and handle the encryption in a single central module so the expert can fix any problems without touching the entire codebase.
If you do something that makes intelligence agencies target you - well, good luck to you It’s unlikely that JME programs will ever run into that category though.
I know a bit about encryption and attack vectors etc., so if I have the time I’d probably roll my own DSA infrastructure.
If I don’t have the time, or if I were somebody with no specialist knowledge, I’d indeed stick with SSL, it’s the best available effort-to-effect ratio.
If you have to encrypt time sensitive stuff on UDP packets then I think you’re going to have a bad time.
The very nature of the type of data you’d want to send encrypted means that you also want to avoid blasting them as unreliable packets… you want a secure data stream. SSL has the benefit of already doing the hard stuff. UDP support is a non-argument to me.
