SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 59
  1. #1
    SitePoint Guru
    Join Date
    Jan 2007
    Posts
    967
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    When is SSL necesary?

    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?

  2. #2
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,788
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    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.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  3. #3
    SitePoint Guru
    Join Date
    Jan 2007
    Posts
    967
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I'm curious what other developers do. Obviously, not all sites require the same level of security. What's the baseline?

  4. #4
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    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

  5. #5
    SitePoint Addict
    Join Date
    Nov 2009
    Location
    Carlsbad, California
    Posts
    200
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...

  6. #6
    Non-Member
    Join Date
    Nov 2009
    Posts
    302
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That will be needed when you are running some kind of web sites where users transfer personal information (billing info as well).

  7. #7
    SitePoint Guru
    Join Date
    Jan 2007
    Posts
    967
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #8
    SitePoint Member temmokan's Avatar
    Join Date
    Dec 2009
    Location
    Novosibirsk, Russia
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Last edited by temmokan; Dec 17, 2009 at 04:58. Reason: minor correction
    Konstantin Boyandin
    Network and Server Monitoring Tool: uptime/performance monitoring

  9. #9
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by temmokan View Post
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  10. #10
    SitePoint Member temmokan's Avatar
    Join Date
    Dec 2009
    Location
    Novosibirsk, Russia
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    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.
    Konstantin Boyandin
    Network and Server Monitoring Tool: uptime/performance monitoring

  11. #11
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by temmokan View Post
    ...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.
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  12. #12
    SitePoint Member temmokan's Avatar
    Join Date
    Dec 2009
    Location
    Novosibirsk, Russia
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    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.

    Dixi.
    Konstantin Boyandin
    Network and Server Monitoring Tool: uptime/performance monitoring

  13. #13
    SitePoint Zealot
    Join Date
    Oct 2008
    Posts
    140
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    "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.

    Michelle

  14. #14
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    and date of birth (most people aren't too bothered about identifying age)
    Sometimes that's all the confirmation required to gain access to somebody's personal information, assuming you have their name as well.

    Cheers,
    D.

  15. #15
    SitePoint Member
    Join Date
    Dec 2009
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  16. #16
    SitePoint Member
    Join Date
    Dec 2009
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When you site to a very high security requirements!

  17. #17
    SitePoint Enthusiast
    Join Date
    Sep 2008
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by eruna View Post
    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?
    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.

  18. #18
    SitePoint Guru
    Join Date
    Jan 2007
    Posts
    967
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by techmichelle View Post
    "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.

    Michelle
    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.

  19. #19
    SitePoint Guru
    Join Date
    Jan 2007
    Posts
    967
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arkh View Post
    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.
    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..

    E

  20. #20
    SitePoint Enthusiast
    Join Date
    Sep 2008
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by eruna View Post
    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..

    E
    And because big websites do not care about what you put in their DB, should every website do the same ? No.

  21. #21
    SitePoint Guru
    Join Date
    Jan 2007
    Posts
    967
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    The sites I mentioned do have the funds and technical expertise to make competent, security decisions and have decided ssl is not merited for their sites. This indicates the practice is up for debate.

    Obviously, the level of security is not going to be the same for different applications. There is a cost associated with security and a calculation needs to be made.

    This discussion has made me think of alternative ways to handle low security access without sacrificing protection of data. For example, the password could be automatically generated using random common words or the assets could be mailed as attachments.

  22. #22
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,398
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Completely agree w/ you. Just tell the user that this site does not contain any sensitive information.

  23. #23
    We're from teh basements.
    Join Date
    Apr 2007
    Posts
    1,205
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If it's a simple matter of requiring users to choose a strong password, just add a password strength tester to the registration form and don't allow weak passwords through.

  24. #24
    SitePoint Guru
    Join Date
    Jan 2007
    Posts
    967
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by World Wide Weird View Post
    If it's a simple matter of requiring users to choose a strong password, just add a password strength tester to the registration form and don't allow weak passwords through.
    I think its more an issue of password ownership than its strength. In other words, the user name and password combination might be used on any number of sites. If the transmission was intercepted a hacker might be able to gain access to online banking, email, or other important areas. The auto assignment of password ensures that the password is unique.

  25. #25
    SitePoint Wizard lorenw's Avatar
    Join Date
    Feb 2005
    Location
    was rainy Oregon now sunny Florida
    Posts
    1,098
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    My big question is - Has the client ever joined a forum, blog, social networking site? If they have, how do they send the password to them?

    Most of these type of sites have much more personal information than a document library.

    I'm scratching my head on this one.
    What I lack in acuracy I make up for in misteaks


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •