Accessing a computing resource

[0001] The present invention relates generally to accessing a computing resource, and more specifically, to authenticating a user requesting access to a computing resource.

[0002] Many computing resources (e.g. a computer system) require a user to authenticate by entering a password before gaining access to a particular resource.

[0003] The present invention provides a method, and an associated computer system and computer program product. One or more processors of a computer system receive a login request, from a user, to log into a computing resource, wherein the login request includes a password and a user identifier of the user. The one or more processors compare the received password with a stored password to determine whether to grant access to the computing resource. Responsive to determining that the received password does not match the stored password, the one or more processors determine an authenticity of the login request based on one or more characteristics of the user and/or one or more checks performed against the received password. The one or more processors calculate a score based on the determined authenticity of the login request. The one or more processors deny the login request. Based on the calculated score, the one or more processors decide whether to lock the user and deny the user further access to the computing resource.

[0010] It should be understood that the Figures are merely schematic and are not drawn to scale. It should also be understood that the same reference numerals are used throughout the Figures to indicate the same or similar parts.

[0011] A user is typically allowed a specified number of failed attempts at entering a correct password before the user's account is locked, which represents an issue for legitimate users who may have forgotten the legitimate users' password. Alternatively a malicious attacker may submit multiple invalid logins in order to purposely lock a user out.

[0012] In the context of the present application, where embodiments of the present invention constitute a method, it should be understood that such a method is a process for execution by a computer; i.e., the process is a computer-implementable method. The various steps of the method therefore reflect various parts of a computer program; e.g., various parts of one or more algorithms embodied within the computer program.

[0013] There is provided, in accordance with embodiments of the present invention, a solution which attempts to prevent account lockout of authorized (legitimate) users after a specified number of failed attempts at gaining access to a resource. A scoring system is used to determine a likelihood that an attempt is from an attacker and to weight each failed attempt accordingly. An account may have a certain number of credits associated with the account, and the system will deduct one or more credits in response to receipt of an invalid login attempt, wherein the login attempt is highly likely to have come from a non-authorized entity. In response to an account having no more associated credits, a user(s) is locked out.

[0014] FIG. 1 provides a high level overview of embodiments of the present invention. A user 10 attempts to login to a resource by providing a set of user credentials which may include, inter alia, a user name (identifier) and a user password. The resource may, for example, be a website, an application or a computer system (none of which are shown in FIG. 1). The resource may have the resource's own built-in or associated authentication mechanism (e.g., security software) or may forward the login request to an authentication server 30. The login request to the authentication server 30 may go via a reverse proxy 20. In another embodiment, the reverse proxy 20 may be omitted entirely. Authentication server 30 then makes a determination as to whether the user's login request should be allowed. Such a determination of whether the user's login request should be allowed is made by accessing password store 40, which stores passwords associated with user accounts for which the authentication server 30 is responsible. The passwords associated with user accounts may be stored as a hash digest of the password rather than plaintext, as hash digests created via cryptographic hash algorithms provide an extra layer of security should the authentication server become compromised. If the submitted password is found not to match the stored password for the requested user account, then the requesting user 10 is not necessarily locked out. Instead, authentication server 30 checks authentication policy 50 to make a determination as to whether the requesting user 10 is likely to be a legitimate user (who has forgotten the user's password or made a minor mistake) versus an attacker. It will be appreciated that an attacker may, for example, be a human, but may equally be an automated bot submitting hundreds of such requests.

[0015] The login attempt is weighted accordingly, and a failed attempt is reported back via reverse proxy 20 to user 10. The authentication server 30 weights the failed attempt based on authentication policy 50 and makes a decision whether or not to lock the user account. The authentication server may or may not report a locked account back to the user 10.

[0016] FIG. 2 is an exemplary component diagram showing the components of the authentication server 30, in accordance with embodiments of the present invention. FIG. 2 should be read in conjunction with FIGS. 3a, 3b and 3c, which show a flow chart of embodiments of methods of the present invention.

