34

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 '15 at 2:33
  • 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 '15 at 16:56
  • This is basically the same as separately validating logins and passwords, which is sometimes considered bad. – Mints97 Apr 3 '15 at 19:39
  • @D.W. There are, but only after entering the name and password. – ThisIsNoZaku Apr 3 '15 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. – ThisIsNoZaku Apr 3 '15 at 20:00
26
  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.
  • 4
    "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 '15 at 8:58
  • 2
    "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 '15 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 '15 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 – David Jacobsen Apr 3 '15 at 17:01
  • 1
    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 '15 at 17:33
3

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. – Matthew Peters Apr 3 '15 at 12:33
2

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 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) – user2813274 Apr 3 '15 at 18:03
1

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.

0

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.