CORDIAL MINUET ENSEMBLE

There are currently 14 people playing in the tournament, it seems.

So much for attracting 100+ of players back.

Oh, sure, that's fine.  Playing with a full bot is also fine.

Well, the good news is that "credit card numbers" are not involved, beyond the initial charge.

Having someone lose the $20 or even $1000 that they put into Cordial Minuet due to an attack would be bad, but having a bunch of credit card numbers leaked would spell doom---there would be no limit to how much someone could lose.

The other good thing is that there are stops in place (like $600 tax reporting limits, etc.) before big withdrawals happen, so an attacker that stole a bunch of money would have some hoops to jump through before running off with it.  The server keeps a ledger of every penny-fraction that moves in the game, so you can reconstruct how someone who has a lot of money got that money.  Thus, in the case of clearly ill-gotten gains, it would be possible to return the money to the accounts where it came from.

Yes, I meant Elliptic Curve Cryptography.  The ECC key pair has no relation to your account key.  It is generated through cryptographic random number generators on both client and server.  The server's secret key is fixed (was generated by me, long ago), and the client ships with the public half of that server key.  The client generates it's own secret each time it needs to (like, to send a CC number to the server) using its platform-specific crypto random number generator and sends the public half to the server.  The client will fail and give up if the platform-specific random number generator misbehaves.

Yes, requests are signed via SHA1-HMACs using the account key as the HMAC key.

Yes, the account keys are stored in the clear in the server database.  If the server is compromised, all bets are off about money not moving where it shouldn't move, no matter what security mechanism I used.  Better to store a key that only affects this game and not a salted password hash that will get dictionary-attacked and compromise all other accounts where the user has the same password, especially since a password isn't needed here (user is playing from one, trusted computer, not logging in through the web or something).  The server does not store credit card info.

The only security function needed here is signing each request to prevent actions from being taken on the user's behalf, even if someone is listening on the wire, intercepting traffic, etc.  Most of the requests do not contain sensitive information (except the CC number, which is encrypted using ECC in isolation).

You're saying to do it through password over HTTPS (send password with each new request, check password hash on server), but this is much more lightweight (no libraries, tiny source files for SHA1 and ECC), easier to understand, and fits the specific need here, and does not depend on user password strength (or secrecy) for security.

In terms of sending the key "in the clear" to you by email, if your adversary has the pipe tapped between my email server and your email server, and has broken the encryption used between those email servers, then your adversary exceeds my threat model.  You've got bigger problems than losing your Cordial Minuet money---you're probably on your way to jail for something else.

If I used passwords, your password reset link would be "sent in the clear" too, making that password no more secure than what I'm doing.  And passwords are the weakest link in most security systems because of the human factors involved.  Avoid passwords whenever possible.  (Like, the next Sony leak or whatever will not make any Cordial Minuet or Castle Doctrine users more vulnerable to being hacked, unless their email gets hacked).  Finally, there would be all that password infrastructure (emailing reset links, a web page for people to change passwords, etc.) that would need to be securely coded.  If passwords aren't needed, better to avoid one more door that needs its own lock.

"Best practice" here isn't really best practice.  If it was, there wouldn't be so many security breaches.

In terms of my qualifications, I've been designing security systems using cryptography in one form or another since 1998 or so, and one of my secure systems (not a game) has been downloaded over a million times, and I've been invited to speak on the subject.  If there's a hole in my system here, please point it out and I'll fix it.  But "you're not doing it the way everyone else is doing it" isn't a hole!  :-)

From Stack Exchange:

I see one place where passwords would be better than what I'm doing:  if the server data is breached in a read-only way, then anyone with a strong password would be protected (weak passwords would be dictionary attacked), whereas every account would be breached with my mechanism.  The trade off is that people with weak passwords would likely have other off-site accounts compromised by the breach, whereas the breach would be limited to Cordial Minuet using my mechanism.

To surpass password security in the case of read-only data breaches, the server could maintain an encryption key outside of the database and use it to store the account keys in encrypted form.  I didn't do this because I felt like it was pseudo-security (if they can read the database, assume they can read the disk too and get the key), but in the case of an SQL injection attack that dumps the database, this would work.

A read-write data breach counts as game over in my model, which is why the server is secured using two-factor, physical authentication.  I supposed the above change would secure the server against read-write SQL injections, because the attacker wouldn't be able to replace keys in the database without accessing data outside the database.

