RE: Implementing RSACryptoServiceProvider *and* JavaScript

From: Glenn (Glenn_at_discussions.microsoft.com)
Date: 11/26/04

  • Next message: Glenn: "RE: Implementing RSACryptoServiceProvider *and* JavaScript" 
    Date: Thu, 25 Nov 2004 21:19:01 -0800

    I'm still working on this.

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

    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
    > >

  • Next message: Glenn: "RE: Implementing RSACryptoServiceProvider *and* JavaScript"

    Relevant Pages