The present invention relates to password use to protect various user accounts, and in particular to a service in a server to obtain and discern passwords to better protect user accounts.
Conventionally, most systems remember the user's previous N passwords, in order to have the user create a different password. This only keeps a history of that account, not from the person.
The present invention provides for a service to obtain and discern a user's likely passwords. One password likely has no information on its own. Several passwords put together may contain small bits of information about a user, such as hobbies or interests (especially if passwords are key words or phrases, or are somehow related to each other).
A method for enhanced login is described including determining if a user is attempting to login to a particular account, performing analysis on the user's passwords if the user is not attempting to login to the particular account, determining is it is time to change a password on the particular account, if the user is attempting to login to the particular account, suggesting alternative passwords to the user based on the password analysis and performing a login procedure.
The present invention is best understood from the following detailed description when read in conjunction with the accompanying drawings. The drawings include the following figures briefly described below:
The present invention provides for a service to obtain and discern a user's likely passwords. A single password likely has no information on its own. Several passwords put together may contain small bits of information about a user, such as hobbies or interests especially if passwords are keywords or phrases, or are somehow related to each other.
Passwords may also give information about a user's technical competence, such as their security practices (length of passwords, similarities, use of common “dictionary” words). A set of passwords may also give a mask of common characteristics, such as always capitalizing the third letter or always putting a punctuation at the beginning, or different words of varying lengths users may commonly modify (e.g., password must be 6 characters long, user always has “ball” and two special characters. Password must be 8 characters long, user always has “tennis” and two special characters. Password must be 12 characters long, user always has “tennis” and “ball”, with two special characters.)
Once a service knows its user's likely passwords, it can do several things. First, it can determine if the user is using hobbies and interests to formulate their password, and market products towards the user. If the user is technically incompetent (i.e. passwords are matched against other very common passwords), it can guide the user as to how to pick a better password. If the user has a set of common characteristics between their passwords, the service can make recommendations to help the user diversify their passwords.
Also, as a consequence of the present invention, an account becomes more secure from a brute force attack. The owner of the account is likely to re-enter their password, where a brute force attempt will continue, and ignore the “wrong” password.
The present invention provides a method to obtain likely passwords a person has with other profiles or accounts (for instance, email accounts or logins unrelated to the current service.)
The present invention also can help to protect from brute force attacks on inactive accounts, by doubling the amount of time required to log in to an account.
When a user forgets their password for a particular service/account, before resetting their password they are likely to volunteer their “best guess” as to what their password might be, based on similar patterns they use for other accounts. Understanding this behavior, a service can trigger that behavior if the service detects the user is guessing their password. The service will then automatically tell the user they are using the wrong password on their first try. The user may then volunteer their other “best guesses” in order to gain access to their account. If the first password was actually correct, and the user later enters that password, they will have access to their account. The user will then likely blame the lock out on a typo, and will have provided their other passwords.
These password guesses can be stored for later, and can be used to generate a profile of a user's interests, a user's technical or security competence, a user's password pattern, or even help suggest a new password (which passwords not to use) in the event a password expires. Password information can also be used to help train a user to be more secure.
In order for the server to determine if the user can login, several steps must be taken. The first step, the most obvious, is if the password the user enters is correct or not. If the user enters the incorrect password, the user cannot log in. The server then records the details of the login attempt (e.g. account, time, password used). The server then checks the number of incorrect attempts, and if the number is greater than a threshold, locks the account for a time period. If the threshold has not been reached, the server then allows the user to try logging in again.
If the user enters the correct password, several decisions have to be made. If the user has logged into their account recently, or if the user auto filled the field (time password was entered was near zero, as if the password was stored in the browser, as well as a perfect match on the first attempt), the server is more likely to allow the user to log in directly.
If the user had not logged in recently, and the field was not auto filled, the server is more likely to tell the user that they are not allowed to log in. If the server tells the user it cannot log in even though the account details are correct, the threshold for number of log in attempts is increased. If the user enters the correct password again (twice in a row), the user is automatically allowed access.
During server idle time, the server can then examine passwords a user supplied incorrectly in an attempt to determine a common theme, as described above.
It is to be understood that the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Special purpose processors may include application specific integrated circuits (ASICs), reduced instruction set computers (RISCs) and/or field programmable gate arrays (FPGAs). Preferably, the present invention is implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage device. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s). The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may either be part of the microinstruction code or part of the application program (or a combination thereof), which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device.
It is to be further understood that, because some of the constituent system components and method steps depicted in the accompanying figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US12/65079 | 11/14/2012 | WO | 00 |