Logging In | Hacker Web Exploition Uncovered

Several authentication methods are used in Web programming, and each has advantages and disadvantages.

When a user tries to log into a system, the first thing the system does is authentication. I now describe the most popular authentication method.

A Long URL

The simplest way to implement authentication (and, simultaneously , authorization) is to make the URL of a resource long and senseless. For example, to access the administration panel in a system, the user has to go to the address http://site/admin-4gf84sdgfd.php . No additional authentication is done.

If there are no links to that address on the site and the address is kept secret, it will be difficult for a malicious person to find this URL. The complexity of this task is comparable to finding a password.

You could say the password is contained in the URL.

Although the method is simple to implement and seems secure (the protection is comparable to password protection), it has a lot of disadvantages that reduce its security to zero:

No system treats URLs as secret information.
URLs can be written to log files in the HTTP server or the proxy server. Therefore, there is no guarantee that this information will never land in strange hands.
Because the information necessary for administrative privileges is contained in log files, anyone with access to these files can obtain the administrative privileges using a Web interface.
Log files are often available for reading to all the local users of the system. Therefore, any user can obtain administrative privileges using a Web interface.
Even when there are no malicious users in a system (e.g., when the server belongs to one company), a remote user can sometimes read log files through another vulnerability in the system.
Any local user who is allowed to read the Web directory of the target site can obtain the contents of the files and, therefore, the file name . Thus, he or she can access the file using a Web interface.
The user doesn't have to be local. A remote user might find another vulnerability and list files in the site directory to find the name of the script responsible for administering.

What's more, there is no guarantee that this address won't appear in the databases of search engines. It can get there in many ways. For example, if a link to this address was available for some time, a search robot could index it. Alternatively, some browser tools could have passed the address to a search engine when a legitimate user visited this page. For example, GoogleToolbar could have passed the address of a site visited by the user to the Google search engine.

If an URL is in the database of a search engine, anyone can obtain it with an appropriate request. For example, to view all indexed pages in Google, you should make the following request: site: www.site.ru .

So, such a policy of implementing an authentication and authorization system is a policy of confusion. This type of policy is seldom effective.

As I told you, in some circumstances, any user can easily gain access to the system. As for a malicious user, he or she can always access the system after investigation.

Even if search robots are prevented from indexing the address, you can pursue this policy only when the data aren't confidential but are of interest to a narrow circle of users. In addition, leakage of these data should do no harm to the data owner.

Only when these conditions are met can you implement this method of authentication and authorization.

Authentication on the Client

Sometimes, authentication is done completely on the client, and the server just receives the result of authentication. A subtype of this type of authentication involves readdressing the user to a long URL if authentication is successful.

Regardless of a particular implementation, such authentication isn't secure enough. In fact, it is worse than authentication with a long URL.

All data sent to the server when authentication is successful and the long URL are available on the client side, even for an unauthenticated user.

Consider an example of how such authentication is implemented in JavaScript.

http://localhost/4/2.html
<html> <title>authentication</title> <head> <script Language=JavaScript> function auth() { p=prompt('Password'); if (p=='pdgf32f') { document.location.href='auth5fger.html'; exit; } alert('Incorrect password'); } </script> </head> <body> <input type=button value='Loggin in' onClick=auth()> </body> </html>

http://localhost/4/2.html

 <html> <title>authentication</title> <head> <script Language=JavaScript> function auth() {  p=prompt('Password');  if (p=='pdgf32f')  {   document.location.href='auth5fger.html';   exit;  }  alert('Incorrect password'); } </script> </head> <body> <input type=button value='Loggin in' onClick=auth()> </body> </html>

Such a system cannot hinder an attacker. The HTML code is available to any user, even an unauthenticated one. By examining this code, anyone can find all information necessary for successful authentication.

In a more complicated case, the password can be encrypted with a hash function.

http://localhost/4/3.html
<html> <title>authentication</title> <head> <script Language=JavaScript src=md5.js> </script> <script Language=JavaScript> function auth() { p=prompt('Password'); if(md5(p)=='afdceda2236462ec9a3859c7f5da3a5e') { document.location.href='auth5fger.html'; exit; } alert('Incorrect password'); } </script> </head> <body> <input type=button value='Loggin in' onClick=auth()> </body> </html>

