So... This is a method that I had tried when I first created PO. It lagged too much then (from my handmade code, generating RSA keys with bigints with non-optimal multiplications), but now that Crypto++ supports it correctly... Generating a RSA key from a password. Client-Side, you'd generate a private RSA key just once - from a password you type. That way you can use the same key on other clients without issues. The authentification would go like this: -> Server challenges -> Client gives public key -> Server checks public key matches hashed key with salt stored in database -> Server gives challenge string -> Client gives encrypted string -> Server checks that it's encrypted correctly (using the public key it still has in memory) That way, you don't even need to enter a password when logging on a server. Cryptico could be used in javascript Reading
Servers would provide backward compatibility obviously, and client/android client would have a simultaneous update.
Why would you generate a RSA-key from a typed password? Would this be for key recovery? This leaves the user open for several attacks. 1) The keys will have the same entropy as the original password. This means that dictionary attacks and brute-forcing is still possible. 2) The keys can be stolen. This is the same as with all password-less logins. 3) You now have a secure login, but the connection is still unsecure. A real hacker can spoof the connection and change the stored hash of the public key. Problem 1 can be solved by using random input like the Truecrypt use, and like ssh-keygen. Or by using a standard solution like SSL/TLS. This however makes account recovery without user information impossible. Problem 2 can be solved by encrypting the keys with a password. Which, I understand, you don't want. SSH supports this, I don't know if SSL or TLS support this. Problem 3 can be solved using the SSL/TLS transport protocol. Standard libraries have support for keys to authenticate both parties. Personally I think Pokemon Online is not serious enough to need cryptography for authentication. Especially when secure connections aren't implemented yet. Using a standard library is your best shot at getting a secure implementation. My experience: I read a book on cryptography once(Just kidding, multiple books). I have an interest in cryptography and read a lot about it. In my opinion standard solutions are secure, easier, faster to implement and faster to work. Sources: http://happybearsoftware.com/you-are-dangerously-bad-at-cryptography.html I would have recreated most of the examples.
I know that the keys are the same as passwords. Brute forcing would be a lot more complicated though, given the time it would take to generate a RSA key. Keys can be stolen, well, if you store your password using po's autosave it's basically the same problem. If you don't, you could regenerate the key everytime the user launches PO too. Spoofing is something different, the framework we use allows the use of SSL connections easily, so if we wanted to address this we'd just give the registry a public RSA key (also in the client download) and servers communicating with the registry would give their public keys to the registry, so the registry can "authenticate" any servers for the client. (and once they've connected once to the server, they have the server's public key on file). Then this topic's solution would just be to use standard SSL everywhere, except that the client can recreate his private key based on a simple password. (and he better make it secure if he has sensitive stuff) My main problem at the moment is this: Say that you use the same password on several servers. Server A is the main server you go to, Server B is another server, and they want to steal your access to Server A. Currently all they need to do is to get the salt Server A has stored for you (by trying to log in with your name). Then when you try to login to Server B, they give you that salt, and if you use the same password there, you'll give them the hash (salt+password hashed) that will allow them to connect to Server A by impersonating you. That kind of problems wouldn't happen with the solution in this topic. Other issues like hardcore spoofing can be dealt with too, but then it's really serious business.
But that threat isn't solved by the proposed algorithm. Suppose Alice is a client, Eve is an evil server, Bob is a normal server. Eve wants to impersonate Alice on Bob's server. Alice connects to Eve, sends her public key. Eve connects to Bob, sends the public key of Alice to Bob. Bob challenges Eve, Eve challenges Alice. Alice signs the challenge, proving it's her. Alice sends her signature to Eve. Eve send the signature to Bob. Bob accepts, Eve accepts. Eve is impersonating Alice on Bob's server. SSL also guards against this problem using mutual authentication (the server also requests a certificate from the client). Bob requests a certificate of Alice(normally) or Eve(the attacker). Alice then signs the handshake until that point. Thus Eve can't misrepresent Bob or predict that value.