Some applications use elaborate login mechanisms involving multiple stages.
For example:
■ Entry of a username and password.
■ A challenge for specific digits from a PIN or a memorable word.
■ The submission of a value displayed on a changing physical token.
Multistage login mechanisms are designed to provide enhanced security over the simple model based on username and password. Typically, the first stage requires the user to identify themselves with a username or similar item, and subsequent stages perform various authentication checks. Such mechanisms frequently contain security vulnerabilities, and in particular various logic flaws.
Some implementations of multistage login mechanisms make potentially unsafe assumptions at each stage about the user’s interaction with earlier stages. For example:
■ An application may assume that a user who accesses stage three must have cleared stages one and two. Therefore, it may authenticate an attacker who proceeds directly from stage one to stage three and correctly completes it, enabling an attacker to log in with only one part of the various credentials normally required.
■ An application may trust some of the data being processed at stage two because this was validated at stage one. However, an attacker may be able to manipulate this data at stage two, giving it a different value than was validated at stage one. For example, at stage one the application might determine whether the user’s account has expired, is locked out, or is in the administrative group, or whether it needs to complete further stages of the login beyond stage two. If an attacker can interfere with these flags as the login transitions between different stages, they may be able to modify the behavior of the application and cause it to authenticate them with only partial credentials or otherwise elevate privileges.
■ An application may assume that the same user identity is used to complete each stage; however, it might not explicitly check this. For example, stage one might involve submitting a valid username and password, and stage two might involve resubmitting the username and a value from a changing physical token. If an attacker submits valid data pairs at each stage, but for different users, then the application might authenticate the user as either one of the identities used in the two stages. This would enable an attacker who possesses his own physical token and discovers another user’s password to log in as that user (or vice versa). Although the login mechanism cannot be completely compromised without any prior information, its overall security posture is substantially weakened and the substantial expense and effort of implementing the two-factor mechanism does not deliver the benefits expected.
Some login mechanisms employ a randomly varying question at one of the stages of the login process. For example, after submitting a username and password, the user might be asked one of various “secret” questions (regarding their mother’s maiden name, place of birth, name of first school, etc.) or to submit two random letters from a secret phrase. The rationale for this behavior is that even if an attacker captures everything that a user enters on a single occasion, this will not enable them to log in as that user on a different occasion, because different questions will be asked.
In some implementations, this functionality is broken and does not achieve its objectives:
■ The application may present a randomly chosen question, and store the details of the question within a hidden HTML form field or cookie, rather than on the server. The user subsequently submits both the answer and the question itself. This effectively allows an attacker to choose which question to answer, enabling the attacker to repeat a login after capturing a user’s input on a single occasion.
■ The application may present a randomly chosen question on each login attempt but not remember which question a given user was asked in the event that he or she fails to submit an answer. If the same user initiates a fresh login attempt a moment later, a different random question will be generated. This effectively allows an attacker to cycle through questions until they receive one to which they know the answer, enabling them to repeat a login having captured a user’s input on a single occasion.
Insecure Storage of Credentials
If an application stores login credentials in an insecure manner, then the security of the login mechanism is undermined, even though there may be no inherent flaw in the authentication process itself.
It is very common to encounter web applications in which user credentials are stored in unencrypted form within the database. Because the database account used by the application must have full read/write access to those credentials, many kinds of other vulnerabilities within the application may be exploitable to enable you to access these credentials — for example, command or SQL injection flaws or access control weaknesses.
NEXT is..Securing Authentication…,,,