Is it bad practice to use GET method as login username/password for administrators?

Question

I work on web applications and as you know, having an administrator panel is a must in most cases. We can see that a lot of web applications have a specific login page for administrators in which there is a form (usually POST method) that admins can use to login their panel.

But because the field names are known, a hacker can attempt to crack the passwords even if some security methods are implemented.

So what is the problem with a simple GET key (as username) and its value (as password)? Why it's not used a lot or at least, is not suggested in many articles?

For administrators, user-friendly login pages are not really needed! Data will be logged in both cases (GET/POST) if there is a MiTM attacker.

But using this method, fields will be unknown expect for admins themselves. Here is a sample PHP code:

"category.php": (A meaningless page name)

<?php
if (isset($_GET['meaningless_user']) && $_GET['meaningless_word'] == "something"){
    session_start();
    $_SESSION["user"] = "test";
    header('Location: category.php');   // Redirect to same or other page so GET parameters will disappear from the url     
} else {
    die(); // So it'll be like a blank page
}
?>

Answer 1

This would store the login link with password and username in the browsers history. It could also be accidentally be captured by things like firewall logs, that wouldn't capture post variables.

Answer 2

I can think of quite a few reasons why this would not be ideal:

• In the code snippet you posted, you are now hardcoding a secret key into your program's source code. This is bad because now if you want to publish or share your source code with anyone else, you will have to remember to redact that key. The security of a system should not be dependent on its source code remaining hidden.
• This doesn't scale well. If you have only one secret key that all administrators must share, it becomes a lot easier to accidentally leak. If it does leak, you would have no way of knowing who was responsible for leaking it. You could provide a different key to each administrator, but this becomes messy very quickly.
• You cannot change the key easily. Generally speaking, you will likely need to have site administrators who are not also server operators. But with this setup, you cannot grant anyone the ability to change the key without also granting access to the source code and server, which they may or may not know how to use handle. Tweaking the source code running on a production system willy-nilly is error-prone and will likely result in downtime.
• Because you use GET, it is very easy for the key to leak through browser histories, or accidental link sharing.
• It is not very user friendly. Using this requires knowing how to manually manipulate a specific GET parameter. You say that user-friendliness for administrators is not needed, but this is definitely not true in general. Your entire site should be as user-friendly as possible, including the administrator panel.

In summary, I can see this kind of system in use as a temporary measure on a tiny site, where there is one site administrator who also wrote the site's source code and manages the server. But anything bigger than that, you'll want to have an actual administrator login panel, with hashed and salted credentials stored in the database like any other user.

Answer 3

Not strictly from a security stance, but Hypertext Transfer Protocol -- HTTP/1.1 RFC 2616 makes it quite clear:

...the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

GET should be used only for retrieval. In your case, you are submitting data to the server, the server is performing these specific actions (at a minimum):

• Authenticating a user
• Creating a session to track user state (PHP creates session data in flat files or a database)
• Setting a session cookie to track the session

POST over HTTPS would be the preferred method to transmit sensitive data; username, password in this case.

Answer 4

How comfortable are you with storing administrator passwords in clear-text in your web server access logs?

The problem I see here is that a GET request must put all the field names and values in the request URI. Request URIs are logged by all sorts of processes and will likely be stored, in full, in the web server access log.

That means your web server access log increases in security risk because it now contains the usernames and passwords for GET-based login pages. While you might generally treat server logs as containing privileged information (your customer's IPs for instance), they are not typically so sensitive as to contain enough information to compromise a client's administrative interface.

POST is superior for this, because the field names and values are not stored in the log.

Answer 5

A malicious user gains admin credentials. Using an image tag

<img src="https://example.com/login?username=admin&amp;password=topsecret" style="display:none"> 

they trick your browser to log in (images are not subject to cross-domain restrictions by default). They can then use a series of "image" calls to obtain or change data (a lot of AJAX calls use GET incorrectly as well). There are ways to avoid this, but most people don't enable them. If you're using POST, this attack vector doesn't work.

Answer 6

The problem of using the get method is that the data will be visible on screen and in the webserver logs by default.

My rule of thumb is use post for passwords and big information such as blog article editors and use get for most everything else. Of course there is a few exceptions where the data is too sensitive to appear even in the logs. But those are rare even in the corporate sector.

For example, I have a wizard like functionality with 5 steps where I generate a process id on the first step and on every step you will see ?proc_id=123. PHP supports the query string even in post methods. Even in a step where the form data is too big and I am forced to use the post method the process id still goes visible in the URL like ?proc_id=123.

This makes easier to bookmark things, easier to understand the access logs, as well more educative to third parties that wants to integrate with my apps.

Some precautions must be taken in that scenario to avoid problems with the back button such as clearing from history URLs that must not be resubmitted. Most save actions are like that.

Of course the POST will not protect you from a MiTM attack. It will only prevent sensitive information such as passwords to be written in the logs in your site and in the local history of the browser.

Answer 7

Also consider that GET-Requests are intended not to change anything on the server side. A state change like "logged out" -> "logged in" always have to be done with a POST-Request.

Having a GET parameter like

https://example.com/loginpage.php?password=topsecret 

is semantically exactly the same as

https://example.com/loginpage/password/topsecret 

So there is no authentication at all. It is just an "secret" URL that you have to know to "login".

To make it more clear. If you use Apache for instance you can get the same result with a redirect like this:

RedirectTemp password/topsecret veryobfuscateddirectoryname/loggedin

and then on the loggedin-page place your session_start()

Answer 8

Even if the user and password weren't stored in the browser's history (which they are, as URL parameters) this makes it extremely easy for any hacker to steal your information. It will appear in the server's logs, it makes it even easier to perform a man-in-the-middle attack. It also allows for lots of bad practice, like people bookmarking the login URL, forgetting about it, and letting other humans use their Web browser.

TL;DR: This is a horrible idea.

Answer 9

Yes, it is bad practice. Any security advantage available by having a secret field name could also be gained by prepending that secret on to the password.

Instead of GET with

elephant=rthg4e5sdc

you would be better to use POST with

password=elephantrthg4e5sdc

And of course you can increase the security again by changing that to something more like

password=ehu3dva7rthg4e5sdc