pytrin wrote:How about using this method to create secure cookies that can be later be read on the server? it's probably better than most other client-side cookie encryption techniques.
Sending an encrypted cookie value along with other POST stuff and ignoring the standard cookie system?
Let's forget MITM since we need SSL/TLS to protect from it and let E be "seen by Eavesdroppers".
A typical cookie based authentication system goes like this:
1) Client requests a login page in plain-text. (E)
2) Server responds with the login page HTML in plain-text. (E)
3) Client sends a HTTP POST request with the login credentials in plain-text. (E)
4) Server receives the login credentials, setups a session and sends the session identifier to the client in plain-text (Set-Cookie header). (E)
5) Client will be able to request any protected pages since the session identifier in the cookies has the proper rights and is being sent on each page load. (E)
Eavesdroppers would at this point:
- have the client's login credentials in plain-text and can use it to authenticate themselves.
- be able to do anything that the client can do using the session identifier and act as the client on the current session. (unless there are IP restrictions being applied)
- see everything that the client sees.
Using JavaScript and PKI we could do the following:
1) Client requests a login page in plain-text. (E)
2) Server responds with the login page HTML in plain-text. (E)
3) Client requests (XHR) for the public key. (E)
4) Server responds with a public key (the private key is kept in the session). (E)
5) Client generates a random key pair (A = public key, B = private key).
6) Client sends a HTTP POST request with the encrypted login credentials and A (which is also encrypted). (-)
7) Server receives the login credentials (and decrypts them), setups a session and sends the encrypted session identifier (encrypted using A) to the client . (-)
8) Client can request any protected pages as long as he sends the session identifier as encrypted using the private key B. (-)
Compared to the typical scenario, eavesdroppers would at this point:
- not be able to have the client's login credentials in plain-text and can't use it to authenticate themselves.
- be able to do anything that the client can do using the session identifier and act as the client on the current session. (unless there are IP restrictions being applied)
- see everything that the client sees.
Our login credentials would be protected, but eavesdroppers can still forge requests by using the encrypted session identifier (a replay attack). Eavesdroppers will see anything that is not encrypted with the server's public key. Here's an improved version:
1-7) Same...
8) On each page load, the client generates random data R and sends the session identifier XOR R as encrypted using the private key B as well as R encrypted using the private key B. The server then decrypts R' using its private key and gets R. With R, it will use it to XOR the session identifier and see if the identifier has proper rights. (-)
Now eavesdroppers would:
- not be able to have the client's login credentials in plain-text and can't use it to authenticate themselves.
- not be able to do anything that the client can do using the session identifier and act as the client on the current session.
- see everything that the client sees.
Since the encrypted session identifier, which is being sent, changes on each page load and must comply with R, eavesdroppers can't forge requests or act as the client. At this point, they will just see anything that is not encrypted using the public key.
Hmm, maybe I'll write a JavaScript library that encrypts "cookies", HTML and POST/GET data. The server could also encrypt the response body so that only headers (which do not contain cookies anymore because they are part of POST/GET) are readable to eavesdroppers. This way eavesdropping would be waste of time even if no SSL/TLS was used.