So true. I have my doubts that the plugin it self is involved.
The plugin should not send the password as a GET request, for starters. If it was switched to a POST request, it would not be logged. Anyone security conscious will be running https anyway, but logging passwords to text is a HUGE no-no, even for a non-security-focused company.
In my instance, HTTPD (Apache) is simply passing the requested URL to the logs (this is its intended function) but the plugin code determines how that is sent
The native WordPress login does not pass the password to Apache logs in plaintext, so it’s definitely a “feature” of this plugin.
Can you show me proof of the plugin sending the password in plain text to a log file? I’ve just reviewed the plugin but do not see anything possible of doing that.
This is a santized line from my logs at:
Notice the part that reads:
In this example, kirkw’s password is FuzzyBunny267 and displays openly in the logs as such.
1-2-3-4.sanitized-example-domain.com - - [10/Mar/2013:11:09:13 -0500] "GET /wordpress/wp-admin/admin-ajax.php?callback=jQuery&action=sidebar_login_process&security=1c&user_login=kirkw&user_password=FuzzyBunny267&remember=forever&redirect_to=http%3A%2F%2Fmysanitizeddomain.com%2Fwordpress%2Fcategory%2Fstuff%2F&_=1 HTTP/1.1" 200 133
It looks like the magic all happens around line 136 of sidebar-login.php then line 225 at “function sidebar_login_ajax_process” is where it appears to assemble the redirect string.
SSL or no SSL, this redirects the login to a GET url in plain text.
See the responses on the other thread: http://wordpress.org/support/topic/my-site-got-hacked-after-installing-this-twice?replies=20#post-
My log is showing plaintext passwords at the hands of your plugin. Is your answer seriously the “head in the sand?”
This is not my plugin. I am in no way affiliated with the plugin, I’m simply a plugin reviewer for WordPress.org.
The log entry is not created by the plugin.
This is not my plugin
Then why are you blindly defending it?
I am in no way affiliated with the plugin,
Then why are you blindly defending it?
I’m simply a plugin reviewer for WordPress.org.
Officially? Or in the same capacity as I am reviewing plugins here?
The log entry is not created by the plugin.
You seem to have a very strong opinion which also contradicts the facts.
Yes. Look at the log line. Did my browser randomly redirect to sidebar_login_process for no reason and take with it the very login and password given by the user? I’m not trying to be disrespectful… but I am afraid you picked the wrong side of this one. The proof is in the logging.
I’m not blindly defending it. I have reviewed every line of code in the plugin.
As a plugin developer, I dislike injustice when it comes to other developers work. Myself and several others have reviewed the code in the plugin and it is not explicitly responsible for the security problem.
I’m an official member of the plugins review them.
Just because the log file recorded the request doesn’t mean the plugin was responsible for the log entry getting written.
It is quite simple (from a developer perspective) to write a “hack” that will intercept the login credentials of ANY login form on a WordPress site. All I have to do (from a hypothetical hacker’s perspective) is find a way to install the hack on your site, then I can capture every single login name and password.
That’s all I’m saying has happened here.
Oh and just a suggestion: rather than leaving a negative review like this, it is always best to contact the plugin developer and make them aware of the potential flaw. The vast majority of the time when a plugin has a flaw, it is unintentional and the developer will be thrilled to know about it so they can fix it. If the developer is responsible, they will fix it (assuming it is confirmed) right away.
No one is blindly defending anything. We take security issues very seriously here – hence the rapid response to http://wordpress.org/support/topic/my-site-got-hacked-after-installing-this-twice?replies=22
This plugin has now been checked by three, independent, experienced, WordPress developers and not one of them can find any evidence that this plugin was responsible for your site hacks.
Okay, look… I’m not here to argue with strangers. I have Twitter for that.
I did a fresh install on one of my servers. New WordPress, bone stock. I login and authenticate while watching the logs… No problems. I activate the plugin. I use the sidebar login to log in while watching the logs in realtime. I INSTANTLY see my login and password in plaintext.
So being the moderately logical engineer that I am, I deduce that since I’m using the sidebar login very moment on a dormant site… And I’ve watched my credentials go into the log in realtime… I guess I just wanted to share that there’s a problem.
I disregarded your earlier links because I felt they were irrelevant to my initial concern. No one has hacked my site. The fact is that this plugin passes the login in clear text. I have proven it. If you take the time to test it the way I have described and shown, you will see for yourself.
I’m not coming here to try and be smarter than anyone. All along, my claim has been the same. And I have factually proven in my lab scenario that my claims are true. I don’t know what I did to make you react with doubt or condescension but please believe for a second that not everyone is jumping to conclusions. That is, assuming you believe that anything I’ve said is legitimate.
Until you actually test this the way I did, you really can’t prove me wrong with your really strong opinions. Just sayin.
I’m wondering if perhaps you didn’t scroll the log that I pasted. If you don’t scroll to the right, you might miss the part where it calls a function specific to the plugin and the redirect URL that I set in the plugin settings. That’s where it’s showing the plaintext login credentials just before it redirects. That might help you understand that I’m not a quack.
I searched the code too and don’t see exactly why it’s happening but it is.
I did see the logs, but just because the URL came from the plugin does not mean that’s what caused the password to be logged as plain text.
Now, that being said, I’ve done some more investigation and HAVE found a problem with the plugin. It is very, very minor and extremely simple to fix.
The issue is that the plugin (I missed this before) is sending the login form as a GET request to the server, when it should be using a POST request. (I’m now looking back up to the top and seeing that you said this early, so I have to apologize for missing it).
GET requests are automatically logged by the access logs, including all data sent in the get request.
POST requests are also automatically logged but the data sent to the server is NOT logged in access logs.
The fix for the plugin is to simply change one word from “get” to “post”.
I should have caught this before but it such a minimal thing that it slipped past all of us. I only caught it because I started really digging into the code and extensively testing the plugin.
I’m going to ensure that the plugin author updates the code to fix the issue ASAP.
Now, I want to reiterate a few things:
1. Even though I have confirmed a security problem in the plugin, it does NOT even remotely make the plugin a bad plugin. It simply means the developer (who is a very well known and respected member of the WP development community) made a small error and didn’t catch it, just like the three of us that looked at it failed to catch it.
2. When security problems are found, please, please, please do not simply give the plugin (or theme) a bad rating. Report the issue to the developer and allow them to take care of it. As I said before, if the developer is responsible (Mike is), he/she will fix the bug right away. As far as we can tell, no effort was ever made to alert the developer discretely of the problem.
3. This extends on number 2; by publicly disclosing the problem and what it results in is a MAJOR security concern because you have now explicitly told those with malicious intent what they can look for on sites running this plugin. Security concerns should ALWAYS be discussed privately. If a fix fails to be committed, feel free to openly disclose it.
The plugin will be disabled until it is fixed.
- The topic ‘Secure and Functional!’ is closed to new replies.