Encrypt user password with jquery and decrypt it with C#

• I don't want to use SSL to encry开发者_JAVA百科pt signup and signin forms for a website I'm building.
• I don't have money to pay for a certificate.
• I need to use encryption with jQuery and decryption with C# in my asp.net website.

Does someone have an example and how is it secure to adopt this method?

If you're not using SSL, then you're not secure, but that's not the only reason.

SSL protects the actual communication, whereas encryption protects the data you are communicating. You should not even be encrypting the passwords at all. You should be making a hardened hash of the information. A hash is a one-way function (cannot be reversed), whereas encryption is two-way function(can be reversed). Hash hardening and use includes:

• Iterating over a hash built for speed, such as SHA512 a couple of thousand times or using something like BCrypt.
• Use a salt - Something like a 64-bit array of jumble per user, stored in the database will do it
• Encrypt the keys and salts in the DB using a key in the application layer - This means if your database is taken, they would still need the key from the application layer to access the raw hash information, as well as the salts.

You have to remember that security is built in layers. By skipping SSL, you're skipping a large portion of it. At the very least you can use makecert to create a self-signed certificate. All that will happen is that the user will be warned about it. A good SSL certificate can cost as little as $12.99 on GoDaddy. I recommend getting one as well as implementing the above.

You can do SSL without paying for a certificate, and this method get you secure only browser get information about your certificate is not qualified.

Read about this http://www.akadia.com/services/ssh_test_certificate.html

It's probably not secure at all. SSL really is the way to go; if you can't afford a certificate, you can always make your own. Obviously those won't validate up to one of the trusted root authorities, but they are just as secure - the identity of your website will not be confirmed by a trusted third party, but the connection itself will be just as securely encrypted.

By not using SSL you're opening up your code to network sniffing attacks. Encrypting on the client side won't do any good either.

Unfortunately there's no safe way around it without getting a valid certificate. This approach would be unsecure.

I agree with the security concerns of the other individuals, if you're hell-bent-for-leather on doing it this way, you may attempt to employ a custom PKI interface. You will have to research a little more deeply on the code necessary to accomplish this but here is a link to describe the public key structure:

Public Key Cryptography

So if you manage to code up a public key RSA algorithm in jquery, you should be to match its private key decryption in C# without difficulty. This is not a recommendation because this really is only "security through obfuscation" (which is not security at all).

You can encrypt the form data with Javascript. This can be done, see http://www.movable-type.co.uk/scripts/aes.html. If data is encrypted with a key, then you'll have to store that key in javascript code and also in server-side code. Since javascript code will be client-side and key will be public, that's not secure at all :). The same is also valid for asymmetric encryption. Different data can be encrypted with the same key and sent to server.

SSL is designed to overcome security problems on the web, using public key cryptograpy and symmetric encryption tehcniques. Middle-man attack is prevented. Using SSL, you can be sure that your data is secure, not altered through the way and there is a 3rd party, certificate authority, which says that you're the person you claim to be.

If you say that I can put the key or encryption code in an applet or active-x or flash swf object and use obfuscation to secure the code, that may be a way. But again this approach is open to attacks and not secure. Obfuscation does not guarantee that your key or algorithm is safe, just hardens the cracker's job to get the key.

I hope that helps.

You could use a HMAC for authentication. This would not provide privacy but a sniffer (guy looking into then network traffic) would not be able to get the passwords nor login impersonating an authentic user. When I it does not provide privacy I mean the sniffer will see all the transferred content but not the password.

SSL is of course very secure, but an overkill for many applications.