Password transmitted in plaintext. Possible solutions?

[AlexT]

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?

 

[Floren]

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

 

[Chris D]

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

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.

 

[AlexT]

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

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.

 

[Chris D]

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.

 

[AlexT]

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.

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.

 

[Chris D]

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.

 

[AlexT]

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.

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.

 

[SheepCow]

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.

 

[AlexT]

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.

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.

 

[Floren]

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.

 

[AlexT]

Digitalpoint is, I believe.

Thanks Floren, I'll give it a shot.

 

[Floren]

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.
Also, no session resumption... this will slow down the site.

 

[digitalpoint]

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.
Also, no session resumption... this will slow down the site.

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.