1

Coming to WordPress development from more "hardcore" (slow) development, I find it extremely odd that the WordPress login process provides absolutely no defense from sniffing credentials data.

It all goes in plain text, which makes it extremely easy to fish anyone's login credentials under a public WiFi, including admins, if the website doesn't have any SSL installed.

Even searching for plugins that might encrypt the data before sending it to the server went to no avail.

So what's up WordPress? Is it a considered a good practice to install SSL in all websites? Is it considered OK to just sign in with your admin account on public WiFi, regardless if your website has SSL installed? And what about other user's login/registration process? It puts most WordPress websites and its users at a major security risk it seems, if not using SSL encryption.

Improve this question
9
  • How do you know that WordPress makes the login info go into plain text and is easy to get the login info under public WiFi? Did you test this out yourself?
    – Ethan O'Sullivan
    Sep 23, 2016 at 12:14
  • What is your research to say that claim? Were you able to steal a user's login over a public wifi? Please put the details and how it can be done.
    – Ahmed Fouad
    Sep 23, 2016 at 12:15
  • While interesting, this isn't really within our scope here How to Ask
    – Andy Macaulay-Brook
    Sep 23, 2016 at 12:15
  • @EthanJinksO'Sullivan Obviously the normal WordPress login page doesn't use any JS, so no encryption is being implemented... it just sends the login in plain text (in post method, but still plain text) I'm using a theme which implemented an AJAX frontend login page, and it's the same case... just unsecure
    – user102853
    Sep 23, 2016 at 12:21
  • 2
    JavaScript is not a secure way to "encrypt" anything.
    – fuxia ♦
    Sep 23, 2016 at 13:30

3 Answers 3

Reset to default
1

The login process itself is not as important, it is a one time thing that with the right settings you can do once a year.

What is important is the authentication cookies that are being sent. As long as they are not encrypted it doesn't matter at all how much defense you put on the login form itself, and cookies are sent every time any of the URLs of the site are being fetched.

So you either have SSL or you are not secure. There is a middle ground in wordpress in which you will automatically get HTTPS URLs for logged-in users (and the login form) but obviously you still need a certificate.

Why would anyone not use HTTPS when the threat of WiFi is known and the cost of a certificate is zero? because the cost of the "free" certificate is wasting time to configure it and administering it, and while the WiFi threat exist, no one showed it that using WiFi is less secure than having an account on Yahoo, and most people do not connect from an external Wifi to their sites. Personally I use my cellular data even when free WiFi is available.

There are also other benefit of not running a full HTTPS site, especially caching. When you do HTTPS your content can not be cached.

So yes, the industry (google) tries to make it a case of white and black but in reality it is (like most things) gray. Everyone has to asses his own security risks and compare it to the amount of work required to overcome it and make his own decision

Improve this answer
3
  • Thanks for the thoughtful answer ;) It's good to hear a solid answer from someone in the industry... I guess it does leave everyone not using HTTPS in a major risk.
    – user102853
    Sep 23, 2016 at 12:31
  • Interesting thoughts about the caching, is it just the content that isn't getting cached on HTTPS on wordpress?
    – user102853
    Sep 23, 2016 at 12:31
  • web pages can not be cached on proxies (end user browser is a different thing but less interesting) because SSL based encryption generates a different page for each client (the encryption key is different) therefor if the same encrypted page will be sent to different clients at least one of them will fail decoding it, so it is not literally impossible, it is just pointless. This is, like most of the answer, not wordpress specific and impacts everything on the web.
    – Mark Kaplun
    Sep 23, 2016 at 13:45
0

Disclaimer: Take all this with a pinch of salt as I am not a security expert.

All of this is no different for WP than it is for anything else. If you don't use SSL everyone who can intercept traffic can fish anything transmitted. You can either get SSL or live with the risk. So this is probably off topic here anyway as it isn't specific to WP.

Your idea of encrypting before transfer - I don't really get it. Unless you're using a Browser Plugin that handles this the code that could encrypt the password is coming from a server which you can't trust. So an attacker would need to send you a manipulated JS that leaks the password instead of just listening to the traffic. Maybe a bit more difficult, but still basically the same.

TLDR; If you want your site to be secure get SSL. Otherwise live with the risks or at least avoid hostile networks(e.g. public wifi).

Improve this answer
3
  • You are right it's basically not really a WP issue, although I thought there's a built in solution in it like to many other things in WP... I did worked before with frontend RSA encryption, and decrypting it on server... that way using SSL isn't a must when performing login/registration
    – user102853
    Sep 23, 2016 at 12:33
  • Using custom clients or a browser plugin? Or via code coming from the site itself? Because as I said I think the latter is quite pointless.
    – kraftner
    Sep 23, 2016 at 12:35
  • From the site, it's pointless if you are using HTTPS yes... you are right, I remember now that I did it for a hybrid js mobile app
    – user102853
    Sep 23, 2016 at 12:45
0

In addition to @MarkKaplun's answer over here which answers the real question, I thought I would add the hacker's perspective into the topic. I am not a security "expert", but I do have some experience in this. Let me explain.

If I was doing an MiTM attack on the network where the said users are, I would first look at the non SSL packets, which are non encrypted. Now let us say that I find a form key, for which I also find a garbled value. My first intuition would be to look for the referrer, go to the referrer, and reverse the JS code that does it.

You could obviously trump me with flash/java apps but you won't really do it as doing so will scare your visitors away (unless you have something private , right?).

Even if you enable SSL on the login page, I would try to make the user accept my fake certificate. Doing so, will result in full information disclosure from that particular client.

The point is to have SSL, and a very strict login policy enabled instead of an encrypted form, because you can't encrypt it ultimately on the client side. If your user is a ******, he/she will continue to be one..

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.