Ronin Security
Since Ronin involves a serious investment of time and money by the users, ensuring the security of that investment is of utmost importance. Players must be confident that their valuable armies and strategic position will not be altered by hackers or other blackguards. Specifically, Ronin security must solve the following problems:
When a player logs into Ronin, the player must provide a username and password. In response, the Ronin server allocates a new unique session identifier (SID) for the current session. The SID is recorded in the player database and sent to the player. This transaction is conducted using a secure socket layer (SSL) which ensures that the information is unintelligible to anyone listening in on the connection. The SID is used to authenticate all connections made on behalf of the player throughout the lifetime of the session. Exhaustive password guessing will be thwarted by a limit on the number of retries allowed. After a few failed attempts, the user will be disconnected. Since re-establishing a connection will take at least a few seconds, exhaustive search will be impractical. Also, the server will keep track of failed login attempts and the IP address from which the attempt was made. If too many attempts come from the same IP address, or within the same window of time, the administrator will be notified.
Ronin cards come with a security code that is used to activate the card and have the character on the card made available for play. These codes will be randomly generated such that only 1 in 1000000 possible entries will be correct. Initially, each code will be 7 digits from a set of 64 possible digits (upper and lower case letters, numeric digits, and a few typographic symbols). This will allow us to have an initial capacity of approximately 4,398,046 cards. In the event that this is not enough, later cards can be issued with more than 7 digits to maintain the desired distribution.
Two mechanisms will be used to make the system robust against brute-force assault. First, like the login mechanism, the server will disconnect a user if 3 (or some other small number) consecutive erroneous activation codes are entered. Due to the overhead time required to log in to Ronin, this will make it ridiculously time-consuming for a user to attempt to exhaustively try activation codes until a correct code is found. Secondly, the Ronin server will keep track of the number of times a user has entered an erroneous activation code. The Ronin administrator will have access to this information and can detect users who are engaging in this activity.
On the off chance that someone is able to guess the activation code of a card, Big Fun will maintain a liberal policy of replacing cards that have been activated by someone other than the rightful owner.
In the general case, Ronin will be secure against alteration by the fact that important computations will occur on the Ronin servers. Since the client software is primarily a user interface, changing it will offer no advantage. The important exception to this rule is in the case of a battle. During a battle is when most important changes to character information occur (death, change of allegiance, etc.), yet Ronin battles will be executed on the local machines of battle participants. So what is to stop a player from altering the client code to produce more favorable results? The answer is that all Ronin battles involve synchronized computation between all parties involved in the battle. The players in a battle perform independent deterministic computations on shared input information. Divergence will be detected by the receipt of impossible inputs from other players. Also, at the end of a battle, all players will be required to check in the resulting information to the server, which will make sure that they all agree.
An important part of the Ronin model is that some of the server-side functionality can be distributed across a network of machines allowing salability of the system. As the game progresses, the client software will request various connections as services are required. Most importantly, there will be a service that allows character information to be updated as the result of a battle. It is important that illegitimate connections to these kinds of services cannot be made. The mechanism that will be used to protect these connections is the use of SIDs mentioned above. All important communications will be authenticated using the SID of each player involved, communicated using SSL. In the case of a battle update, the SIDs of all players involved in a battle will be required for an update to take place. As another precautionary measure, each player's IP address for a session will be recorded when the player logs in, and communication from a player will only be allowed from that address.