[fatjonny]

If you can trust the client by having them enter in a password, can't you then set up a system that uses the same idea as public-key cryptography (http://en.wikipedia.org/wiki/Public-key_cryptography)? Once the user has logged in and authenticated with their password they generate their public and private keys and send the server the public key while keeping the private key local. This method would be processor intensive, but good security usually isn't cheap. Or maybe my understanding of how public-key cryptography works isn't accurate and someone can explain why it wouldn't work?

[wmf]

Here's the attack: The user writes software which performs the same authentication handshake as the official client, but after the handshake it starts sending evil messages to the server.

[fatjonny]

Isn't that where the password comes into play? Basically you authenticate once by passing the password and the client generated public key to the server. The server checks the password and then if it matches it sends all future communication to the client encrypted with their public key. It can generate a new "public" (in quotes because it will only be shared with the client) key specifically for that client and send it encrypted to the client using the public key passed along with the password. All communication from client to server will be decrypted with the private key that matches the public key given to the authenticated client, and all communication from server to client will be decrypted with the private key that matches the public key the client gave to the server with the password. This is probably more like TLS or SSL (http://en.wikipedia.org/wiki/Transport_Layer_Security) than I suppose. Which makes me think you could just use an SSL connection since it is supported (http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/...).

Or am I really missing something and should just stop commenting? :)

[thwarted]

The password as the basis for authentication and generating the encryption is useful in this instance to be able to "blame" someone when they are using your service incorrectly. At the very least, you can notify someone to change their password because their account has been compromised. You know _who_ is responsible for the request because it was authenticated.

In other words, your EULA/terms-of-service is a long the lines of "you are responsible for the user of this service using your login credentials, which can be revoked at any time if we perceive you to be violating the terms of service". Then becomes a little more manageable as a social problem (which it is), rather than solely relying on a technical solution to a social problem.