> For the complete documentation index, see [llms.txt](https://0xn3va.gitbook.io/application-security-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xn3va.gitbook.io/application-security-handbook/web-application/authentication/authentication-with-login-and-password.md).
# Authentication with Login and Password
## Overview
This page contains recommendations for the implementation of the authentication scheme where login (username, email, etc.) and password are used as proof of identity.
## General
* Implement the authentication on the server side. In other words, all authentication decisions must be made on the server side.
* Do **not** send passwords in an URL (in the path, query, or fragment).
* Do **not** send passwords in HTTP headers.
* Do **not** use HTTP Basic Authentication.
* Do **not** use password hints or knowledge-based authentication (so-called "secret questions").
* Return the same error message for an incorrect password for an existing and non-existing username.
* Comply with requirements from the [Error and Exception Handling](/application-security-handbook/web-application/error-and-exception-handling.md) page.
* Log all authentication decisions (successful and not successful), see the [Logging and Monitoring](/application-security-handbook/web-application/logging-and-monitoring.md) page.
* Successful authentication
* Failed authentication
* Successful password reset
* Failed password reset
* Successful password changing
* Failed password changing
* Comply with requirements from the [Sensitive Data Management](/application-security-handbook/web-application/sensitive-data-management.md) page.
* Limit the number of attempts to sign in for a certain period, see the [Vulnerability Mitigation: Brute-force](/application-security-handbook/web-application/vulnerability-mitigation/brute-force.md) page.
* Enforce multi-factor authentication, see the [Authentication: Multi-factor Authentication](/application-security-handbook/web-application/authentication/multi-factor-authentication.md) page.
* Implement injection protection for login and password arguments, see:
* [Vulnerability Mitigation: Command injection](/application-security-handbook/web-application/vulnerability-mitigation/command-injection.md)
* [Vulnerability Mitigation: SQL injection (SQLi)](/application-security-handbook/web-application/vulnerability-mitigation/sql-injection.md)
* [Vulnerability Mitigation: XML External Entity (XXE) Injection](/application-security-handbook/web-application/vulnerability-mitigation/xml-external-entity-xxe-injection.md)
* Notify a user via an available communication channel (email, push, SMS, etc.) about successful login under their account from an unknown location, browser, client, etc.
## Login management
* The login must be unique. Make sure values have been truncated before checking.
* If emails are used, implement the email address validation, see the [Authentication: Email Address Confirmation](/application-security-handbook/web-application/authentication/email-address-confirmation.md) page.
* If usernames are used, handle usernames as case-insensitive strings.
* If usernames are used, implement username validation, see the [Input Validation](/application-security-handbook/web-application/input-validation.md) page. The validations must include at least the following checks:
* The username only contains alphanumeric characters and hyphens or underscores.
* The username can not start with hyphens or underscores.
* The username length is more than 1.
* The username length is less than 64.
* Assign usernames for users instead of using user-defined public data.
* If emails are used, ask for authentication from a user when changing email.
## Password management
* Do **not** set default passwords during registration or password reset. Allow a user to set their password.
* If you are setting default passwords, comply with recommendations from the [Authentication: Default Passwords](/application-security-handbook/web-application/authentication/default-passwords.md) page.
* Validate passwords against the password policy, see the [Authentication: Password Policy](/application-security-handbook/web-application/authentication/password-policy.md) page.
* Implement password comparisons in constant time. In other words, the password comparison should **not** depend on the provided values.
* Store passwords in a secure way, see the [Authentication: Password Storage](/application-security-handbook/web-application/authentication/password-storage.md) page.
* Implement the password change, see the [Authentication: Password Change](/application-security-handbook/web-application/authentication/password-change.md) page.
* Implement the password reset, see the [Authentication: Password Reset](/application-security-handbook/web-application/authentication/password-reset.md) page.
* Implement a mechanism to force a user's password reset. You can reuse standard password reset for implementation of this mechanism.
Clarification
In case of password compromise, there should be a way to reset passwords for a bunch of users.
* Terminates all active sessions after a successful password change and reset. Do the termination across an application, federated login (if present), and any relying parties.
* Notify users if their password has been changed or restored. Add the `What should I do if it wasn't me?` section with a link to a password reset page and other relative pages (multi-factor authentication set-up, support contacts, etc.).
## References
* [OWASP Cheat Sheet Series: Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#logging-and-monitoring)