This statement is rather silly. The CA does not do any kind of audit of your business process to make sure you are not a “bad guy” before they sell you a certificate. All they really verify is that you are the valid owner of the domain.
The certificate serves two purposes.
- It provides asymetrical encryption of the data while going from the browser to the server.
- It confirms the domain that the data is being sent to is actually abcbank.com and isn’t abcbankspoof.com (but only if the person about to use the page actually checks the certificate to make sure which of those two certificates the current page has attached to it). From what I have seen few people actually bother to do this which is how many of the spoof attacks on bank web sites actually manage to successfully capture passwords.
SSL or Secure Sockets Layer is a security protocol created by Netscape that has become an international standard on the Internet for exchanging sensitive information between a website and the computer communicating with it, referred to as the client.
SSL technology is embedded in all popular browsers and engages automatically when the user connects to a web server that is SSL-enabled. It’s easy to tell when a server is using SSL security because the address in the URL window of your browser will start with https. The “s” indicates a secure connection.
When your browser connects to an SSL server, it automatically asks the server for a digital Certificate of Authority (CA). This digital certificate positively authenticates the server’s identity to ensure you will not be sending sensitive data to a hacker or imposter site. The browser also makes sure the domain name matches the name on the CA, and that the CA has been generated by a trusted authority and bears a valid digital signature. If all goes well you will not even be aware this handshake has taken place.
However, if there is a glitch with the CA, even if it is simply out of date, your browser will pop up a window to inform you of the exact problem it encountered, allowing you to end the session or continue at your own risk.
Hi…
Well…I dont think so that in this case you need to use SSL. As only username and password are passed, there is no need to use SSL.
You can do one thing instead of passing them as query string you can pass them using cookies or session variables…
Regards,
SSL certificate is necessary for your website protection. It’s necessary if you have online store which accepts online orders and credit cards. SSl Certificate enables encryption of sensitive information during online transactions.
One site I’m a member of made a password by combining random words rather than random letters. I’ve remembered it for the last 7 years.
SSL is only a means to pass data without third-party able to intercept them. it makes your on-line trade safely
Personal Information = SSL if not than your ok. 
SSL Secure socket layer that means your application is secured from external hacking and your message transmit through destination without being intercept. It works on private and public key concept. The web server sends encrypted message with certificate as public key token. The browser valid the certificate and send the response to web server with encrypted data and once data is received by browser it decrypt with private key token so public key encrypts and private key decrypt. This is how transmission of data becomes secure. This SSL is 128 bit and worked on URL with HTTPS–S-Secured.
The port 443 is used in web server and port 8080(http unsecured transmission).
The application like:
• Online Retail banking
• Consumer Banking
• Mutual Fund Sites
• Online Ecommerce with credit card gateway
It should. You already admitted that at least some of your users use the same password for other things, then you should help protect it.
Woot ! “Others are not making any effort so why should I ?”, gotta love this kind of thinking.
When then would you like to pay for it? Provide funding for every login form to have SSL?
You pay for some server already ? Then adding some more for SSL instead of more CPU power / disk space / bandwidth may be an idea.
Or better, use openID or some other login service.
We’re not responsible for saving the user from their own stupidity or carelessness. Not yet, anyway. But give Dear Leader time to introduce Appropriate Legislation…
Checks= forum section name Web security. I’m sorry, but working on security mean you have to work around the user stupidity. That’s more work from the developper to help the user not having to do any effort, isn’t all info things done just for that ? Helping the user not have to work to achieve something.
Not being being held responsible for something by higher autorities does not mean your clients will like to know their passwords leaked from your hacked database.
Well, the only thing to add is that anyone shall have SSl certificate installed on their website when transmits sensitive information - credit cards, personal data, etc.
If information is not confidential and the only reason for SSL/TLS is to protect authentication process, you could use OpenID or other hosted authentication service (that you trust of course), or implement SRP.
Anyhow, there should be a good reason not to use SSL/TLS, because not only does it provide secrecy of transfered data, but data integrity as well - meaning that it assures that no one has changed anything on the page (which is very important for all authentication methods that rely on client side JavaScript).
really? what about when you store that information on your server? Not trasmit but just store it.
Where SSL is useful is in protecting the passwords from sniffers. Anytime they use Public WiFi/Hotspots, an unencrypted password could be stolen. If the data on the site isn’t that critical, then don’t worry too much; if it is important, then you should be using SSL.
SSL is an interesting illusion: many people assume a site is “secure” when it has SSL, when in fact all SSL protects you from is password sniffing. A database of unencrypted passwords could be far more devastating, and is actually a bigger (but invisible) development mistake.
Thanks For Share…