[0017] In FIG. 3, a user 10 attempts a login at step 200 via a login request that may be transmitted to the reverse proxy 20 at step 210, if reverse proxy 20 is present. In step 210, the reverse proxy 20 may add additional detail to the login request such as, inter alia, a source IP address or location information. The reverse proxy 20 is able to query the requester or a separate service/database for such additional information. The reverse proxy 20 then forwards the login request to authentication server 30 at step 220. Authentication server 30 comprises a login component 100. A password receiving component 110 (within login component 100) receives the user's login request at step 230 after which processing proceeds to step 240 in FIG. 3b, with password checker component 120 performing a password check using password store 40. As discussed above, valid passwords (i.e., those passwords which grant access to a computing resource) may be stored as hash values. Hash values generated using a cryptographic hash algorithm cannot be reversed and therefore add an additional level of security. A received password is run (by the password checker component 120) through a cryptographic hash function to create a hashed version of the received password, and password checker 120 compares the hashed version of the received password with a stored (hashed) version of the password.

[0018] If the submitted (received) password is correct (i.e. matches the stored version of the password), then score calculating component 150 resets a score associated with the user's account (steps 250, 260) and access granting component 130 issues a session token to the user 10, which grants the user 10 access to the user's requested resource (step 265). Processing then moves FIG. 3C and ends.

[0019] Embodiments of the present invention includes case(s) in which the check fails at step 250, thereby indicating that the user 10 submitted an incorrect password. Policy checker 140 checks the authenticity of the request at step 270 using authentication policy 50, and score calculating component 150 calculates (finalizes) a score based on a likely authenticity of the request (step 275). Therefore, a specified number of successive failed login attempts does not necessarily cause a user's account to be locked. Each such failed login attempt is assessed and weighted based on a likelihood that the failed login attempt has come from either an attacker or a legitimate user. Such an assessment affects an overall score associated with the account for which access is being requested. This score is calculated by score calculating component 150. Step 270, along with the calculation of a score at step 275 by component 150, will be discussed in more detail later with reference to FIGS. 4a and 4b.

[0020] After step 275 is executed, processing moves to step 280 in FIG. 3C. Based on how likely it is that the login request has come from a legitimate user (rather than from an attacker) and after the score is calculated (finalized) at step 275, a determination is made by account locking component 160 at step 280 as to whether to lock the requesting user 10 out of the requesting user's account. If a positive determination is made at step 280, then the user's account is flagged (at step 290) as locked by component 160. In one embodiment, this lockout of the user 10 is only reported to the user 10 in response to a subsequent attempt to login. Processing moves to step 295. In an alternative embodiment, however, the user 10 is informed that the user 10 is now locked out of the user's account.

[0021] If it is determined at step 280 that the user 10 should not be locked out of the user's account, then failure reporting component 170 informs the user 10 at step 295 that the user's login attempt has failed. This information (i.e., the user's login attempt has failed) is transmitted from the authentication server 30 via the reverse proxy 20 to the user 10, as is shown in FIG. 1.

[0022] While not shown in the flowchart of FIG. 3, it will be appreciated that a first step in response to receipt of a login attempt may be to check that the user account is not locked.

[0023] Authentication policy 50 includes a set of modifiers (or input parameters) which may be used (applied) at step 270 to determine an authenticity of the login request and which have impact on the score calculated.

[0024] Some exemplary modifiers which may be included in authentication policy 50 are:

[0025] 1) Password matches password policy (length, character set, case sensitivity of password);

[0026] 2) Previous password (based on a password history, looking for automated patterns);

[0027] 3) Passwords that are words based on a dictionary attack or user personal information;

[0028] 4) Passwords based on company name or an abbreviation for a company name or public information;

[0029] 5) Location where the login request originated, time of the login request, and/or time zone;

