# Authentication vulnerabilities

* [PortSwigger - Web Security Academy - Authentication vulnerabilities](https://portswigger.net/web-security/authentication)

## Authentication

### Authentication factors

Authentication mechanism verify one or more of the following factors:

* Something you **know** (e.g. password, security question)
* Something you **have** (e.g. mobile phone, security token)
* Something you **are** (e.g. biometrics, behaviour)

### Difference to authorization

* Authentication: Who you are
* Authorization: What you are allowed to do

## Vulnerabilities

### Password based

#### Username enumeration

Try to spot differences in:

* Status codes
* Error messages
* Response times (use a very long password to increase the difference in response time)
* If an account is being locked, it probably means, that account exists ;-)

#### Brute-force protections

**Blocking IP address**

* If `X-Forwarded-For` header is supported, try to change it for each request.
* Sometimes logging in to a valid account will reset your failed count.

**Locking the user account**

* Password spraying: Test a lot of different usernames, with just a few common passwords, to avoid being locked out.
* Credential stuffing: Use credentials from a breach of another site, as users often reuse their credentials.

**Rate limiting**

Too many login requests in a short period of time.

### Multi-factor

TODO

### OAuth

TODO

### Other vulnerabilities

#### Keep users logged in

Often implemented as a "remember me" token and then stored in a cookie.

* If the token is somehow guessable, it can be brute-forced (e.g. username:password, or username\_timestamp, ...).
* Even if you don't have a valid account for inspecting the cookie, you may be able to steal one from a valid user via XSS.
* If the password hash is contained in the cookie and not salted, you probably can even brute-force it to gain the plaintext representation.

#### Reset password

A password reset url should contain a high-entropy, hard-to-guess token, that is tied to that very user account in the back-end, expire after a short period of time and be immediately destroyed after the password has been reset.

* If just the username is provided here instead, you may just change it to any arbitrary one you like to.

**Password reset poisoning**

* [PortSwigger - Web Security Academy - Password reset poisoning](https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning)

#### Change password

Password change pages are often affected by the same type of vulnerabilities as login pages.

* If the username is sent via hidden field, you may be able to change it to any arbitrary username.