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?

  • The only benefit I can think of is that it gives the user slightly longer to identify a phishing attack if the site is a fake duplicate. Closely related: Is SiteKey a valid defense against Phishing?
    – apsillers
    Apr 3, 2015 at 2:33
  • 1
    Are you sure there aren't additional features present during this process, such as a random image to help you authenticate the bank (a la SiteKey)?
    – D.W.
    Apr 3, 2015 at 16:56
  • 2
    This is basically the same as separately validating logins and passwords, which is sometimes considered bad.
    – Mints97
    Apr 3, 2015 at 19:39
  • @D.W. There are, but only after entering the name and password. Apr 3, 2015 at 19:59
  • @Mints97 I don't know if it they do that, they have me enter both and then check them, together as far as I can tell. Apr 3, 2015 at 20:00

4 Answers 4

  1. 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.
  2. 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" On Screen keyboardto 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.
  • 5
    "For example, my bank first asks 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." that would be an account enumeration vulnerability in itself as you'd be disclosing whether an account actually exists before authenticating. This could be valuable to a range of attacks including social engineering or say if you had some account numbers and you wanted to discover which bank they belonged to.
    – thexacre
    Apr 3, 2015 at 8:58
  • 4
    "It slows down the ability of automated password testing software to perform their tasks of trying out multiple passwords." also I question how significant a single extra HTTP request is. If this was genuinely their intention then surely they'd introduce an artificial delay via a slow hashing algorithm or even just a busy wait instead.
    – thexacre
    Apr 3, 2015 at 9:02
  • 1
    As I said, its not really any type of significant security mitigator. But the banking industry has decided it is one of many acceptable security features for banks to choose to implement. I'm just stating their rationale.
    – cybermike
    Apr 3, 2015 at 9:09
  • 1
    "asks me to confirm an image I picked in my profile from a set of images... Whether or not picking an image from a set of images really adds any authentication effectiveness is a separate issue" From a UX PoV, I found the image to be helpful. For better or worse, I tend to use similar usernames across systems. However, with different systems having different requirements and since I use multiple email accounts, sometimes I attempt the wrong email on a certain site. By displaying the picture, I know whether or not I used the correct email before logging an invalid attempt with a wrong password Apr 3, 2015 at 17:01
  • 2
    This answer is superficial look at this issue. It assumes that brute forcing is the major issue & focuses on the user and not the company/sever. A big reason why this is done is to prevent passwords from accidentally landing in the username field, which is logged, & is correlated in all sort of reports. If you get two failed login attempts in a short period of time from the same IP, chances are one one time the username is the username & next is the password. If you gain access to the logs, you can find such instances & get a user's password. security.stackexchange.com/a/32026/36538
    – Eric G
    Apr 3, 2015 at 17:33

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.

  • 2
    I always thought this was an attempt to prevent users from accidentally entering their passwords into the username field. Apr 3, 2015 at 12:33

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.


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.

  • 1
    I have seen this, and the usual "catch" is that they won't show this "safety image" unless the client is a previously-known one (i.e. saved cookie/IP address/etc.) and will instead insert another screen before showing it if it's not the case (i.e. what's your mother's maiden name) Apr 3, 2015 at 18:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .