Authentication and Authorization

1.

Authentication and Authorization
INF 203

2.

Authentication
Often sites have restricted non-public functionality. To access this resources
user must go through login functionality. First of all, he must identify himself. But if
I’m identifying myself as Bill Gates, it doesn’t mean that I’m one. As a result, I
must authenticate, i.e., determine that I’m really who I claim to be. In real world it
would be showing a passport or driver’s license.
So, authentication is an act of confirming the identity. This process ensures that
contents are accessed only if the user has the rights to do so.
For example, we often login with username and password. In such cases,
username – is an identification of user, when password is authentication factor of
that user.

3.

Authorization
Authorization is the function that specifying what you are able to do.
Authentication and authorization both are similar words, and often
confused for each other, so keep in mind the difference.
For example, if you are a student, and you can claim that you are a teacher and read
a lecture – you broke authentication mechanism (you verified yourself as a different
person). If you able to go into teachers lounge, where all know that you are a
student, and still put marks for recent exam instead of actual professor – you broke
authorization mechanism (you performed an action, that you normally cannot do)

4.

The ways in which someone may be
authenticated called authentication factors. They can
be based on what user knows, owns or is. There are 3
types of factors:
Authentication
factors
• Knowledge factors – something that user knows, e. g.
password, PIN, secret question.
• Ownership factors – something that user has, e. g.
security token, mobile phone, bank card.
• Inherence factors – something that user is or does,
e.g., fingerprint, retinal pattern, DNA sequence,
signature, face, voice, unique bio-electric signals, or
another biometric identifier.

5.

Single-, two- and
multi-factor
authentication
The single-factor authentication requires a user
to provide just one of the factors.
Usually for web applications it is a password
(knowledge factor).
The two-factor (or multi-factor - MFA)
authentication requires a user to provide two (or
more) of the factors.
For example, many web applications require,
besides password, an SMS or OTP (one- timepassword) code.

6.

AAA
concept

7.

Access Control Models
Applications may
differently define
access control –
which user can
access different
resources. There
are several
common models
which are used in
implementations:
Discretionary Access Control (DAC) – least restrictive model where users
can decide which parties can access resources that they own. Example –
Google Drive where you can give access to the files you uploaded
Mandatory Access Control (MAC) – model where owner manages roles of
other users
Role Based Access Control (RBAC) – user can access the resource if he have
proper role
Rule Based Access Control (RBAC) – the are rules defined to accessing the
resource. For example, you need to be part of some DL (delivery list).

8.

COMMON VULNERABILITIES
CONFIDENTIAL

9.

Credentials over unencrypted
channel
Let’s dig into common vulnerabilities for username +
password authentication.
First of all, all sensitive data, including credentials, must
be transmitted over encrypted channel.
Because of star-topology of ethernet and wi-fi based
networks, all the hosts in the local network see unencrypted
traffic from other hosts, so sniffing is an easy option. But if it
somehow not possible – attacker still may be able to
perform Man-In-The-Middle (MITM) attack and intercept the
credentials. It is crucial for web application to use HTTPS or
other protocols with encryption.

10.

Inadequate Password Policy
A simple passwords can be easily guessed or brute-forced, so it is
an application job to ensure that users can choose only strong
passwords.
Attacker can attempt to guess passwords with dictionary attack –
meaning querying the authentication system with a set list of
words from wordlists (or dictionaries, such as SecLists,
SkullSecurity).
Brute-force attacks means that attacker will try all possible
combinations of defined character set to guess a password (or
tokens and etc.). This attack will cover all possible combinations,
even that user won’t probably choose, and will require much
more time to complete. Usually, it is best to perform this attack
only if dictionary attack has failed.

11.

Strong password
policy
Password policies usually also include
rules, such as composition of characters
(at least one uppercase, at least one
lowercase, at least one digit and special
character), never use the same password
twice, regularly change password, do not
include personal info in passwords.
OWASP ASVS recommends at least 12
symbols in passwords (8 symbols can be
brutted in offline attack with help AWS).

12.

Password
storage
• On a server side, passwords must be
stored in hashed (with salt) state and never
be stored in clear text.
• If an attacker would be able to access
unhashed password storage, he will be able
to access any user account with them.

13.

Lockout
For defending against online brute-force and
dictionary attacks, an application can identify
an attack and block attacker’s authentication
requests.
It can do that in the following ways:
Add an increasing delay after each failed
login attempt
Show a CAPTHA after several (usually 3)
failed login attempts
After 10 failed attempts, lock a user for a
certain amount of time

14.

User enumeration
As we mentioned before, simple application accept
username (user ID) and password as an authentication
mechanism and let in a user only if they are both correct.
So having a user ID is a half of what we are need to
login. Improperly implemented systems can reveal information
about existence of user. It is not considered a direct threat,
but it is a good practice not to avoid such behavior.
For example, error message for login (or password reset
function) can reveal the state of user: “Incorrect username”,
“User is disabled”, “Account has been deleted”, “Invalid
password”.
Good error message does not reveal any info: “Login or
password are incorrect”.

15.

