Obscurity is not good Security

Started by
26 comments, last by hplus0603 18 years, 8 months ago
Quote:Original post by mr BiCEPS
I see that you're from the USA. I thought the export restrictions on crypto there were lifted years ago?


I don't think so [Unless that is outdated or irrelevent, didn't read it too much] I really don't keep up with encryption export laws so I wouldn't know, Its just a waft of information I picked up and thought I should be conscious about.
Advertisement
Quote:Original post by hplus0603

5) If you find yourself shifting goals towards banning the maximum number of people, then you're in trouble.


True to a point... When I worked on UO we banned everybody we could, of course we could afford it at the time. The exception to that was a little tool called "UOAssist". Anyway, if you do what Mythic did and 1) believe your game is unhacked, and 2) let radar get so far out of control that 30% of your players are using it, then obviously you can't ban them all.

I don't know if Mark Jacobs really believed that people weren't hacking his game or if he was just telling people that, but I think it cost him. To this day they still post about bannings. Then they claim they only banned a few hundred people, while thousands are still running loose with hacks.

Amazing.



Quote:Original post by krum
1) believe your game is unhacked, and 2) let radar get so far out of control that 30% of your players are using it, then obviously you can't ban them all.


Was this comment in regaurds to the Y max allow with random Z checkpoint method I described? Or are you referring to a different matter entirely. I'd really rather stay on-topic because I'd like to get as much info about making a secure OSS Online game as I possibly can.
Quote:Original post by Falados
Quote:Original post by mr BiCEPS
I see that you're from the USA. I thought the export restrictions on crypto there were lifted years ago?


I don't think so [Unless that is outdated or irrelevent, didn't read it too much] I really don't keep up with encryption export laws so I wouldn't know, Its just a waft of information I picked up and thought I should be conscious about.


Doesn't seem outdated, the last date referenced tehre is Dec 9 2004, which isn't too long ago. The page, and the page linked with more information, don't seem too specific on how large keys you can export without a specific license.

Some laws, such as these, suck. Totally obsolete law.

Edit: Wikipedia has a pretty good article about crypto export.


Quote:
Legal challenges by civil libertarians and privacy advocates, the wide spread availability of encryption software outside the U.S., and the perception by many corporate interests that adverse publicity about weak encryption was limiting their sales and the growth of e-commerce, led to a series of relaxations in US export controls, culminating in 1996 in the effective elimination of export controls on mass-market "shrinkwrap" and open source software containing cryptography (which, in any case, a "rogue state" could have downloaded, and subsequently verified, from file sharing networks or servers outside the US).


[Edited by - mr BiCEPS on August 11, 2005 4:48:17 PM]
Quote:I need a find a way to make it both secure, and still not have the server, in essence, play the game for all its connected players.


Well, good luck with that!

I wouldn't even try, because any system that relies on peers can be hacked with determined peers. Your best bet is to solve the problem through game design.
enum Bool { True, False, FileNotFound };
Quote:Original post by hplus0603
Well, good luck with that!

I wouldn't even try, because any system that relies on peers can be hacked with determined peers. Your best bet is to solve the problem through game design.


Any specific design pitfalls to avoid?

Quote:Original post by Falados
I would like to design this project to combat cheating as much as possible. Most of the time, closed-source projects have an easier time because they aren't exposing the client-side network protocol,


1. No, they don't. This is a fallacy promoted by people who've generally not tried writing closed-source projects and are working from a position of "thought experiments", i.e. "no idea what they are talking about". Don't worry about the open vs closed debate: closed-source games today are written with the assumption they are open-source anyway ;).

2. You could read Game Programming Gems 5, "Secure by Design", on the topic of how to make your game secure, especially if it's an online game. It doesn't tell you how to do encryption etc, but it gives you a framework to let you find out whether it's even worth bothering doing encryption etc. (disclaimer: I wrote that. So, I'm biased. I make something like $ 0.01 if you buy a copy of the book)

3. Encryption is generally worthless in games, just assume you don't want to do it. Anyone who thinks it's a good idea you can safely assume they don't know what they're talking about w.r.t games, and demand a damn good justification before listening to them. Ditto with many of the other tools in the security-programmer's toolbox - most people don't really ask themselves "but, does it actually make the overall game any more secure *at all* if I do this?" and the answer is often "no" :(.
Quote:Original post by krum
Quote:Original post by hplus0603

5) If you find yourself shifting goals towards banning the maximum number of people, then you're in trouble.


True to a point... When I worked on UO we banned everybody we could, of course we could afford it at the time. The exception to that was a little tool called "UOAssist". Anyway, if you do what Mythic did and 1) believe your game is unhacked, and 2) let radar get so far out of control that 30% of your players are using it, then obviously you can't ban them all.


Blizzard never let it stop them. They seem to be doing quite well these days. YMMV...
Quote:Original post by MENTAL
The only thing the client needs to send is the direction the player wants to move in (NOT the new location of the player - the server works that out for itself) and any actions the client wishes to perform.

The server sends the client details about what is currently visible to the client - nothing else. If you keep to this rule the only thing the player can do is reprogram the client to do repetitive tasks automatically (i.e. like mining), which should be easy to pick up on the server.

Don't even send any monster detail other than which model it uses and which animation it is currently performing - the client simply doesn't need to know.


Server side all the way. Authenticate and validate *ALL* actions. Make sure if client picks up magic sword + 9000 that magic sword +9000 is actually there! Dead reckoning all the way I feel is the best for clients, they are glorified video terminals. The more stupid they are and the more helpless the client code is the better. All it needs to do is send messages for movement and to interact with the environment (pickup item, attack, etc). It's physics should be very basic and stupid, only what is necessary to update the display. It's actions must be properly validated on the server. Client should never have the power to attack/damage anything. Client is very untrustworthy, any oppurtunity you give it it will take and abuse.

I think it is impossible to develop a secure encryption scheme open source. Think about it. No matter what you do, the client has both the algorithm and code. He/she can debug the code while it is running, and set breakpoints, catch data. There is no way to protect against that I can see. So Secure sockets is maybe the only way to do it. I could be wrong of course, but I can't see how an Open encryption scheme could ever hope to work.

And another thing of course is the client has the source code... so you need to make sure there is absolutely NOTHING they can do without being authenticated through the server.
"It's such a useful tool for living in the city!"
I might be way of base here, but here some rambling about public key encryption

essentially it only stopps tampering with the data between the client and server. Without it I can get away with an unmodified client and I can have some computer on my network sending additional "attack" packets or have that computer modify packets of things my client would decide not to show to make it always visible . However, it would just be easy enough for me to modify the client to do that myself, particularly if it were open source. <br><br>will the server be open source? or just the client?

This topic is closed to new replies.

Advertisement