Autologin-Links is a WordPress plugin that I created in 2012 to allow users to login to WordPress websites using nothing more than a automatically generated magic string. After abandoning the plugin for about 4 years, I checked it again in 2016 and found that still works and that it is reasonably popular. Therefore, I decided to add more features to it, and also to recreate this page that WordPress.org still links to.
Operation
The autologin links plugin allows WordPress administrators (exclusively) to create magic strings for users that then can be distributed and used to login to a website under that user when visiting a link. The magic string is called an autologin code and can be generated via the user profile page. The autologin code is appended as a GET query string to the URL of the target website. Since version 1.06, it is possible to create URLs with autologin codes that link to arbitrary pages of a website through the admin bar of WordPress:
The generated URLs will look like this:
http://my-wordpress-website.demo/post-2016/?autologin_code=iaj3F39dfkdfDdDDaASRR12FMmbbT6When visiting a website with an autologin code in the URL the plugin, the plugin will check if the autologin code is known. If it is unknown the visitor will be redirected to the login page of the wordpress website with a message indicating the use of a wrong autologin code. If the code is correct, the user that corresponds to the autologin code will be logged in. Then the autologin code is stripped from the URL and the visitor is redirected to the original page, in the example http://my-wordpress-website.demo/post-2016/.
Users who have autologin links generated for them can always view their own autologin link on their profile page. However, generating and changing autologin links is only possible for administrators of a website as only they can consider the security risks that this plugin might pose.
Security
This plugin has a few, partially obvious, security issues that users need to be aware of.
Autologin codes are sent in plain text
The plugin does not and cannot obfuscate the autologin codes in any meaningful way. This means when using the http-protocol for a website, a man-in-the-middle attacker can listen to the traffic to the website and intercept autologin codes used by users or generated by the admin using the admin panel. This can be avoided by using exclusively https to connect to a website and disabling http access.
Anybody who has an autologin code is able to login to the website
This point should be fairly obvious, but is important to highlight one more time. This is the basic design principle of this plugin: Everybody who has a valid autologin code for a website can use it to login to the website under the associated user name adn get the associated rights for that user. Consider for which users you generate autologin links and for which you do not!
Redirect to login page when using an invalid autologin code
This could be considered a minor security flaw of the plugin, because it informs a potential attacker that the Autologin-Links plugin is installed on a particular website. If there are any security vulnerabilities in the plugin, an attacker can focus on them. However, to successfully login with a autologin code, the attacker has to guess the (pseudo)-randomly generated autologin code for a some user of the website. Guessing a code is getting more likely the more registered users have autologin codes associated with them. However, a single autologin code is forced to be 30 characters long, is (pseudo-)randomly generated, and consists of numbers, lower-case, and upper-case letters. An attacker should be more likely to succeed with a brute-force attack on the actual user password than with an attack on the autologin code.
Possible future features
- While users should not be able to generate autologin codes for themselves, the administrator should have the possibility to allow users to delete their own autologin code.
- This feature should be activated on a user-by-user basis. A current use-case for the plugin is to redirect general traffic to closed part of a website. In this case, the general visiting audience should not be able to delete an autologin code that leads other visitors to the closed part of the website.