My additions to: Old proposition for an update to the login handling system for Minecraft utilizing public key cryptography and user login certificates.

Minecraft Login Protocol Version 14 ab

Roles: (They are all standard names for this kind of thing but why not)

Alice (The end user / the minecraft client software)
Bob (The Minecraft Server the user wants to connect to)
Trent (The Minecraft.net Server)
Eve (The hacker who is trying to impersonate Alice and connect to Bob)

Before anything happens, Alice generates an RSA Keypair and both Alice and Bob get a verified copy of Trent's public key wrapped in a certificate with full chain of trust signatures resolved which is also fully valid for login.minecraft.net.
Alice's public key will be known as APK.
Trent's public key will be known as TPK.

This proposition includes alternate verification. Standard login is known as protocol 14A. The optional extension is known as 14B. 14B can only be used if 14A has been used recently (Specifically if APK's hash is still present and valid in Alice's revokation list)
// LOGIN PROTOCOL 14A
First, Alice generates a random nonce known as ARN. She then encrypts her Password using this Nonce as the key, the result of which is known as AEP. Then, she encrypts the Nonce and the encrypted password using TPK. This result is known as TEP.
Alice connects to Trent (The connection from earlier can be reused if it's still valid).
    Alice sends Trent her Username, TEP, If she requires verification, and her Public key and that she's logging in using protocol 14A.
        Trent now begins decrypting TEP.
            He decrypts TEP using his Private key, and gets ARN and AEP.
            Then, using ARN as the key, he decrypts AEP to get Alice's password.
            Then, he checks to make sure Alice's password is correct.
            Now that Alice has verified, he generates a login certificate containing APK, Alice's username, if she requires verification, the current time, and a timeframe for which the certificate is valid and signs it.
            The signed Login Certificate for Alice is now known as ALC.
            /* The following is only used if Trent wishes to implement Protocol 14B.
            He also stores a hash of APK in Alice's revokation list.
                If this hash is already there, it simply updates the last used time.
                Note that if a hash is not used in a timespan it CAN be removed from Alice's revokation list.
                Also note that Trent can limit the number of hashes per user.
            */
    Trent then gives Alice ALC encrypted with Alice's public key. // Fixes replay attacks
    Alice decrypts ALC with her Private key, and then verifies it has her public key and Username, and verifies the signature using TPK.
    Alice Disconnects.

At this point, the following is true.
APK: Public
TPK: Public (Verified)
ALC: Public (Signed) (Verified)
ARN: Secure
AEP: Secure
TEP: Public (Encrypted with TPK)
Alice's Username: Public (Verified)
Alice's Password: Secure (Verified)

// LOGIN PROTOCOL 14B
Alice requires a signed and verified copy of ALC AND the matching private key for this protocol. If she does not have it, she has to fallback to protocol 14A. This signed copy of ALC and Alice's private key should only be saved to disk if the user specifically selects Save Login Credentials.
Alice connects to Trent and sends Trent ALC and that she's logging in using protocol 14B.
    Trent verifies that ALC is valid.
    He then generates a hash of APK and checks it versus Alice's revokation list.
        If it is not there, authentication fails.
        If timeouts are required, and it's out of date, Authentication softly fails, with Trent informing Alice to fall back to 14A.
    If the hash is there and valid Trent updates the signature on ALC as well as updating the Valid timeframe.
    The updated ALC is then encrypted using the contained APK and sent to Alice.
    Alice decrypts her new copy of ALC and has authenticated sucessfully.

At this point, the following is true.
APK: Public
TPK: Public (Verified)
ALC: Public (Signed) (Verified)
Alice's Username: Public (Verified)
Alice's Password: Secure (Verified via ALC)

// NOTES WITH PROTOCOL 14B
If Alice changes her Password using the Minecraft.net website, ALL SAVED HASHES IN HER REVOCATION LIST SHOULD BE REMOVED.
The Minecraft.net website should also support viewing and removing hashes in the revocation list. This should include the IPs that last used those hashes, and when they were last used, so that in case a copy of a copy of ALC and Alice's Private key was aquired without Alice knowing, she can disable usage of it when she finds out.

// SERVER CONNECTION
Alice now wishes to connect to Bob.
    Alice combines the current time, and Bob's IP address, and her IP address (attempt to get public ip) and signs it. This is combined with ALC (not signed by Alice) to form Alice's Login Request (ALR). // This allows Trent to track server connections.
    Alice connects to Bob and sends Bob ALR.
        Bob verifies ALC's signature using TPK.
        Bob verifies Bob's IP from ALR and verifies that the time is within some reasonable range. // NOTE: He does not verify Alice's IP as there is no way to guarantee that this is available.
        Bob encrypts ALR with TPK to form Bob's Alice Login Request (BALR). // NOTE: Bob does not include the IP Alice connected from (as opposed to what Allice said) as there is no way for Trent to verify this.
        Bob sends BALR to Trent.
        If Trent is available.
            Trent decrypts BALR.
            Trent checks if the hash of APK has been revoked. // And now knows that Alice connected to Bob for tracking purposes.
            Trent signs the result of this check sends it to Bob.
            Bob verifies.
            If APK has been revoked, fail and add the revocation to its local list.
        If Trent is not available.
            Optionally record ALR to later sent to Trent when he is available.
            If ALC requires verification, fail.
            Bob verifies that APK is not in its local revocation list.
        Bob then generates a random key known as CSK and encrypts it with APK, which is known as ESK.
        Bob then sends Alice ESK
    Alice decrypts ESK using her Private key to get CSK.

    From this point on, all traffic is encrypted with CSK using a Stream cipher. Packets can optionally include a MAC if that type of packet is flagged as security critical, such as Chat packets. If a packet if flagged as security critical and the mac is not there or not valid that packet is dropped entirely OR Alice is disconnected from the server.

At this point, the following is true:
APK: Public
TPK: Public (Verified)
ALC: Public (Signed) (Verified)
ALR: Public (Signed) (Verified)
BALR: Public (Encrypted with TPK)
BALR Response: Public (Signed) (Verified)
CSK: Secure
ESK: Public (Encrypted with APK)
Alice's Username: Public (Part of ALC) (Verified)
Alice's Password: Secure (Not transferred) (Verified via ALC)

// REVOCATION PROTOCOL WITHOUT TRENT
Alice wants to revoke APK and TRENT is unavailable.
    Alice must have ALC.
    Alice combines APK from ALC with the revocation payload (currently undefined) and signs it. This is Alice's Revocation Request (ARR).
    Alice combines ARR with ALC and sends it to Bob for each Bob in her list of known servers.
        Bob verifies ALC using TPK.
        Bob verifies ARR using APK from ALC.
        Bob adds APK to its local revocation list.