Implementing RSACryptoServiceProvider *and* JavaScript

[Glenn]

I'm currently trying to strengthen up the security on a large ASP.NET
application (a web content management system). The primary objective is to
prevent people from evesdropping for passwords and other sensitive
information, with a secondary objective of preventing Harry the Hacker from
having his (her) evil way.

Logging on is secured by never storing the passwords in plain text and using
a combination of MD5 hashes for the user/password, and a single-use token to
'salt' the resultant hash. This is secure as the password (or its hash) are
completely obscured by the salt.

The next step -- and I'm *really* surprised that *everyone* doesn't do this
-- is to prevent 'Evil Eve' from listening in to the network when the
passwords and other sensitive information is passed from the client back to
the server. At this point I should point out that SSL isn't an option
because of its cost. The application is aimed at small businesses who baulk
at the thought of paying $400/year for a certificate (it's hard enough
getting $500 out of them for the website!). Also it is often not possible to
implement SSL on public shared web servers.

The way I propose this to work is as follows:

1) The server creates a RSACryptoServiceProvider object and keeps this as an
application variable. When the object is created, it creates the public and
private keys.

2) When the user requests the form to change a password, the form is
rendered with a JavaScript RSA implementation and with the *public* keys
embedded in the form (probably in the onSubmit event). Note that Java or
ActiveX is absolutely out of the question, therefore I can only implement
RSA on the client in JavaScript.

3) On the client, the user fills in the form and the onSubmit event takes
the variables and encrypts them using the JavaScript RSA implementation using
the supplied public keys. The existing form fields are cleared (don't want
the plain text information being passed over!). The RSA encrypted field is
sent back to the server.

4) On the server the RSACryptoServiceProvider object is called to decrypt
the data sent from the client using the *private* keys.

5) Voila!

The strength of this is based on RSA and the fact that you can't break 1024
bit encryption (without an enormous effort). Although it will take a couple
of seconds to encrypt the data on the client, this doesn't matter.

Having hunted around the internet, I keep drawing a blank here. There are
several implementations of RSA on JavaScript, but none of them are compatible
with the RSACryptoServiceProvider object. The bottom line is there's some
enormous numbers involved here (1024 bits worth!), so there's a shed load of
scary maths involved.

I would *really* appreciate it if someone could point me in the direction of
a JavaScript RSA implementation that works with the RSACryptoServiceProvider.

Oh, as a footnote, I'm really surprised that this isn't a common
requirement. It seems so obvious and so cheap; well it would be if I could
get the damn thing working!


TIA,
Glenn

[Patricio Jutard]

Glenn, this is a good idea to overcome the problem of having to pay the SSL
Certificate, here in Argentina, costs are a big issue that usualy stops
clients from buying our software. Your solution of trying to simulate a SSL
style mechanism is great and I would like to help you in order to make this
work.
Could you please tell me what JavaScript RSA implementations you found and
point me to them so I can start helping?

Thanks,

Patricio Jutard

"Glenn" wrote:

