HTTP Basic Authentication requires that the server request a user name and password from the web client and verify that the user name and password are valid by comparing them against a database of authorized users. When basic authentication is declared, the following actions occur:
-
A client requests access to a protected resource.
-
The web server returns a dialog box that requests the user
name and password.
-
The client submits the user name and password to the server.
- The server authenticates the user in the specified realm and, if successful, returns the requested resource.
HTTP basic authentication is not a secure authentication mechanism.
Basic authentication sends user names and passwords over the Internet as text
that is Base64 encoded, and the target server is not authenticated. This form
of authentication can expose user names and passwords. If someone can intercept
the transmission, the user name and password information can easily be decoded.
However, when a secure transport mechanism, such as SSL, or security at the
network level, such as the IPSEC protocol or VPN strategies, is used in conjunction
with basic authentication, some of these concerns can be alleviated.
WEAKNESSES:
Basic Authentication is not secured because it does not close connection with us after we enter wrong username:password, hence it is vulnerable to brute-force attacks. We can try on and on, multiple retries and try to guess username and password.
Another weakness is that sends information in text, base64 encoded, but even with that, base64 can be decoded without any problem.
Example 1: Brute Force with Hydra
First, we are facing authentication pop-up, server asks for username:password combination in order to serve us resources or webpage we want. To quickly do the job, enable Burp proxy and leave intercept on to capture this submit.
As we can see, Authorization is using HTTP Basic Authentication, followed with Base64 encoded username:password. Once we decode this using Burp base64 decoder, we could see that client is trying to send admin:password, but encoded in base64.
What we can do is try to brute-force this website using Kali tool called Hydra. The example is specified below, with keyword hydra we are issuing tool to start getting arguments from us, -l admin has been used because we already know that username is admin, hence no need to try that out, -P /usr/share/wordlists/fasttrack.txt is just a path to a folder inside Kali machine that consists multiple wordlists for us to use. We chose to use fasttrack.txt, you can chose many others if you want. And finally, we have http-get://10.0.2.15/authentication/example1/ path which is telling Hydra where to bruteforce. Notice one thing, we used http-get because request from the browser was sending GET request, and not POST. If your target application is using POST method, use http-post:// followed with URL.
Hit enter and the password is shown up there, obviously not strong one, but we will continue with much harder once down the road.