I built a site where users log in to access a document library.
The data protected does not require a high degree of security so ssl was not used. They have a client complaining that their username and password are being transmitted in clear text and in return, complaining to me.
At what point do you consider ssl important? It doesn't seem realistic to need to require this when the data protected is not sensitive. What do you all think?
Some people make the mistake of using the same password for sensitive logins as they do for ones where it doesn't matter. Where you don't use SSL for your "doen't need to be super secure" login process you expose those idiots passwords for all their secure sites - bank etc - to whoever decides to capture passwords from your login in the hope that the people using the page are moronic enough to have reused the same password as they used for their bank account.
If it were not for such stupidity in using the same password for multiple sites where some of them do need to be super secure then it wouldn't matter.
What the client is really saying in this case is that they think their users are super dumb enough that they are using passwords to access the site you built that are the same password they use for their bank account and other similar sites where security is needed and so they want you to build in that extra security layer to protect their users from their own mental incompetence.
I'm curious what other developers do. Obviously, not all sites require the same level of security. What's the baseline?
If it's sending sensitive or personally identifiable information I use SSL. The only information which I qualify as non-sensitive is Name (not always unique to one person), e-mail (at most would be a spam risk, usually it can be anonymous) and date of birth (most people aren't too bothered about identifying age). Passwords can be sensitive because people tend to use the same password over and over... but that's down to their own stupidity (not to mince words), everyone knows you shouldn't use the same password for sensitive sites as it enhances the exposure risk. If you need stuff like credit card information, addresses and zip/postal codes, phone numbers or other relational information specific to an individuals location... go with SSL, otherwise just ignore the individuals paranoia
Its really necessary to have SSL security certificate, as in order to protect against the password protect case, well SSL is what exactly banks and other money dealing websites uses...:)
That will be needed when you are running some kind of web sites where users transfer personal information (billing info as well).
Right, in the case I was referring to, the password was for a document library. No information about the user was stored. The password protection was for the purpose of gleaning the email for marketing purposes. So it passes a user name and password. That's it. Well, I haven't heard back from the client. So maybe they were satisfied by my explanation.
SSL is only a means to pass data without third-party able to intercept them.
It doesn't improve security by itself. it only allows to communicate safely, at the cost of raising, slightly, server load.
SSL certificate has one more value: if issued by a well-known CA, the certificate may serve as a proof of good standing. In other words, it allows to create trust in the party using the certificate and secure data exchange it allows.
This is why self-signed SSL certificates aren't popular when the question is to trust the site or not.
Actually no. A Certificate has nothing to do with trust but identity. The Certificate is a proof that the identity of this individual has been verified by a third-party. However, this is only the case if the Certificate was issued by one of the few Root Certificate Authorities.
A holder of the Certificate from a Root-CA does not mean it is trusted, only the identity has been verified.
The identity verification isn't a goal by itself. If only identity verification were the goal, there would be no many different types of SSL certificates available from the same vendor, differing only in the amount of trust they assume.
All the identity checks/whatever actions required to obtain a SSL certificate are about trust, finally. I don't care about whether the SSL certificate owner's identity is checked or not. I, the visitor, must be sure whether I can trust my personal data to the site owners or not.
I suggest reading the 'Web of trust' concepts supported by many CAs.
If you want to believe marketing then okay that is fine. But I was told very plainly during several of my courses involving security, the most recent by an instructor with more then 50 years in security. Certificates do not signify trust only identity. Whether you trust the person on the other end is up to the end user. There is nothing stopping "BAD GUY" from getting a Certificate and using it to get your information and then improperly using it.
Of course there's nothing to stop that. However, I will distrust the CA that issues a SSL to many a bad guy, that's all.
Technical aspects (checking the identity) and psychological ones (trust creation) should not be mixed or compared.
"The password protection was for the purpose of gleaning the email for marketing purposes. "
Why ask for a password? Could just request a user email.
Sometimes that's all the confirmation required to gain access to somebody's personal information, assuming you have their name as well.
Not all web application require SSL certificates enabled for their website. Paticularly banking sites where major and crucial transactions occurs requires 128 bit SSL certificates. There are chances these highly confidential sites may expose to phising and more prone to hackers. Such risk factors wants these sites to be protected by ssl certificates as data flow is encryptes and decrypted through proper channel. Even corporate portal do have SSL protected website so as to protect client's data as well as employee credentials.Verisign -(SSL) Secure Soket layer provider.
When you site to a very high security requirements！
Do you store their password without hmac-ing it ? If you responded no, it means it was already considered a sensitive data when designing your app.
If you responded yes, I urge to start thinking about user login/password as sensitive data and start learning the right ways to store these.
That's a good point, but the user needed to access documents from several different pages. So A login enabled a memory of access permission. But come to think of it the Username/Password combination is not really necessary here. It would have been enough to just register the email and use that itself to grant access.
As a note, Sitepoint, Wikipedia and a number of other similar sites don't use ssl on their login page, and they store identifying profile information but not cc#, SS# etc..
And because big websites do not care about what you put in their DB, should every website do the same ? No.
next page →