[0030] 6) Wi-Fi access point (e.g. connected or mobile network);

[0031] 7) Application used to request access (e.g., Browser—type, version, plugins);

[0032] 8) Platform;

[0033] 9) Platform specific parameters (e.g., screen size, resolution, language, etc.); and

[0034] 10) Speed of submission attempts.

[0035] The modifiers may fall into two overlapping groups:

[0036] 1. Those modifiers that identify activity typical to a legitimate user (such as using an old password or a user authenticating from the same (usual) location or with the same (usual) browser characteristics); and

[0037] 2. Those modifiers that identify activity typical to an attacker (such as using a password based on a dictionary attack).

[0038] Many of the modifiers can be classified as those that differentiate legitimate users from attackers based on some characteristic of the user rather than the password being used to authenticate.

[0039] The modifiers are used to calculate an overall score for each invalid (failed) login attempt. Each such attempt is assessed and weighted based on a likelihood that the attempt has come from either an attacker or a legitimate user. Such an assessment then affects an overall score associated with the account for which access is being requested.

[0040] By way of example only, after each successful login, the score calculating component 150 sets 100 credits against the user account for which access is being requested. For every failed attempt to login, score calculating component 150 deducts a number of credits, and account locking component 160 locks the account when credits=0 (or another suitable threshold is reached). The number of credits deducted for each failed login attempt varies depending on whether the modifiers indicate that the attempt is likely to be from a legitimate user or from an attacker. So if policy checker 140 observes that the user is coming from an untrusted new location or that the password is based on a dictionary attack, which is a very typical type of attack for password guessing, the number of credits that score calculating component 150 deducts would be a relatively higher number (e.g., 20 credits).

[0041] If the password is a same password as an old password, or the user comes from a trusted location, then the number of credits that score calculating component 150 deducts would be a relatively smaller number (e.g., 10 credits). If a large number of failed attempts happened in a short period of time with the same password and from trusted locations, then score calculating component 150 could reduce the number of credits for each of those failed attempts even further.

[0042] Score calculating component 150 may use a lookup table to determine the weight to apply to a particular failed attempt and consequently the number of credits to deduct.

[0043] The process for determining the authenticity of the user, in accordance with embodiments of the present invention, is discussed in more detail with reference to FIGS. 4a and 4b.

[0044] Processing in accordance with embodiments of the present invention is performed by evaluation component 180, score calculating component 150 and policy checker 140 (see FIG. 2). Evaluation component 180 has overall control but passes control to policy checker 140 and score calculating component 150 as appropriate. The passing of control between the various components is not shown in FIGS. 4a and 4b. In one embodiment, components 140 and 150 form part of evaluation component 180. In another embodiment, score calculating component 150 forms part of policy checker 140.

[0045] At step 300, evaluation component 180 directs policy checker 140 to access authentication policy 50. As previously indicated, the authentication policy 50 includes a number of modifiers. Policy checker 140 accesses the first of these modifiers at step 310. Policy checker 140 then determines at step 320 whether the password attempt, taking the modifier into account, indicates that the password attempt is likely to be from an attacker. Control is then returned to evaluation component 180, which passes control to score-calculating component 150. If there is a negative determination made at step 320 (i.e., the password attempt is likely to be a legitimate user), then score calculating component 150 lowers a weight associated with the password attempt and deducts a relatively smaller number of credits from the total number of credits associated with the user account at step 330. On the other hand, if it is determined in step 320 that the password attempt is likely to be from an attacker, then score calculating component 150 increases the weight and deducts a relatively larger number of credits from the total number of credits associated with the user account at step 340. Control is then returned to evaluation component 180.

