Authentication as mentioned earlier is the process or action of proving or
showing something to be true, genuine, or valid
Authentication in web application is done through different methods the most
common are:
- HTML Form based authentication: this is the most common method to apply authentication in a web application. The used credentials are mostly the user name and a password but sometimes in critical application extra credentials are applied like the usage of special pin code or a key generate by one time password device.
- Other methods might be depending on HTTP based basic or digest authentication where HTTP basic sends credentials encoded unencrypted with base64 encoding in time where digest method uses hash function to encrypt credentials and nonce value from the server this is why basic HTTP authentication should be used only if the channel is secure with (Https). Those methods is usually used on local networks not on the internet.
- Client SSL certificate with or without a smart card but this can represent a distribution problem
- Some application uses Windows-integrated authentication using NTLM or Kerberos and authentication services like windows passport.
Attack bad passwords
Not having a special password complexity enforcement functionality can make
attacking through the password very easy as many password are predictable or
could be a common dictionary word or even empty or has the same username
value.
Some users tend to leave the default or preconfigured password which makes
the attack much easier.
Attack requirement:
Week or no password
Attack Process
a- Try empty and default values for password.
b- Try common dictionary password.
c- If you own an account or self registered try short passwords, user name like passwords to check if that is permitted to disclose the password rules
Brute force attack
Leaving login process to be repeated unconditionally will make authentication
vulnerable to brute force attack which will end in braking authentication with
the speed that a penetration system can iteratively try different possible
passwords.
Attack requirement:
A. No or client side only check for number of login fails.
B. Not very gonium powerful password.
C. If a self-registering account Is available better to create an account.
Attack process:
A. Before going directly to automate the attack explore the locking policy
manually beginning by trying at least (10) bad password values on the
same account, check any messages and accessibility of the account with
the right password.
B. If the account was locked, try to monitor any cookie to discover it the
locking is based on client side information that you can manipulate.
C. See if the system allows you to login with right user name and password,
if yes you can keep guessing.
D. Monitor to find any difference in response between bad login and
successful one to depend on when start in automated phase. A Burp
comparer tool can provide a good way to do that
E. Use an automation tool to iteratively try different user names and
password. (Burp is an example)
F. Monitor results and collect broken account information.
G. Different messages can be a very good pointer that you did a bad guess
the user name only or both credentials.
0 comments: