password encryption dilemma

[snehula]

Hi there,

I am working on my first website as such and was looking into encryption of stuff like username, password etc. There is a number of functions in php or other languages that can help me out here, like md5 or sha encryption with salt, etc..

What I was wondering about is how any of these is going to actually secure information sent from the browser to the web server. I really do not have a deep understanding of these, but here's how I get it: These encryption methods help in the situation when the database I'm storing the sensitive info in is compromised. What I'm interested in is how in the name of the lord do they guard against someone sniffing my packets while I'm logging in? I guess nohow.. So how do I secure a login or registration page?

I was thinking about RSA public key encryption, in which case the encryption would have to be done client-side (javascript) and decrypted server-side (php in this case). How is that secure if anybody can view the javascript code being executed on a webpage, or am i wrong and utterly confused here?

Finally,I was looking into SSL certificates, but I still don't know how to implement a webpage using https. Does my webhost need to configure their server so my site can use ssl? Does anything need to be configured client-side? Basically I'm looking for a dummies manual for setting up an ssl connection which I haven't found anywhere so far. Anybody any ideas?

[rocknbil]

SSL works **something** like this (apologies to those who have better ways of describing it . . . )

You create a CSR - Certificate Signing Request. This CSR generates a long string of characters using values unique to that computer and operating system. A CSR generated on any other server will create a different pattern. In this way, you are "signing" the CSR, it can only come from your server. Various factors are used to generate it - serial number of hard drive (so I've heard), server signature, date, whatever.

A cert is also bound to a **single** domain and IP address (you need a dedicated IP address.) The exception is a wildcard cert.

You send this CSR to a CA (Certificate Authority) when you request an SSL cert for your domain. The CA is who you buy the cert from, and becomes important when we get to browsers. The CA is the "third party" that verifies the cert. Using the CSR, the CA generates the actual SSL cert, which is unique only to that CSR. With your SSL cert you often get a third file, the cert bundle, which is a signature of the CA.

You install the cert on your server, which has become very easy with domain management tools like Plesk and cPanel.

Once the cert is installed, you browse to the site. Browser have internal "knowledge" of the CA's - when the browser hits the SSL page, it looks up that CA's signature and compares it with the one your site is sending. If found, it considers it a trusted site and uses the actual cert to transmit and decrypt the data.

What this means is the server sends the encrypted data and the browser now has the "key" to decrypt it. When you send data, such as in a form, the browser uses the same key to send encrypted data to the server. This should answer that part of the question - yes your data can be sniffed but it's now encrypted data, won't do anyone much of any good.

Let' take the CA out of the equation and talk about a self-signed cert. This is a cert you create on the server and sign it yourself.

A browser hits a self signed cert and you get a warning something like "we don't recognize this site, browse with caution." It will then prompt you to go away OR install the cert in your browser. Why would you do this? A self signed cert is good for admin control panels or other things that only you will visit, no one else has any place being there, but is not worth the hassle of setting up an official cert. The reason: a self signed cert will **still** be able to transmit encrypted data once you install it in your browser. So that data can't be used in a packet sniff, it's just that there is no CA to recognize it.

As for "implementing" it: this is generally in your hosting setup. You usually can choose to "house SSL content and non-SSL content in a single directory" and this will allow a given page to be viewed over SSL, or non SSL. You'd generally force pages that need to be over SSL to the https versions, and avoid allowing non-SSL pages to use the SSL connection (it's a bit slower due to the encryption.) Or, if it fits your scenario (never seen one that does,) you can have a single SSL directory and everything none-secure somewhere else.

If you just need SSL for user logins and/or checkout processes, SSL is a good option, it's the easiest way to encrypt your data. Encrypting data in forms with Javascript or even sever-side processing is just an additional "layer" if protection - but is still a good idea.

[pinterface]

rocknbil has covered SSL fairly well, so I'm going to address some of your other concerns.

Without SSL, client-side JavaScript public-key encryption is still vulnerable to MITM attacks. While it raises the bar a bit, you can do much better, with less effort, by simply using SSL. SSL isn't hard, isn't expensive, and many of the companies that sell certificates offer step-by-step instructions for setting it up (or just talk to your web host, who should be able to walk you through it).

MD5, SHA-1, and so forth are not encryption functions, they are one-way hashes. (Don't feel too bad: it's a common mistake.) And, because they're really fast, they're also a terrible way to store passwords. Not nearly as bad as storing passwords in plaintext, mind you, but you can do a lot better. To store passwords, use bcrypt [codahale.com].

[snehula]

thanks guys :-)