> I'm currently trying to strengthen up the security on a large ASP.NET
> application (a web content management system). The primary objective is to
> prevent people from evesdropping for passwords and other sensitive
> information, with a secondary objective of preventing Harry the Hacker from
> having his (her) evil way.
>
> Logging on is secured by never storing the passwords in plain text and using
> a combination of MD5 hashes for the user/password, and a single-use token to
> 'salt' the resultant hash. This is secure as the password (or its hash) are
> completely obscured by the salt.
>
> The next step -- and I'm *really* surprised that *everyone* doesn't do this
> -- is to prevent 'Evil Eve' from listening in to the network when the
> passwords and other sensitive information is passed from the client back to
> the server. At this point I should point out that SSL isn't an option
> because of its cost. The application is aimed at small businesses who baulk
> at the thought of paying $400/year for a certificate (it's hard enough
> getting $500 out of them for the website!). Also it is often not possible to
> implement SSL on public shared web servers.
>
> The way I propose this to work is as follows:
>
> 1) The server creates a RSACryptoServiceProvider object and keeps this as an
> application variable. When the object is created, it creates the public and
> private keys.
>
> 2) When the user requests the form to change a password, the form is
> rendered with a JavaScript RSA implementation and with the *public* keys
> embedded in the form (probably in the onSubmit event). Note that Java or
> ActiveX is absolutely out of the question, therefore I can only implement
> RSA on the client in JavaScript.
>
> 3) On the client, the user fills in the form and the onSubmit event takes
> the variables and encrypts them using the JavaScript RSA implementation using
> the supplied public keys. The existing form fields are cleared (don't want
> the plain text information being passed over!). The RSA encrypted field is
> sent back to the server.
>
> 4) On the server the RSACryptoServiceProvider object is called to decrypt
> the data sent from the client using the *private* keys.
>
> 5) Voila!
>
> The strength of this is based on RSA and the fact that you can't break 1024
> bit encryption (without an enormous effort). Although it will take a couple
> of seconds to encrypt the data on the client, this doesn't matter.
>
> Having hunted around the internet, I keep drawing a blank here. There are
> several implementations of RSA on JavaScript, but none of them are compatible
> with the RSACryptoServiceProvider object. The bottom line is there's some
> enormous numbers involved here (1024 bits worth!), so there's a shed load of
> scary maths involved.
>
> I would *really* appreciate it if someone could point me in the direction of
> a JavaScript RSA implementation that works with the RSACryptoServiceProvider.
>
> Oh, as a footnote, I'm really surprised that this isn't a common
> requirement. It seems so obvious and so cheap; well it would be if I could
> get the damn thing working!
>
>
> TIA,
> Glenn
>

[Glenn]

I'm still working on this.

Some of the most useful articles are:
* [url]http://www.codeproject.com/csharp/TotalSecurity.asp[/url]
* [url]http://pages.infinit.net/ctech/20031101-0151.html[/url]
* [url]http://pajhome.org.uk/crypt/rsa/rsa.html[/url]
* [url]http://www.leemon.com/crypto/bigInt.html[/url]


I've come to the conclusion that I need to create all three systems in
JavaScript: hashing (MD5), synchronous encryption (3DES), and asynchronous
encryption (RSA). This will enable me to ensure security between the client
and the server in all ways:

1) Password entry
User enters username and password. Do the following:
- Transform the password as --> MD5( Username + MD5( Password ) )
- Transform the username as MD5( Username )
(where MD5( Username ) means get the MD5 hash of the username).
Send these back to the server.

On the server, use the username hash string to search for the user record
(have an extra field in the user record that contains the hash). With this
record, read the username and password hash from this record (*never* store
the password in plain text, always as a hash). Create a local transform:
MD5(Username + MD5(Password)) and compare this with the string sent back from
the client. If they're the same, let them in. If not...

Reasoning: have to hash the username to prevent evesdroppers getting half
of the password.


2) Changing passwords = protecting postback data using PGP style crypto
Server creates the form page and sends a public key to the client in the page.
- User enters data that is to be secured and clicks submit.
- Generate a random password on the client. Hash this using MD5 to get a
trully random password.
- Build a string containing name=value pairs of all the data that is to be
protected.
- Encrypt this data using 3DES
- Encrypt the password with RSA using the public key
- Send the encrypted data and encrypted password back to the server

At the server...
- Decrypt the password using the RSA private keys
- Using this password, decrypt the returned data using 3DES
- Check the decrypted data for sanity (e.g. does it contain name=value
strings?)
- Extract the name=value pairs.

The above algorithm is pretty much what PGP does; combining synchronous and
asynchronous encryption.

Comments for the SSL zealots: this ISN'T a replacement for SSL. It's just
a way of encrypting data returning back to the client so that script kiddies
can't sniff the data. Any encryption's better than no encryption. It's
still vulnerable to the man-in-the-middle attack, but as this is difficult
to perform, the risks are low.


