hessodreamy wrote:We get about 15000 hits a day. So you think that the perforance impact would not too bad?
Correct. But as with all issues relating to performance, you should measure your specific environment to determine if SSL itself is adding the performance hit, or something else in the page. (This presumes you've found a performance issue at all).
hessodreamy wrote:And do you mean sites should be designed properly in general or with specific reference to https? in which case what considerations should I make?
Using SSL means you need a fast processor, or ideally, multiple fast processors. Having a crypto accelerator is also a possibility, but I'd just go with a faster processor.
You also want to isolate the webserver from the db server, to ensure that the webserver and ssl connection can focus its power on the connection itself. Then use some aggressive optimizations in Apache configs, and possibly in your db configs. You could even setup a round-robin web cluster if you want to get extremely aggressive.
hessodreamy wrote:And how would you use Javascript to encrypt the logon?
http://pajhome.org.uk/crypt/md5/
hessodreamy wrote:Do a js call with the details which authenticates the details and updates the session server-side? If the call is secure you'd then get a "Mixed content" warning, would you not? I'm basically trying to avoid giving the user any kind of security alert at all.
At the login, you have a form with two (visible) fields: username and password. The password field on submit triggers js that takes the password entry, runs it thru a hash (sha256, sha1, md5), storing it in a hidden form field (hash_pw). the password field is cleared.
That way no clear text password is sent (that field is cleared), the hashed password is sent, and the browser doesn't store it.
You do not get a mixed content warning at all - that only happens when you have both https and http elements on the same page.
hessodreamy wrote:Besides, I try not to use javascript for anything critical such as login. I don't want to force the user to change any settings or exclude people with the wrong settings. I'm appalled at some sites out there who rely so fundamentally on javascript, especially with not a noscript tag in sight. But that's a different issue entirely

If you want a secure login, you have two, and only two, choices: SSL, or javascript hashing for passwords. Offering a secure login isn't excluding people with the wrong settings - its offering additional functionality that isn't available without it.