CORDIAL MINUET ENSEMBLE

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.

[1] - http://security.stackexchange.com/quest … ll-our-own