Day 4 Authentication Planning over SSL2

What I did: Authentication
Total time: 42.667
Comments:
Grappling with questions like 'authenticate then encrypt or encrypt then authenticate?'
Finding way to minimize the protocol and move session management to a higher level. This level should only be concerned about creating encrypted layer and ensuring the person is authenticated. Session management and tracking should be done at a higher level.

Managed to simplify the FSM even more by moving session management to a higher level.

Furthermore I fleshed out SSL2 (Sapphirian Secure Layer) which now includes a fixed size of 1MB+1KB+Some fixed size header. This ensures full E2E with the server by distrusting the SSL layer.

I also reorganized the authentication step and had the SSL2 kick in before any credentials were sent over (this improved security in 3 ways:

1) All sensitive information is now always sent over SSL2
2) The server is directly verified and spoofing or fake server is caught before login information exchanged. This is because the server's public key will be baked into the client's before distribution ensuring that the client can only be connected to the legitimate server.
3) Prevents replay attacks. Since all information is protected by SSL2, it's now extremely difficult to replay and succeed since:
1) The session header has to match
2) The session header have the same encryption key the last time that session header was used.
3) The session may have the login tied to a ephemeral private/public key for the login session.


You'll only receive email when they publish something new.

More from Gaya