On 03/17/2010 05:05 PM, Bob Kerns wrote:
Yes, SHA-1 is what you should go with. It's really a matter of just
requesting a different engine; the API doesn't care which one you use.
One thing to consider is that a salt doesn't prevent replay attacks.
If you want to prevent people driving up their score by replaying the
packets already sent, you may want to include a nonce in your
protocol.
I'd suggest using a secure random, and the current time, and remember
recent nonces, and reject anything that's either not recent, or has a
nonce that's been recently seen.
Ie, a Kerberos-like replay cache :) I sort of wonder how often
they actually need to send results up... if it's pretty infrequent
and/or not very intensive, is there a reason to just not use TLS
to deal with _all_ of these problems, and way more (like MITM
attacks, etc)? I know it seems heavy handed, but it's just a matter
of changing http to https on the phone side of things. The server
side would need a cert, but that's not terribly hard to come by
these days, and you'd get the assurance that strengths and weaknesses
of MD5 and other arcane cruft is somebody *else's* problem.
Mike
It's easy too do -- and even if it's not necessary to have that level
of security, it's a good technique to be aware of.
On Mar 17, 2:27 pm, Kevin Duffey<[email protected]> wrote:
Hey Mario,
Thanks for the replies. So your salted md5 hash, do you generate one for
each player, or just one for your game, that is sent in with every
request by each game player (via your game code)? So this secret that you
concatenate, you hard code it in both the game code and your server code?
So some string like abcd123, append it, md5 the whole string, then send it?
I have been using SHA-1 for playing around, using the Java SDK api that can
also be used for MD5. Any benefit in using MD5 over SHA-1? I thought
SHA-1 was more secure/harder to crack?
I agree with you.. the chances of anyone sniffing the packets, figuring out
its game data, trying to decipher it, and for what purpose anyway.. is
unlikely.
However, for some reason, companies tend to shy away from anything that
isn't super industrial strength secure. I am also curious because I may want
to
allow the game player the option to use real currency in game to buy game
items. That may require a game player to set up some sort of credit card or
paypal account... not sure yet how this all works, but because of this there
may be a need to be "more secure", such as using TLS. What do you think?
On Wed, Mar 17, 2010 at 11:15 AM, Mario Zechner<[email protected]>wrote:
How about security? As a developer, do you have to get some sort of API
key?
Is it done over SSL/TLS, or both an API key and SSL/TLS? I am wondering
how
invovled the process is to get set up to actually use one of these
services... or for those of you that wrote your own, what do you do to
ensure it's your game calling the server side, and not some hacker or
another game trying to use it for free?
As stated in my post all data is submitted with an accompanying salted
md5 hash which the server can reconstruct. What you basically do on
the client is construct a string out of your data, salt it by
concatenating it with another string only you know about and then
calculate an md5 hash from that. On the server you also construct a
concatenated string out of the send data and salt it with the same
string you use on the client. If the md5 hashes match the data is
coming from an original client, if not someone is trying to hack your
server. Reengineering the salt string by sniffing the transfered md5
hashes is possible to my knowledge, however you'd need a shitload of
computing power to do so (and i really mean a shitload). Nobody has
the resources to do this and nobody is probably going through the
hassle to crack your game server anyways :)
I don't say that this is the perfect method, but it worked well for me
and a couple of my friends in various projects.
And an off topic question.. I see more and more people talking about
getting
a free phone from google? Is there some place you sign up to get this?
I'd
love to get a Nexus One to test on... sounds like some people are getting
just that.. a free phone to test on?
Thanks again all. More to come I hope.
On Wed, Mar 17, 2010 at 10:37 AM, Justin Giles<[email protected]>
wrote:
Just to throw it out there...
There's also Google Apps Engine:https://appengine.google.com
It's java or python based (your choice). The free quotas are rather
generous. I keep my high scores stored there for my apps and for one
of the
apps I have over 75000 active installs and I have yet to go over the
free
quota. You do get charged if you go over your quota, but the rates, in
my
opinion, are reasonable. Same basic idea as the MySQL and Rails
suggestions.
No, I'm not a Google fanboy, but with a free device coming sometime
soon,
if Google asked me, I'd sheepishly say yes sir, yes I am a fanboy :).
Justin
On Wed, Mar 17, 2010 at 11:25 AM, Robert Green<[email protected]
wrote:
Since no one else has responded I'll talk about what I did, though I
haven't gone cross-platform yet (which is why I didn't respond right
away).
I chose cross-platform technologies just in case I ever wanted to and
I know that they will work for it. What works well for me for my
leaderboards and turn-based multiplayer code is to use Ruby on Rails
with JSON as the encoding. It's supported natively by rails and
Android comes with JSON parsing and encoding. It's such a simple
protocol that one could easily write an encoder/decoder for any
platform, though I don't think you'd have to because I'm sure one
exists for almost every one.
There are many routes to go that will work fine, including having an
XML-based service. I'd stay away from things like Java Object
Serialization. That is not easily portable. I'd also stay away from
technologies like SOAP and WS. They are heavy and you want to keep it
light and simple usually on a phone and small server / high traffic
setup.
My first recommendation is to use Ruby on Rails / REST / JSON for your
basic server.
How it works:
Rails runs either as a plugin to apache via Phusion Passenger or
standalone via mongrel/other server apps.
Clients make requests using REST, which means HTTP Get Post Put and
Delete which query, insert, update and delete respectively.
The requests and responses are encoded in JSON, which is a simple
encoding, human readable and extremely fast to parse.
Advantages:
Any platform can implement a client for it.
It's very light and fast.
All of the necessary tech is inherent in rails and so this provides a
very low-resistance coding path.
Passenger (the apache plugin that runs RoR servers) runs great and is
easy to deploy and uses your standard web server.
You can actually easily run a game core written in Java wrapped with
the RJB (Ruby Java Bridge) - I do this for Wixel
Disadvantages:
Another language to learn (though I don't mind working in it at all,
it's really kinda nice)
Doesn't handle native code well (if you have a game core in C/C++ that
you need to access, it's a little tricky with Apache/Passenger/Rails)
Is only good for scores/leaderboards and turn-based games. You can
only update as much as you can push HTTP requests and process
responses. It's not good for real-time games requiring faster than a
second or two turnaround, though it can handle scores and accounts for
them fine.
If you want a cross-platform real-time game server, that's pretty much
what you need a robust game engine for. Most real-time games have
their own protocol and are inherently cross-platform because of that.
I'll be porting my engine this summer and designing it to be cross-
platform. Issues to overcome when going cross-platform are: Sound
handling, Image loading and processing (can't rely on your OS for that
anymore), Font loading and text drawing, How input is handled, How the
video context is created, Menuing systems, Networking, etc..
Basically you can't depend too much on any one convenience of a
particular OS and you kind of have to design the system so that you've
abstracted out the "connectors", that is, the input and output in the
form of user input in (touch/key/network/etc), sound, music, graphics,
vibrate, lights and network out. Each mobile OS will have a
particular set of hoops to get the connectors in.
With that said, many people would probably rather go with a solution
like Unity who have made it their mission to handle as much of that
cross-platform overhead as possible. I believe you can run a unity
server and connect to it from any unity client.
Hope this was a little helpful.
On Mar 17, 10:15 am, shaun<[email protected]> wrote:
We are considering the use of Scoreloop (http://www.scoreloop.com/)
to
add a social component to our games and apps. Since we have no real
experience in that arena, I'll just leave this link as my
contribution.
On Mar 16, 8:08 pm, Kevin Duffey<[email protected]> wrote:
Hey all,
I am curious how the various groups of game developers, primarily
mobile
(android in this case) and cross-platform
(android/iPhone/facebook)
handle
storing high scores, achievements, and such as well as how multi
player is
done.
How does your game(s) access high scores, update the list, remove
them
if
need be? The same would apply for achievements, and to a lesser
degree,
leader boards.
Are you using a service out there that you pay for... if so how
much
does it
cost.. and do they provide some sort of java/objective-c SDK that
you
can
just plug in to your code?
How do you dispaly high scores, leader boards, achievements, etc
in
your
game? Do you provide your own web site with the same info, perhaps
jazzed up
a bit more or with more detail than your mobile game (due to
limited
screen
realestate for mobile devices)? Do you provide a link to a web
site in
your
game if they want to see things like high scores, achievements and
leader
boards?
I would also like to know what sort of things are most important
for
your
games. High scores are so yesterday, so to speak. The latest craze
in
most
games seems to be achievements and the ability to obtain extra
items
for
your games, either by buying them,
...
read more ยป
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
