Password sign-in

Players can sign in with their email address and a password. Setting a first password and resetting a forgotten one both use a six-digit code sent to the player's email address.

1. Turn it on for an application

Password sign-in is off by default and is turned on for one application at a time. Email sign-in must stay on for the project, because codes for setting and resetting passwords are sent by email.

1. Open the project in the console and go to Applications.
2. Open a browser or game application.
3. Under Password sign-in, tick Let players sign in with a password.
4. Select Save password sign-in.

Owners and admins can change the setting; viewers see it read-only. Your application needs no code changes. The hosted login page adds Continue with a password belowContinue with email.

For a game application, Continue with a password appears on the device approval page, and the guest upgrade page offers Create a password. Browser applications offer Create a password on their guest upgrade window too.

What players see

• Sign in. The player enters their email address and password. A wrong password, an address with no account and an account with no password all get the same message, so the page can't be used to find out who has signed up.
• Set a first password, or reset one. The player selects Forgot your password, or setting one up? and enters their email address. auth4.dev emails a six-digit code. The player enters the code and a new password, and is signed in. A player who signed in with email codes before sets a password this way.
• Change it. The player enters their current password and a new one.

A password belongs to the player's email address in your project. Signing in with a password or with an email code reaches the same player, with the same sub. When sign-up is turned on, setting a password for a new address creates a player account. When it's off, only existing players can set one.

Codes work as they do for email sign-in: they expire after ten minutes, a new code replaces the earlier one, and they share the same sending limits. The email contains only the code, never a link that sets a password.

Signing out open sessions

Resetting or changing a password signs the player out of sessions that are already open in your project. Their refresh tokens stop working, and the hosted login no longer remembers them in other browsers. Sessions in your other projects aren't affected.

• Reset. Every open session ends, including the one in the browser that made the reset. The player is signed in again when the reset finishes.
• Change. Every other session ends, and the session in the browser making the change stays open. To end that one too, send keep_current_session: false with the change request.
• Setting a first password replaces nothing, so it leaves email-code sessions open.

Your application sees a refresh fail with invalid_grant and should send the player to sign in again. Each sign-out is recorded in the audit log asauthentication.password.sessions_revoked, and webhooks receive a session.revoked event with the reason password.

Password rules

The breached-password check uses the Pwned Passwords range API. Only the first five characters of a hash of the new password are sent; the password itself never leaves auth4.dev. If the service can't be reached, the password is accepted so players are never stuck.

Attempts and lockout

After 10 wrong attempts from one network, password sign-in for that address pauses on that network for 15 minutes. Someone guessing from another network can't lock the player out. The limit of 100 attempts per address stops guessing spread over many networks.

Both limits lift on their own. When a player resets their password with an email code, the 100-attempt limit and the limit for their own network lift at once. Players can still sign in with an email code meanwhile.

How passwords are stored

auth4.dev stores a salted PBKDF2-SHA256 hash with a work factor of 600,000 iterations, never the password. Setting, resetting and changing a password, and each password sign-in, are recorded in the project's audit log without the password or email address. Deleting a player deletes their password hash.

Saving guest progress with a password

On the guest upgrade page, Create a password asks for an email address, emails a six-digit code, and sets the password when the player enters the code and a new password. The player then confirms the link, and the guest keeps its user ID. If the address already belongs to another player, the password is set for that player, as a reset would, and the guest is not upgraded: the page explains that the account is already in use. Accounts are never merged.