[0046] After step 340 is executed, processing proceeds to step 350 in FIG. 4b. Evaluation component 180 passes control to policy checker 140 which determines whether the ‘End Of File’ (EOF) has been reached. In other words, policy checker 140 determines whether the last of the modifiers has been taken into account when considering whether the password attempt is likely to be from a legitimate user or from an attacker. If there are one or more additional modifiers that the login attempt needs to be evaluated against, then processing proceeds back to step 310 in FIG. 4a. Policy checker 140 then evaluates the next modifier in the list and raises or lowers the weight as necessary and deducts an appropriate number of credits from the total number of credits associated with the account for which access is being requested.

[0047] If the last modifier has been evaluated, then control is returned to evaluation component 180 which then requests that score calculating component 150 finalizes the score associated with the invalid login attempt, which is done at step 360. Based on the final score, evaluation component 180 determines (at step 370) whether the attempt is likely to be from a legitimate user or from an attacker. Processing then ends.

[0048] As indicated above, the score is associated with a user's login account and is carried over between invalid login attempts. The score may continue decreasing until 0 (or until another appropriate threshold) is reached or until a successful login attempt is received and the score is reset. Score calculating component 15 may reset the score back to the full amount (e.g. 100) or to an amount that is above the threshold.

[0049] The processing performed for some of the modifiers with respect to step 320 is discussed in further detail below.

[0050] Password Policy

[0051] It is determined whether the password is in accordance with the password policy (not shown in FIG. 1). The password policy may set rules as to length, character set, case sensitivity etc. If the submitted password does at least comply (or mostly comply) with a specified password policy, then at step 330, the weight is lowered by a relatively smaller amount, since the login attempt is likely to be from a legitimate user.

[0052] Passwords Based on a Known Dictionary or Containing User Personal Information

[0053] The password is checked against a list of known dictionary of bad passwords such as “12345678”, “password” or passwords that can be easily guessed (such as user login). Such passwords may indicate an attack and thus have more weight.

[0054] The provided password is also checked for publicly available personal information, which would add weight to the likelihood that the login attempt is from an attacker as opposed to a legitimate user.

[0055] Location from which the Request Originates/Wi-Fi Access

[0056] The location from which the user 10 connects is determined. The location could be the IP address, the network or a location identified by any location service technology. Whether the Wi-Fi access comes from a connected or mobile network is also determined. New or unknown configurations add more weight.

[0057] Machine Configuration

[0058] The authentication server 30 may store a fingerprint of the client machine configuration (browser type, version, plugins, platform, screen resolution, language etc.) from which the user 10 typically logs into the user's account. The authentication server 30 will then check how the client machine compares to the machine from which this login request originates. If the authentication server 30 determines that the client machine configuration is a new configuration, then relatively more weight would be added to the likelihood that this attempt is from an attacker.

[0059] There are many papers and descriptions of how an individual client machine can be identified with a fingerprint, which will not be described herein in any further detail.

[0060] Speed of Submission

[0061] Submissions done in rapid succession may indicate an automated attack against a user's account. A typical user pauses or types slowly between attempts to review the user's password submission. An automated brute force attack would repeat password attempts quickly.

[0062] Previous Password Attempts

[0063] An action of the user 10 using a previous password lowers the weight. A threshold may be set to indicate a password for an acceptable time period; e.g., any password valid within the last 3 months.

[0064] In one embodiment, using the same password a specified number of times lowers the weight. In an example, after changing the user's password, the user 10 gets immediately revoked, because there are multiple clients trying to connect with the old password. However, from the attack point of view, this is only a single password test just repeated a specified number of times.

[0065] In one embodiment, password submissions are compared with previous password attempts to look for a pattern in the previous password attempts. A typical user would not rotate through a common pattern of strings (ex. password, password1, password2). Looking for patterns in previous password attempts (i.e., previously received invalid passwords) could help identify a brute force attack by an automated system in order to guess a user's password. Such a pattern of password attempts would therefore add weight to the likelihood that the previous password attempts are from an attacker.

