Sidebar Login
Secure and Functional! (24 posts)

  1. gokevgo
    Posted 2 years ago #


    Any security doubts I have were alleviated with the update. I don't know how to delete the conversation below, but I've updated my review to 5*. Thanks to Mike for the quick fixes. It's truly appreciated.

  2. thanushka
    Posted 2 years ago #

    So true. I have my doubts that the plugin it self is involved.

  3. gokevgo
    Posted 2 years ago #

    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.

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

  5. gokevgo
    Posted 2 years ago #

    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.

  6. gokevgo
    Posted 2 years ago #

    My log is showing plaintext passwords at the hands of your plugin. Is your answer seriously the "head in the sand?"

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

  8. gokevgo
    Posted 2 years ago #

    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.

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

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

  11. esmi
    Forum Moderator
    Posted 2 years ago #

    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.

  12. gokevgo
    Posted 2 years ago #

    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.

  13. gokevgo
    Posted 2 years ago #

    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.

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

  15. For future reference, all security related issues with plugins should be emailed directly to plugins@wordpress.org where we can handle the matter correctly.

  16. gokevgo
    Posted 2 years ago #

    I appreciate your confirmation. Thank you for taking the time to check. I did contact the author initially with no reply. Even when I pointed out the exact problem here, I was met with extreme opposition. But enough of that. I do appreciate eventually gaining your ear and attention.

    The problem appears to be background / Ajax (not something that will likely cache in the browser bar).

    In my unlimited security testing, I've found this text only to be available for someone with root access or access to logs (many boxes don't secure the logs appropriately so this is likely the largest risk).

    Again, thank you for your time and attention on this. I will handle this type of issue differently in the future.

  17. Mike Jolley has already responded to my ping and said he will have the issue fixed in the morning.

  18. gokevgo
    Posted 2 years ago #

    I must also mention that I didn't consider this to be an external security risk when I posted it. As I said, in my environment, the plaintext was limited to someone who already had escalated access to the logs.

  19. 2.5.0 has just been uploaded and fixes the issue.

  20. gokevgo
    Posted 2 years ago #

    Updated and it works great!!

    Watching the logs and everything is VERY standard... nothing compromising at all :)


  21. Mike Jolley
    Plugin Author

    Posted 2 years ago #

    Yep - all patched. Took the opportunity to rewrite the whole thing.

  22. @gokevgo I'm sure Mike would appreciate it if you updated your review to reflect the fixed plugin, assuming you are now happy with it.

  23. gokevgo
    Posted 2 years ago #

    I'm happy to delete it and add a positive one. This thread is irrelevant now from what I can tell. I don't see options to edit or delete but if someone can tell me how, I agree with you that it needs updating.

Topic Closed

This topic has been closed to new replies.

About this Plugin

  • Sidebar Login
  • Frequently Asked Questions
  • Support Threads
  • Reviews

About this Topic


No tags yet.