http://localhost/4/3.html

 <html> <title>authentication</title> <head> <script Language=JavaScript src=md5.js> </script> <script Language=JavaScript> function auth() {  p=prompt('Password');  if(md5(p)=='afdceda2236462ec9a3859c7f5da3a5e')  {   document.location.href='auth5fger.html';   exit;  }  alert('Incorrect password'); } </script> </head> <body> <input type=button value='Loggin in' onClick=auth()> </body> </html>

I should mention that this code (and the code on the CD-ROM that accompanies this book) is just an example. The MD5.JS file that would contain the md5() function computing the hash from a string is missing from the CD-ROM.

This example doesn't differ much from the previous one. Nevertheless, it is difficult to find the password, especially if it consists of random uppercase and lowercase letters .

However, you don't need to know the password to log in successfully. Information on where the user will be readdressed if authentication is successful is available from this HTML code, and even an unauthenticated user can examine it.

This protection can be complicated further. The code of the JavaScript functions or even the entire HTML page can be encrypted, and decryption will be done only before it is output in the browser window.

In this case, a JavaScript function decrypting the encrypted portion of the HTML page will be called first. A simple examination of the HTML code wouldn't give a positive result.

However, because the decrypting function itself isn't encrypted, and it possesses all information necessary for decryption, the source code of this function and the auxiliary information are available to an attacker.

Therefore, he or she can decrypt encrypted portions of the HTML page regardless of which algorithms, keys, and so on, are used.

In addition to JavaScript functions, Java applets, ActiveX components, and other programming technologies can be used to implement client-side authentication. All these methods will have the same drawback. The only difference might be in how much time it will take an attacker to decrypt encrypted code. For example, a Java applet can be decompiled that is, converted into the easy-to-analyze source code. In addition, there are special tools that allow an attacker to analyze ActiveX components .

A subtype of authorization on the client is an authorization system that computes a value from data entered by the user. For example, the URL to which the user is readdressed can be computed from the password. In this case, information necessary for successful authentication isn't available to the attacker. You could say that only primary authentication is performed on the client and that the secondary authentication based on the computed value is done on the server.

To summarize, a system of partial or complete authentication on the client can have the following disadvantages:

In partial client-side authentication, the set of primary authentication results can be narrower than the set of all the possible passwords.
In some cases, the authentication system becomes too complicated and, therefore, less reliable.
In some cases, incompatibility with client configurations can increase. In addition, the system can require additional operations from the user.
The labor input to designing the system increases .
Efforts directed to complicating and strengthening the system cannot protect it from analysis and successful breaking within a short time.

Solitary Password

Sometimes, only a password is used for authentication. Each user has a unique password, and logins aren't used.

This system also isn't secure enough. Different users should have different passwords; otherwise , the system won't be able to distinguish among users.

Now imagine a situation, in which a new user tries to register in the system and enters a password already belonging to another user.

The system must reject registration of the first user, and the password of the second user will be disclosed.

If a malicious person tries to use the disclosed password to log into the system, he or she won't need that user's login because only the password will be required for authentication.

In addition, when there are many users in such a system, the task of finding a valid password becomes even easier. If at least one user chooses a weak or commonly used password, this password can be disclosed without knowing the login of this user.

So, authentication with a solitary password cannot be considered secure. You can use this system only when you know beforehand that there will be few users in the system, ideally only one. In addition, you should require any users to choose random and complicated passwords. It would be best to distribute passwords among the users automatically without allowing the users to change their passwords.

Login and Password

When implementing primary authentication in a system, the most commonly used authentication method requires a user to enter his or her login and a password into the system. The login can be the user's ID, his or her e-mail address, or some other information.

When properly implemented, this primary authentication will be secure enough in most Web systems.

One of the most common errors when implementing this type of authentication is that the password is sent using the HTTP GET method. GET parameters can be logged both on proxy servers and on the HTTP server of the system. Therefore, when the login and password are sent using the GET method, the system will have the same disadvantages as the system with a long URL.

When the login and password are sent using the HTTP POST method or in the HTTP header, the system will be free of these disadvantages.

However, I'd like to mention that in any case the password is sent to the server as plain text and can be intercepted on any intermediate node in the user's segment of the network or in the server's segment. To protect against such an interception, use hypertext transfer protocol over secure sockets layer (HTTPS). In this case, intercepting the traffic is pointless.