[0066] If there are several matches (e.g., a request coming from a new location with a password based on a dictionary of known passwords and from a new platform), in one embodiment, a specific configuration pertaining to the several matches would be blocked, allowing the legitimate user to continue logging in from the user's regular configuration settings.

[0067] As mentioned above, embodiments of the present invention are particularly concerned with systems which store user passwords as hash values, which is done to protect the integrity of user passwords should the authentication server 30 ever be compromised. Storing passwords in clear text is often not a sensible option. Other systems encrypt user passwords, but if the decryption key is discovered, then a resource becomes vulnerable. Hashed user passwords, on the other hand, are seen as more secure as long as a cryptographically secure hash algorithm generates them. Cryptographic hash functions make the password storage more secure, but also bring additional challenges. Because the hashes are cryptographically secure, the output of a hash cannot easily be compared for differences, which is different from storing encrypted versions of passwords, since an encrypted password can be decrypted.

[0068] Password modifiers 1, 3 and 4, listed above are still valid in a system which stores hashed passwords, as the rules can be checked against a non-hashed version of the password. The checking of the rules may be done upfront before a comparison is made between a hashed version of the received password and the hashed version of the password protecting the user account. The results of any checks are then stored for use in determining the authenticity of a user should the user's password submission be found to be invalid (i.e., not to match). Of course, such checks could be done only in response to discovering that the two passwords do not match, but this could mean (in some cases) temporarily storing a plaintext version of the received password which could compromise security.

[0069] With respect to password modifier 2, previous password hashes can be retained, which is a better approach than retaining non-hashed versions that could compromise security by enabling an attacker to guess the correct password from previous incorrect submissions. Hashes of a certain number of previous invalid password submissions could also be retained for checking against. Retaining plaintext versions of a predetermined number of invalid attempts (so that patterns can be identified) could be implemented but may compromise security (i.e., enable an attacker to guess the correct password) and thus may not be a sensible option.

[0070] Referring to FIG. 5, an exemplary system for implementing embodiments of the invention includes a data processing system 600 (which is an example of authentication system 30) suitable for storing and/or executing program code including at least one processor 601 coupled directly or indirectly to memory elements through a bus system 612. The memory elements may include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

[0071] The memory elements may include system memory 602 in the form of read only memory (ROM) 604 and random access memory (RAM) 605. A basic input/output system (BIOS) 606 may be stored in ROM 604. Software 607 may be stored in RAM 605 including system software 608 such as operating system software 609. Software applications 610 may also be stored in RAM 605 and may include login component 100.

[0072] The system 600 may also include a primary storage means 611 such as a magnetic hard disk drive and secondary storage means 612 such as a magnetic disc drive and an optical disc drive. The drives and their associated computer-readable media provide non-volatile storage of computer-executable instructions, data structures, program modules and other data for the system 600. Software applications may be stored on the primary and secondary storage means 611, 612 as well as the system memory 602.

[0073] The system 600 may operate in a networked environment using logical connections to one or more remote computers via a network adapter 616.

[0074] Input/output devices 613 may be coupled to the system 600 either directly or through intervening I/O controllers. A user may enter commands and information into the system 600 through input devices such as a keyboard, pointing device, or other input devices (for example, microphone, joy stick, game pad, satellite dish, scanner, or the like). Output devices may include speakers, printers, etc. A display device 614 is also connected to system bus 612 via an interface, such as video adapter 615.

[0075] The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

[0076] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0077] Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

[0078] Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

[0079] Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

[0080] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

[0081] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0082] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0083] A computer program product of the present invention comprises one or more computer readable hardware storage devices having computer readable program code stored therein, said program code containing instructions executable by one or more processors to implement the methods of the present invention.

[0084] A computer system of the present invention comprises one or more processors, one or more memories, and one or more computer readable hardware storage devices, said one or more hardware storage devices containing program code executable by the one or more processors via the one or more memories to implement the methods of the present invention.

[0085] The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others or ordinary skill in the art to understand the embodiments disclosed herein.