1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Password transmitted in plaintext. Possible solutions?

Discussion in 'General XenForo Discussion and Feedback' started by AlexT, Mar 29, 2013.

  1. AlexT

    AlexT Well-Known Member

    I understand the same XF installation may require different kind of hashes depending on the authentication module used (e.g. vB imported users require MD5 whereas newly created XF users use SHA1 or SHA256).

    As a consequence, in the login procedure, a user's password is transmitted in plaintext rather than as a hash. In comparison, vBulletin uses client-side Javascript to turn the password into a hash before sending it over the net, which seems somewhat safer to me (well, depending on the hash used).

    It's understandable that the password is transmitted in plaintext so that XF can keep the login procedure as flexible as possible. One way to solve this is to provide secure authentication over HTTPS.

    Has anyone tried to use HTTPS conditional for XF login only?

    Another way would be to provide several client-side generated hashes through Javascript (those that are potentially needed by the installed authentication modules) instead of the plaintext password, and have the respective authentication module pick the right one. The weak link would be the weakest hash (MD5 for example), but it's still better than plaintext. And it would make the authentication procedure less flexible in case a particular authentication module relies on acces to the plaintext password. Personally I would go with HTTPS since it is safer and would require less code hacking.

    What do you think?
     
  2. Floren

    Floren Well-Known Member

    Using SSL for login only defeats the entire purpose of using SSL.
     
  3. Chris D

    Chris D XenForo Developer Staff Member

    Yeah, this.

    Just make your entire site SSL. It's easy to set up and ensures all data is transmitted securely, including private messages, image uploads etc.
     
  4. AlexT

    AlexT Well-Known Member

    There are obviously different reasons why someone would employ SSL. If you can afford it to enable SSL site-wide, fine. But if you only want to avoid the user password from being transmitted in plaintext, than SSL for login would suit this purpose.
     
  5. Chris D

    Chris D XenForo Developer Staff Member

    If you deploy SSL the cost is the same whether it's on one page, or site-wide.

    All you need is to configure the web server, buy an SSL certificate and install it.
     
    Floren likes this.
  6. AlexT

    AlexT Well-Known Member

    An SSL certificates is relatively cheap these days. It is not the cost I was referring to though. I was referring to the costs it would involve scaling your hardware to properly serve 2000+ online users while performing computationally intensive cryptographic routines used in SSL transactions (public-key encryption). If you limit these transactions to the login sequence, the additional stress on your hardware would be insignificant. If scaling hardware is not an issue for you, then site-wide SSL is preferred of course.
     
  7. Chris D

    Chris D XenForo Developer Staff Member

    I've read a lot to suggest the overhead of deploying SSL is pretty negligible.

    I can't find the source now, but one comment in an article stuck in my mind. When Google deployed and forced SSL for all Gmail users, it requires absolutely nothing extra. No extra hardware, no additional resources. It amounted to a 1% increase in CPU usage.
     
  8. AlexT

    AlexT Well-Known Member

    Traditional SSL over HTTP is anything but negligible on hardware requirements.

    Google uses the SPDY transfer protocol which seems to help a lot. Digitalpoint is using it with Nginx, and some others do. Though I haven't seen any data yet that would suggest that the benefit of SPDY outweighs the disadvantage (in terms of hardware requirements) of SSL.
     
  9. SheepCow

    SheepCow Well-Known Member

    Depending on how ancient the CPU in your server is, you shouldn't see that much of a dent from SSL since most of the encryption algorithms are hardware accelerated. If you compare the time to encrypt the page and the time to generate the page, you'll find generating the page still uses 90% of the time.

    But the short answer is, turn it on, profile it and see how much of a difference it makes for your hardware/users.
     
  10. AlexT

    AlexT Well-Known Member


    I don't know what kind of CPU you are referring to, but I am not aware of any wholesale CPU that is capable of performing the cryptographic routines required for SSL handshake transactions - which is where the CPU-intensive part lies. Just because modern CPUs have extensions such AES-NI doesn't mean that they can accelerate anything that is related to cryptography.

    I may try new technologies such as SPDY when I get the time. The question is will the advantages of a modern transfer protocol over traditional HTTP outweigh the negative side-effects of SSL handshakes.

    Until then - it is still a question whether anything should or could be done against XF transmitting login credentials in plaintext. If you know that you won't need the flexibility of the open authentication architecture, then it could be a good idea to have client-side Javascript submit hashes (md5 for migrated vB users, sha256 for XF users) instead of the plaintext. And if you started a new forum without migrated vB users, even better, you could leave out the insecure md5 hash. Anyhow ;) I am going to test SPDY (and continue to look at DP and see how he performs) and also consider the option to enable SSL only during the login/registration phases.
     
  11. Floren

    Floren Well-Known Member

    Just use Nginx and cache the SSL queries for 5min. Problem solved. :)
    On top of Nginx usage, my site uses the same encryption technology Google has on their sites. Google optimized Ephemeral Elliptic Curve Diffie-Hellman key exchange over P-224 runs at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster. The implementation is immune to timing attacks and as far as I know, nobody else use it beside Google... not even Facebook. :giggle:

    axivo-ssl.png google-ssl.png
     
  12. AlexT

    AlexT Well-Known Member

    Digitalpoint is, I believe.

    Thanks Floren, I'll give it a shot.
     
  13. Floren

    Floren Well-Known Member

    Nice, I did not know he went SSL. I told him about the Google algorithms in a Skype IM if I remember correctly...
    Hmm, I see his site is open to BEAST attacks, Shawn patch this ASAP. :giggle:
    Also, no session resumption... this will slow down the site.
     
  14. digitalpoint

    digitalpoint Well-Known Member

    Not really... since the SSL traffic is SPDY for the most part (connection intentionally held open for long periods by SPDY), there's not a lot of need for session resumption. Plus it gets a little tricky with how our load balancing setup across multiple web servers is (not impossible, but tricky... and really not worth it for the tiny bit of non-SPDY SSL traffic we have).

    But BEAST attack, yeah... fixed.
     
    Floren likes this.

Share This Page