An online bank I use requires inputting your username, navigating to a second page and then entering the password to login. What actual security advantage does this provide, if any?
- From a security control perspective, all it really does is slow down the ability of automated password probing software to perform their task of trying out multiple passwords. The site is hoping an attacker may choose a "softer" target instead of their site. As an actual security control, this technique is not particularly effective.
- Also, specifically for banks, this is one of several Industry approved "security enhancements" that the U.S. banking industry is requiring member banks to choose from. In the U.S. in 2011, all banks and credit unions were informed of new cybersecurity policy from the Federal Financial Institutions Examination Council (https://www.ffiec.gov/pdf/Auth-ITS-Final%206-22-11%20%28FFIEC%20Formated%29.pdf), along with authentication guidance presentations (https://chapters.theiia.org/western-new-york/ChapterDocuments/FFIEC%20Authentication%20Guidance.pptx). I remember the bank I use converting their login pages in 2012 and 2013 to meet the new standards before their annual audit, including moving the password to a separate page from the userid.
- Given all the stolen password lists, the separate stolen email address lists, the fact that most users use the same password on all the sites they have accounts at, and the fact that most sites stupidly (from a security perspective) force user-ids to be email addresses, there are new types of highly selective "low-and-slow" over-the-web password probing systems that take advantage of all the above. So the site is hoping that making the login sequence slower to do the automated password probing may make the attackers give up sooner.
- From a security UI design perspective, this UI design pattern does offer some useful advantages. It allows sites that adopt it to add conditional authentication steps. For example, a site can offer their users the option for a text-message token to create a two-factor authentication. For those users that provided a mobile number, the sequence may be: page1=enter userid, page2=enter token, page3=enter password. For those users that did not provide a mobile number, it is just page1=enter userid, page2=enter password.
- This UI design template also allows for gradual conversion of their user base to newer and stronger authentication both over-a-timespan and user-by-user, which are both critical considerations for a site with thousands or more of users.
- Another example, the bank I use in 2012 converted their login pages to first ask me for user id, then asks me to confirm an image I picked in my profile from a set of images, then finally asks for my password, all on separate pages. Whether or not picking an image from a set of images really adds any authentication effectiveness is a separate issue from the question about the login UI design template.
- A further example, some banks chose to implement a "UI Keyboard" to attempt to thwart key loggers (userid is entered on one page with a regular UI text field, then a second page is brought up with the "UI Keyboard". One can debate whether an on-screen keyboard is or is not effectivesecurity-wise, but the UI design pattern of configurable and sequential authentication on separate pages allows sites this freedom to innovate.
- Most sites do not prematurely end the login sequence if something is incorrectly entered. The end-user enters all information in the various pages of the sequence, and only at the end learns if authentication was successful or not. Some sites do exit early, which creates some institutional residual risk in terms of account validity detection.
- Which specific authentication steps are shown can even vary by the particular user-id given what that user selected in their profile. So sites that do this are not forced anymore to offer only one fixed authentication sequence for all their end-users.
- Even more advanced login systems of this style can even vary the authentication steps for the same end-user who fails a first authentication, or is accessing from an unknown computer/device, or from an IP address that is significantly out-of-area, or if the site's automated IDS software thinks a password probing attack is in-progress.
- So separating IDENTIFICATION from AUTHENTICATION (aka user-id from password and other steps) in the login UI gives sites more freedom and flexibility to evolve their login processes over time. Those sites that change their login pages to this new template can further adapt or alter the login sequence in the future, yet have their end-users not feel like the login process is changing all that much.
I have seen this used by many provides as a way to do Home Realm Discovery, when many IDPs are involved.
When a user types their email address in, the next screen will be the IDP or in case of many possible choices, a selection list, followed by a redirection.
Another possibility is that this technique confuses password managers, or built in chrome "remember my password" features. There are probably better ways of doing this, and if done for this reason alone it may result in security theatre.
Some sites may allow users to associate a non-confidential picture or phrase with their username, and show it before the user enters their password. Depending upon the mechanisms used to prevent man-in-the-middle situations, such an approach may make it more difficult for a phisher to make a page which, given a username, would quickly and smoothly call up the image/phrase associated with that user. In the absence of MITM-detection code, nothing would prevent a phisher from putting up a fake "username" screen, submitting the username from that into the bank's form, and then sending back the picture/phrase from the bank's system, but a bank's systems could incorporate various mechanisms to try to prevent that. Perhaps the biggest difficulty would be achieving compatibility with "security" software that tries to insert itself as a man-in-the-middle on https:// connections.
I suspect this hasn't been done for a genuine security reason, instead these two scenarios might explain it:
- This is simply an artefact of how the system was developed rather than something they'd necessarily reimplement if they were building the system again today.
- It has been suggested in previous answers that banks like to make their authentication processes unique and more complicated than typical online accounts. This is to make users feel that logging into their bank is more secure than logging into say Facebook.
It may have been done to separate the account identification from password verification steps, but if that is the case then I can only conclude that this was done for some reason other than security. If the positive account identification is indicated to the user then it would be creating an account enumeration vulnerability and making the system less secure rather than more.
Some authentication systems do have a "personal site seal" which you're suppose to identify before entering your password to prevent phishing, however these systems usually have some other form of authentication (for example your mothers maiden name) before displaying the seal to you - that prevents accounts from being enumerated and phishers from knowing the site seal without having to know some details about you. This is not considered very effective though.
A multi-factor approach is recommended by ISO 27k and OWASP. But if you only separating a user ID field and password field on separate pages, there are a few things to consider.
Such a login process has nothing to do with separating authentication from autorisation. There is only authentication in the form of a claim (the account name) and the proof (the password). For regular sites, autorisation is linked to identities, so autorisation is automatically implied by any user being able to prove his or her identity.
Such a login process is not what is meant by ISO or OWASP, because there is no multifactor process for proving the claim, no extra channel like a messaging service or fingerprint et cetera. In that sense it does not really improve security.
Such a login process has pro's and cons, depending on the expectation of the user. By first asking for the account name only, regular users can not accidentally mix up the account name with the password. But more experienced users who use long and truly random passwords that they can not remember themselves, will experience a real annoyance. Because those users use automatic login functionality from password managers like KeePass, and will find that it will not work when the fields are in separate pages. They have to login by hand, entering the account name and password separately with each login attempt.
There is an argument that such a login process could be technically more secure, because developers can take other measures to slow down brute force attacks. On the other hand, a hybrid way can be implemented by means of AJAX, so that automatic logons from password managers still work, CRSF-tokens can be used, and session IDs do not have to be given out before a user is fully authenticated. In other words, technical and UX arguments do not necessarily have to depend on each other.
It is important to remember that account names and passwords will be shared amongst users. It is common practice that a single user has multiple unique and/or non-unique accounts for the same system. The identification always identifies the account, rather than a live, unique individual. Security measures should be implemented while being aware of this fact of life.
Many common sites use a mail adress for the identity claim. But users can switch e-mail addresses as fast as pre-paid mobile phone numbers. And whenever users use multiple addresses, the argument that a user will always remember the mailadres will fade. For UX, it is an annoyance when you can not change the e-mail adress easily to a sane account name. A chosen account name will have a much smaller attack vector because it is less easily known and it can vary from one system or site to another. Therefore it will improve security of the user.