But anyway, I'm parsing all user-supplied data with regexps to block SQL injection, so I'd rather work under the assumption that the server can store site-specific secrets in the database.

Oh, and there's also a standing $3000 bounty for finding a security hole in Cordial Minuet:

http://cordialminuet.com/hackingChallenge.php

The bounty has been standing for nearly three months.

Your account key is sent to your client by the server exactly one time:  when your account is created.

And it's not sent in the clear, but through a shared secret between the client and server derived through a 256-bit ECC key exchange mechanism.  This is the same mechanism that is used to encrypt your credit card number in the client before it is sent to the server.

After that one encrypted transmission, your key is never sent between the client and the server again.  The client uses your key to sign each and every request to the server, however.

The key is sent to you by email because it is assumed that your email is secure.  If hackers get into your email, I'm assuming that you stand to lose much more than just your Cordial Minuet money.

And why not a password?  Well, a password doesn't make a very good key to use for digital signatures.  You have to trust the user to create a good password.  Since you don't want to send the password through email, you have to trust them to remember it and have a reset mechanism.

In this case, it's really not a "password" that I need here, but an encryption key, and I'm not using it to protect access to the user's client, but instead access to the server on the user's behalf.  Thus, I never ask the user to type it in or otherwise memorize it (unless they install a fresh client on a new computer).

So... instead of dealing with passwords like "1234" and "letmein" and all that, and forgotten passwords, etc... I just went with a real encryption key and gave it to the user by email for safe keeping, and left it at that.

If someone captures your CM traffic, and if your digital sigs were generated by an easy-to-guess password, then a dictionary attack would allow them to quickly figure out your password from the capture sig.  In the current implementation, your captured signatures would still leave them searching the entire 100-bit keyspace.

This has become a tried-and-true method of mine over my past four games.  This is the way all 20K Castle Doctrine accounts are secured, and I've never had a report of a hacked account or a need for a "password reset."

Essentially, don't burden the user with creating a password if you don't really need a password.

Caught me!

Yeah, this is just an experiment.  How many games will be played that day?  There's an extra rake that will be in effect (at least 10 chips from every tournament table, which is 5 cents).  Still... 4000 games would be needed at that rate to cover the $200 prize.  Well, that's only 20 games per person if everyone plays.  6 minutes per game.  Possible, but unlikely.

There are other options for funding prizes... for example, there could be a larger fixed table rake, and the prize pool could grow as that rake accumulates.  There could be a weekly prize like this, for example (top player of the week at some stake level).

Welcome!

The ordering is intentional.  They are NOT in alphabetical or numerical order.

See if you can figure out what order they are in...

You're right about the differences between CM and poker in terms of the possibility of mounting uncertainty in Poker.  Well, not exactly... in poker, certainty can mount too.  The point is, in Poker, additional cards can change everything, whereas in CM, additional numbers are additive to your score.

I've now lost the term for this... it has something to do with partial ordering, but that's not all.  Essentially, in CM:

If X < Y and C < D, then X + C < Y + D.

This is NOT true in Poker, where X could be 22, Y could be AA, C could be 2, and D could be K.

Essentially, as more cards come out, the partial ordering is not preserved.

Math people:  what's this property called?

I'm not totally happy that CM doesn't have this element.  I've thought about ways to add this element (like, giving a bonus for 3 odd or even numbers, or 3 numbers under 10, etc.), but some of that stuff (sets) feels too much like existing games.

Yeah, I like this kind of thing!

So... the "game ID" isn't exposed in the protocol (otherwise, you could easily make a chat room for a given table).

HOWEVER, you could still do it according to board layout, because all boards are unique.

You'd have to code up a little web proxy that intercepted the CM protocol, scraped the board layout out, and then used that to connect two people together in a separate chat room.

Or even easier, you could just let people type in the top row of their board into the "join chat room" interface.... hmm... well, that wouldn't match the players up... maybe match them by "numbers that are around the 36?  So you would type in between 2 and 4 numbers, and that would let you join a room with your opponent, and then stay there with them as long as you want (you'd only have to match them on one board).  Still, they'd have to both join on the same board for this to match them together.

Or make separate chat rooms based on stake level?  So, you could be chatting in the 0.01 room or the 1.00 room.