You can also toughen up the above by adding additional checks, adding SALT
to the hashes, and obfuscating the code, etc.

Regards,
Glenn


"Patricio Jutard" wrote:

> Glenn, this is a good idea to overcome the problem of having to pay the SSL
> Certificate, here in Argentina, costs are a big issue that usualy stops
> clients from buying our software. Your solution of trying to simulate a SSL
> style mechanism is great and I would like to help you in order to make this
> work.
> Could you please tell me what JavaScript RSA implementations you found and
> point me to them so I can start helping?
>
> Thanks,
>
> Patricio Jutard
>
> "Glenn" wrote:
>

> > I'm currently trying to strengthen up the security on a large ASP.NET
> > application (a web content management system). The primary objective is to
> > prevent people from evesdropping for passwords and other sensitive
> > information, with a secondary objective of preventing Harry the Hacker from
> > having his (her) evil way.
> >
> > Logging on is secured by never storing the passwords in plain text and using
> > a combination of MD5 hashes for the user/password, and a single-use token to
> > 'salt' the resultant hash. This is secure as the password (or its hash) are
> > completely obscured by the salt.
> >
> > The next step -- and I'm *really* surprised that *everyone* doesn't do this
> > -- is to prevent 'Evil Eve' from listening in to the network when the
> > passwords and other sensitive information is passed from the client back to
> > the server. At this point I should point out that SSL isn't an option
> > because of its cost. The application is aimed at small businesses who baulk
> > at the thought of paying $400/year for a certificate (it's hard enough
> > getting $500 out of them for the website!). Also it is often not possible to
> > implement SSL on public shared web servers.
> >
> > The way I propose this to work is as follows:
> >
> > 1) The server creates a RSACryptoServiceProvider object and keeps this as an
> > application variable. When the object is created, it creates the public and
> > private keys.
> >
> > 2) When the user requests the form to change a password, the form is
> > rendered with a JavaScript RSA implementation and with the *public* keys
> > embedded in the form (probably in the onSubmit event). Note that Java or
> > ActiveX is absolutely out of the question, therefore I can only implement
> > RSA on the client in JavaScript.
> >
> > 3) On the client, the user fills in the form and the onSubmit event takes
> > the variables and encrypts them using the JavaScript RSA implementation using
> > the supplied public keys. The existing form fields are cleared (don't want
> > the plain text information being passed over!). The RSA encrypted field is
> > sent back to the server.
> >
> > 4) On the server the RSACryptoServiceProvider object is called to decrypt
> > the data sent from the client using the *private* keys.
> >
> > 5) Voila!
> >
> > The strength of this is based on RSA and the fact that you can't break 1024
> > bit encryption (without an enormous effort). Although it will take a couple
> > of seconds to encrypt the data on the client, this doesn't matter.
> >
> > Having hunted around the internet, I keep drawing a blank here. There are
> > several implementations of RSA on JavaScript, but none of them are compatible
> > with the RSACryptoServiceProvider object. The bottom line is there's some
> > enormous numbers involved here (1024 bits worth!), so there's a shed load of
> > scary maths involved.
> >
> > I would *really* appreciate it if someone could point me in the direction of
> > a JavaScript RSA implementation that works with the RSACryptoServiceProvider.
> >
> > Oh, as a footnote, I'm really surprised that this isn't a common
> > requirement. It seems so obvious and so cheap; well it would be if I could
> > get the damn thing working!
> >
> >
> > TIA,
> > Glenn
> >

[Glenn]

One of the things I discovered is the 'standard' RSA algorithms, as
implemented in [url]http://www.leemon.com/crypto/bigInt.html[/url] for example, WILL
NOT DECRYPT using the .net RSACryptoServiceProvider. I've been working on
the idea that .NET encrypts using OAEP or PKCS, but still need to research
this.

