Skip to main content

What it does not cover

The package closes what Fortify's registration and password reset tell a caller. Some questions about an address can still be asked elsewhere in an application, and some of what the package does has edges worth knowing.

Signing in​

Fortify already answers a failed sign-in with the same message, whether the address has an account or the password is wrong. What still differed was the time: a known address costs a password check and an unknown one does not. The package closes that through the minimum duration, which Laravel applies to a failed sign-in as well. Two-factor challenges and passkeys come after a successful credential check and are not touched.

Changing the address of an account​

Fortify's UpdateUserProfileInformation stub checks a new address with a unique rule. A signed-in user can therefore try other people's addresses one at a time and read the answer. The package does not cover this route, because the answer belongs to the application: the user changing their address is allowed to learn that it is in use. If that is not acceptable, accept every address, send a confirmation link to the new one, and switch only once it is confirmed, and throttle the route either way.

The application's own endpoints​

An invitation form, a newsletter sign-up, an API that checks whether an address is free, or a front end that validates the address while the user types can each answer the same question. Use the assertion on those endpoints as well.

Requests are not throttled​

The package counts mails per address, not requests. Keep a throttle on the registration route and on the password routes: it stops a caller from trying many addresses quickly, which the neutral answers make pointless but do not make cheap.

Equal, not constant time​

The package removes the systematic differences in time, the password hash and the work of the password broker. A request's duration still varies with the load of the server and the network, and work that runs past the minimum duration, such as mail sent through a slow transport while the request waits, shows again. Queue mails, keep the minimum above the time your slowest server needs for one hash, and measure on your own infrastructure if the difference matters to you.