Non-Unique Usernames
Some applications that support self-registration allow users to specify their own username, and do not enforce a requirement that usernames be unique. Although rare, the authors have encountered more than one application with this behavior.
This represents a design flaw for two reasons:
■ One user who shares a username with another user may also happen to select the same password as that user, either during registration or in a subsequent password change. In this eventuality, the application will either reject the second user’s chosen password or will allow two accounts to have identical credentials. In the first instance, the application’s behavior will effectively disclose to one user the credentials of a different user. In the second instance, subsequent logins by one of the users will result in access to the other user’s account.
■ An attacker may exploit this behavior to carry out a successful brute- force attack, even though this may not be possible elsewhere due to restrictions on failed login attempts. An attacker can register a specific username multiple times with different passwords, while monitoring for the differential response that indicates that an account with that username and password already existed. The attacker will have ascertained a target user’s password without making a single attempt to log in as that user.
Predictable Usernames
Some applications automatically generate account usernames according to some predictable sequence (for example, cust5331, cust5332, etc.). When an application behaves like this, an attacker who can discern the sequence can very quickly arrive at a potentially exhaustive list of all valid usernames, which can be used as the basis for further attacks. Unlike enumeration methods that rely on making repeated requests driven by wordlists, this means of determining usernames can be carried out very non-intrusively with minimal interaction with the application.
Predictable Initial Passwords
In some applications, users are created all at once or in sizeable batches and are automatically assigned initial passwords, which are then distributed to them through some means. The means of generating passwords may enable an attacker to predict the passwords of other application users. This kind of vulnerability is more common on intranet-based corporate applications — for example, where every employee has an account created on their behalf, and receives a printed notification of their password.
In the most vulnerable cases, all users receive the same password, or one closely derived from their username or job function. In other cases, generated passwords may contain sequences that could be identified or guessed with access to a very small sample of initial passwords.
Insecure Distribution of Credentials
Many applications employ a process in which credentials for newly created accounts are distributed to users out-of-band of their normal interaction with the application (for example, via post or email). Sometimes, this is done for reasons motivated by security concerns — for example, to provide assurance that the postal or email address supplied by the user actually belongs to that person.
In some cases, this process can present a security risk. For example, if the message distributed contains both username and password, there is no time limit on their use, and there is no requirement for the user to change password on first login, then it is highly likely that a large number, even a majority, of application users will not modify their initial credentials and that the distribution messages will remain in existence for a lengthy period during which they may be accessed by an unauthorized party.
Sometimes, what is distributed is not the credentials themselves, but rather an “account activation” URL, which enables users to set their own initial password. If the series of these URLs sent to successive users manifests any kind of sequence, then an attacker can identify this by registering multiple users in close succession, and then infer the activation URLs sent to recent and forth coming users.
NEXT is..Implementation Flaws in Authentication…..,,,
