A password identifies an account, not the person typing
When a password arrives, a website can verify that it matches an account without knowing who entered it. High-security services can look for additional clues about the login attempt and estimate whether it resembles the account holder’s usual activity.
The clues come from the device and connection
A site may recognize a browser through a small stored token, such as a cookie placed after a trusted login. It can also compare technical details: the device and browser type, the network or approximate location, and patterns such as how the login session is established. These clues are not all equally reliable. A cookie can be deleted or copied, and a person may legitimately sign in from a new phone or while traveling.
The site combines signals rather than relying on one magic identifier. A familiar device and network may make a login seem lower-risk; a sudden change, especially alongside other unusual signs, may raise concern. This is risk-based authentication: the system adjusts its response to how suspicious the attempt appears.
Suspicion can trigger another check
If the login looks unusual, the service might ask for a one-time code, a security key, or confirmation through a previously trusted device. It may also limit access or block the attempt. That extra step is not proof that the site recognized a particular person; it is a way to demand stronger evidence when the surrounding clues do not fit.
The tradeoff is unavoidable: strict checks can frustrate the real account holder, while lenient ones can let an intruder through. The system is judging the login’s context, not reading the typist’s identity from the password.
