jCryption

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

jCryption

Post by Eran »

I'd be interested in hearing what you guys think about jCryption, a jQuery based plugin that performs client-side RSA encryption.
http://www.jcryption.org/
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: jCryption

Post by kaisellgren »

Interesting. Here's what I think.

The purpose of SSL/TLS is to provide data integrity, authentication and confidentiality against MITM and eavesdropping attacks. jCryption will not help against MITM, but eavesdropping attacks. This plugin provides tiny confidentiality with no authentication. Since there is no authentication involved, an eavesdropper knows all the details to become the client (the public key, the session identifier). This process can be automated easily. There does not seem to be any integrity protection at all (which makes sense since this does not prevent MITM attacks). So in overall, there's no way this could be used as a replacement for SSL/TLS. If you can get an SSL certificate, get one. If you can't, surely you could use this library to increase your confidentiality level by a tiny amount, but we have to remember that this plugin does nothing about authentication and integrity.

Hiding GET/POST details (disincluding file uploads) from eavesdroppers (only) is what this plugin does. It's better than nothing, but any kind of business that requires SSL/TLS must use one.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: jCryption

Post by Eran »

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.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: jCryption

Post by kaisellgren »

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.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: jCryption

Post by Eran »

no, I meant for different use case, without a form or POST/GET data. I personally use only sessions, but I know plenty of people use encrypted cookies for storing user information and authentication results. For example, as an added protection against XSS attacks, in which the user cookies are sent to an attacking site through injected scripts.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: jCryption

Post by kaisellgren »

Ah, using PKI for protecting cookie data? No, that wouldn't work great. The server is the only one who can know the cookie details, so, there cannot be two keys. For example, the server encrypts your favorite color "red" that you don't want anyone else to know and sends it to the client. Now, the client will send it as encrypted back to the server on each page load and the server will decrypt it. A typical symmetric encryption process is all that is needed. If the client is able to decrypt the favorite color, then anyone doing an XSS attack can read it, too. Therefore, asymmetric encryption is useless if someone can achieve an XSS attack. Asymmetric encryption is meant to help when there's someone in between two nodes. Symmetric encryption, on the other hand, is meant for situation where there might be someone in the second node (which is the case with XSS attacks).
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: jCryption

Post by Eran »

So this plug-in is not much more than a curiosity then. When do you think you might write that library you mentioned? :)
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: jCryption

Post by kaisellgren »

pytrin wrote:When do you think you might write that library you mentioned? :)
When I have enough time... now I have plenty of tasks to do and I have to be back in the brigade in 5 hours. I can of course always plan in my mind while I'm serving in the army and implement everything when I have time. :P
Post Reply