G
gg
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 .net
RSACryptoServiceProvider object.
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
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 .net
RSACryptoServiceProvider object.
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