??????
You are not logged in.
Pages: 1
First and foremost, let me say that I find this game extremely interesting. If the legality of a game like this holds up I think it could really become something.
That said, as the game concerns movement of money, I'm particularly sensitive to security. I'm a software developer so I apologize if some of this is overly technical.
First, let me describe my experience signing up for the game. I create a new account by providing my credit card information. I'm then provided with a generated "key" to log into my account. Finally, the plaintext key is emailed to me for "safe keeping."
Additionally, in another post, Jason notes that "Well, the client NEVER sends out the account key. It assumes that someone is listening on the wire at all times (so it's safe to play over coffee shop wifi)."[1]
My worry is that the idea that the client never sends out the account key and the fact that I received an email with the plaintext account key don't seem to add up. Either the server is generating the key and then sending the HMAC'd key along with the plaintext key to the client (it displays the plaintext key after registration) or the key is generated on the client and then _must_ be sent via plaintext to the server because I receive it in plaintext via email. Also, HMAC'ing on the client seems impossible because the signing secret needs to be somewhere that is not controlled by the user.
Finally, I find it greatly worrying that I have no way of rotating or changing my key as it is essentially my password that can be used to access any funds I've deposited in the game.
I'd love to hear Jason weigh in with the actual implementation here. I'm curious why he didn't take the tried-and-true method of storing a hashed password on the server (e.g. bcrypt) and sending the plaintext password via HTTPS (with certificate verification) on login, hashing on the server, and verifying the hashed password with the stored hash using a secure compare. It seems to be a best standard for web development that would translate just fine to this game.
Thanks!
Offline
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.
Offline
Jason -
Thanks for the response! I appreciate you having an open dialogue about this as I think it's an extremely important aspect of an application that essentially moves money between parties. I have a few follow up questions / comments to some of the points you raised. I should note that although I work in an area of software development that has security implications, I am not a cryptography expert.
"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."
I'm assuming you mean Elliptic Curve Cryptography.
"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."
Does the client actually use my key to sign each request or does it use the public ECC key that was previously used to pass the generated key to the server?
"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."
The fact that you're able to send the key via email in plaintext leads me to believe that you're either storing the key in plaintext on the server or storing it in some symmetrically encrypted manner that allows you access to it when necessary.
"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)."
While I understand the intent here, it appears to me that you're mixing two orthogonal concepts here: authenticity (signing) and authentication. Also, the phrase "access to the server on the user's behalf" seems to exactly describe authentication, right?
"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."
Why would you generate digital signatures from a password at all? The password is simply used for authentication, it wouldn't need to be used as source material to generate the keys that you're using for signing requests.
"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.""
This game seems fundamentally different from your previous games (which I've greatly enjoyed, by the way) because it moves around real money. Because the account key appears to be generated and stored on the server (maybe I'm missing something here), if there was a successful attack on the server the attack would have access to the keys for every account. Rather than doing something obviously malicious, they could simply use these keys to act as any individual in the system. Furthermore, even if a user suspected malicious activity on their account, they have no way to change their compromised account key.
"Essentially, don't burden the user with creating a password if you don't really need a password."
In the trade off between convenience and security, I think you need to default towards security when money is involved. I don't mean to question your qualifications as a developer. Clearly you've shipped many successful, real projects in the past. That said, I'd really like to see something like the following for authentication:
0. All communication is performed HTTPS with certificate validation.
1. An account is created and an email and password are provided.
2. The password is hashed using brcrypt and stored on the server.
3. Your ECC key pair is generated on the server and is completely unrelated (in generation) to your password and passed back via HTTPS.
4. The client does not cache authentication and requires a login each session.
5. There is a "reset password" button that sends an email with steps to reset your password to the provided email.
I know that HTTPS has had its share of problems recently, but it's the best we've got. HTTPS + bcrypt (or similar) for password hashing does the heavy lifting of authentication for so many major applications that deal with similar security concerns. And it's generally always better than rolling your own crypto[1].
Thanks again for taking the time to discuss this.
Offline
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:
You can roll your own, but you probably will make a major security mistake if you are not an expert in security/cryptography or have had your scheme analyzed by multiple experts
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.
Offline
Thanks much for your detailed responses. It's very helpful to have a more low-level understanding of the security features here and your thought process in creating them.
I'm also glad to hear that there's a bounty, great stuff.
Thanks as well for being open about this, I hope it will lead to more trust in the system used to move the money.
Thanks for a(nother) great game.
Offline
Also, I had no idea the source for the game was available. I'd love to see more people do this. Cheers!
Offline
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.
Offline
That $3000 hacking challenge is an amazing idea. Sony Pictures should have done it long ago...
Offline
Internet-facing companies which actually care about security run bug bounty programs. Sony Pictures' senior vice president of information security is infamous for not valuing security.
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.
In terms of identify theft/malice, definitely. I'm OK with the way it is because I would have a hell of a lot of other problems. I use my email account for everything, yet the few dollars in my CM account are the only funds of mine that I can think of that could be accessed via it. There's a reason that banks don't provide a way to reset your password online.
Offline
Pages: 1