The bottom line is if you use the .NET-generated public keys in the leemon
example to encrypt a known string (e.g. "hello") and then compare this with
the output from .NET. THEY'RE DIFFERENT.

I've more-or-less come to the conclusion that the RSACryptoServiceProvider
is more trouble than it's worth, so I'm going to use the bigint.cs code
from the [url]http://www.codeproject.com/csharp/TotalSecurity.asp[/url] article as I
need to guarentee the client and server code to be compatible, and it's
risky relying on Microsoft to not change the algorithm when they feel like it
(that's assuming I'll ever get the damn thing working in the first place).


Regards,
Glenn






"Patricio Jutard" wrote:

> Glenn, this is a good idea to overcome the problem of having to pay the SSL
> Certificate, here in Argentina, costs are a big issue that usualy stops
> clients from buying our software. Your solution of trying to simulate a SSL
> style mechanism is great and I would like to help you in order to make this
> work.
> Could you please tell me what JavaScript RSA implementations you found and
> point me to them so I can start helping?
>
> Thanks,
>
> Patricio Jutard
>
> "Glenn" wrote:
>

> > I'm currently trying to strengthen up the security on a large ASP.NET
> > application (a web content management system). The primary objective is to
> > prevent people from evesdropping for passwords and other sensitive
> > information, with a secondary objective of preventing Harry the Hacker from
> > having his (her) evil way.
> >
> > Logging on is secured by never storing the passwords in plain text and using
> > a combination of MD5 hashes for the user/password, and a single-use token to
> > 'salt' the resultant hash. This is secure as the password (or its hash) are
> > completely obscured by the salt.
> >
> > The next step -- and I'm *really* surprised that *everyone* doesn't do this
> > -- is to prevent 'Evil Eve' from listening in to the network when the
> > passwords and other sensitive information is passed from the client back to
> > the server. At this point I should point out that SSL isn't an option
> > because of its cost. The application is aimed at small businesses who baulk
> > at the thought of paying $400/year for a certificate (it's hard enough
> > getting $500 out of them for the website!). Also it is often not possible to
> > implement SSL on public shared web servers.
> >
> > The way I propose this to work is as follows:
> >
> > 1) The server creates a RSACryptoServiceProvider object and keeps this as an
> > application variable. When the object is created, it creates the public and
> > private keys.
> >
> > 2) When the user requests the form to change a password, the form is
> > rendered with a JavaScript RSA implementation and with the *public* keys
> > embedded in the form (probably in the onSubmit event). Note that Java or
> > ActiveX is absolutely out of the question, therefore I can only implement
> > RSA on the client in JavaScript.
> >
> > 3) On the client, the user fills in the form and the onSubmit event takes
> > the variables and encrypts them using the JavaScript RSA implementation using
> > the supplied public keys. The existing form fields are cleared (don't want
> > the plain text information being passed over!). The RSA encrypted field is
> > sent back to the server.
> >
> > 4) On the server the RSACryptoServiceProvider object is called to decrypt
> > the data sent from the client using the *private* keys.
> >
> > 5) Voila!
> >
> > The strength of this is based on RSA and the fact that you can't break 1024
> > bit encryption (without an enormous effort). Although it will take a couple
> > of seconds to encrypt the data on the client, this doesn't matter.
> >
> > Having hunted around the internet, I keep drawing a blank here. There are
> > several implementations of RSA on JavaScript, but none of them are compatible
> > with the RSACryptoServiceProvider object. The bottom line is there's some
> > enormous numbers involved here (1024 bits worth!), so there's a shed load of
> > scary maths involved.
> >
> > I would *really* appreciate it if someone could point me in the direction of
> > a JavaScript RSA implementation that works with the RSACryptoServiceProvider.
> >
> > Oh, as a footnote, I'm really surprised that this isn't a common
> > requirement. It seems so obvious and so cheap; well it would be if I could
> > get the damn thing working!
> >
> >
> > TIA,
> > Glenn
> >