Default credentials
Most of the software and devices
come with default credentials. SQL servers,
web administrator consoles, web-cameras, all
of those can be easily accessed in cases
Information Gathering section and then look
up for default credentials for when default
password wasn’t changed. And tests against
such vulnerabilities are simple: you define
what components are used with help of
what
you
learned
in
discovered
components with google or in the GitHub for
open source projects. “admin:admin” is a
lucky number in this step.
Also, developers can create test user
account for ease of application testing,
such accounts usually contain weak credentials
and can be easily guessed.

16.

Remember me
Typing credentials each time when you are visiting a web site is an
exhausting. To avoid that, applications often introduce the
remember me functionality. It allows to remember user for a
long time after one successful login. It can be implemented by using
browser cache, by saving credentials in web storage or cookie.
The password input field must not be cached, because if attacker will
access the cache – it will easily recover passwords from there.
Especially when you are using a public computer. To be protected
from such attack, applications must disable the cache by using
autocomplete=“off” attribute.

17.

Remember me
Application may store credentials in the cookie for remember
me functionality, or give a user session id with a long lifetime.
The first variant is bad and insecure, because if attacker would
be able to steal the cookie, it receive not limited in time
access to application, but full and as a bonus if password was
stored unencrypted will try to use this credentials on other
resources that the same user uses.
Cookie can be stolen with XSS in cases when it does not
have HttpOnly flag or with MITM attacks.
With a Web Storage situation is similar to cookie, but we
don’t have a XSS protection. Best defense is not to store
passwords on client side. And at least encrypt them if do.

18.

Password reset feature
Users who forgot their passwords must have a way to
reset it. And surely it must be safe.
Usually, it is implemented by sending email to the
user with a new password or a password reset link.
As a first step to improve this process is to ask a
secret questions before sending the email. Answers to those
questions usually added by user upon account creation. And
they must be known only by the owner of the account, so it’s
just like another password.
Applications must suggest recommendations for it, so
user won’t choose easily guessed answers.

19.

Logout weaknesses
Another session weakness can exist in
logout. It is can occur either when session
timed out or when user voluntarily logs
out.
On the server side, a logout is freeing up
the session data that corresponds to
session id. If server does it improperly or
not does at all, an attacker can reuse this
session after gaining a session token that
was previously used even if user have been
logged out.

20.

CAPTCHA
• Completely Automated Public Turing test to tell
Computers and Humans Apart or CAPTCHA is a test
used by many web applications to ensure that the
response is not generated by a computer.
• It can be used for prevention of brute-force attacks
that usually performed by bots and would take ages to
do so by humans. It is not an easy task to implement a
good and a secure one, even when using a thirdparty component, and there were a lot of
vulnerabilities in old implementations. And sometimes
it is easy and cheap to hire a people to solve it for
you.
• So CAPTCHA can only add a small security protection
against attackers.

21.

BYPASSING AUTHORIZATION
CONFIDENTIAL

22.

Bypassing authorization
Lets dig into another set of common vulnerabilities that bypass authorization.
Usually this kind of vulnerabilities exist because of logical errors in application code.
First is Broken Access Control. It occurs when restrictions on what authenticated users
are allowed to do not properly enforced. As an old OWASP Top 10, this vulnerability was
divided into two: Insecure Direct Object Reference (IDOR) and Missing Function level
Access Control (MFAC). First occurred when user was able to access resources that he
wasn’t allowed to access and second occurred when user was able to perform an
action (function) that he wasn’t allowed to do. But this classification confused a lots of
people, so it was decided to merge both of them into one.

23.

Broken access control
For resource access it usually an easy exploitation: attacker
can simply change a parameter value (such as fileID) that refers
to
another
object.
Link
can
look
like
this:
http://example.com/download?id=101. The first thing is to try
different IDs and determine a files that not ours. If you are able to
view foreign file – it is a Broken Access Control vulnerability.
The same is for the actions, if you see a word view in URL, you
probably can change it to edit or delete and see what happens. The
same with GET/POST->PUT/DELETE verbs.
To defend against this kind of attack developers must write code
that checks current user permission before giving him resources on
each and every action that application can do.

24.

Incorrect Redirection
Often applications redirect users to error or home pages
when they determine that user cannot access requested
resource. Generally it writes a value in Location HTTP
header, which browser then visits without even
rendering code that was in the application response.
But if we look into this code, by using an interception
proxy or performing a request by tools such as Curl, we
would see a sensitive data that we wouldn’t supposed to
see…
This vulnerability exist because developers forget to
end a script execution after determining that user
won’t allowed to see it.

25.

Weak Session ID
Session ID or session token usually is just a
number that assigned to client after login and will be
used by server to identify the client in subsequent
requests.
Obviously, if an attacker would be able to guess
the ID and send in to the server, the server will identify
the attacker as an successfully logged client.
So, to make impersonation of users impossible, IDs
must have the following properties:
• Purely random and unpredictable
• Valid only for single session
• Time-limited

26.

Other bypasses
Attacker can also use injections (SQL, NoSQL,
XPath,
LDAP,
command)
to
bypass
an
authentication or steal user sessions.
Such vulnerabilities can exist on a login page and you
can bypass an authentication with an input similar to:
admin‘ or 1=1 -- -.
File attacks such as Path Traversal also can help you to
bypass authorization controls and access resources
out of your reach.
Keep in mind such possibilities when trying to bypass
authentication and authorization.