20

The JP Morgan Chase homepage has a 5 second delay before login form appears. If you refresh the delay is always there. If you fail to input a proper password, the failed login page has no such delay when the page is loaded, regardless of how many refresh requests.

Is the homepage implementing some sort of security measure?

  • 37
    Could just be terrible coding practices. – Mark Buffalo Sep 25 '16 at 6:21
  • 9
    It's just banking-grade UX. It's actually not that bad, at least you can use a password manager on their form, unlike others that have an on-screen keyboard or ask for only parts of the password. – André Borie Sep 25 '16 at 7:37
  • 2
    @Tim No. If the machine is compromised to the point where the keyboard is not safe, an on-screen version won't be any safer. The best solution would be 2-FA which sadly I have yet to see on any bank I've been at. – André Borie Sep 25 '16 at 16:19
  • 4
    @user1800340 I disagree. Disabling 2FA just because idiots don't know how to use it is a bad idea (and the solution is time-limited, as idiots will eventually learn how to use it as more services adopt it, like Google, Facebook, etc). Not to mention, 2FA using TOTP requires zero infrastructure (no SMS, etc) so there's really no good reason not to offer it. – André Borie Sep 25 '16 at 16:49
  • 2
    @user1800340 I still do not see any clear reason in the linked article why they eliminated 2FA. Not making it mandatory is indeed understandable, as some people may not know how to use it. However why not offer it as an option? Also, the article seems to imply that fraud detection algorithms and 2FA are mutually exclusive. Why not have both? – André Borie Sep 25 '16 at 17:09
43

Is the homepage implementing some sort of security measure?

If you are referring to https://www.chase.com, then nope, it's just slow to load and do the transition thing. Terrible UX maybe, but this is not a security feature. A login cracking bot would not typically use the user interface anyway.

Basically, it's a banking website, and terrible UX is sadly the norm.


While this particular case may not be security related, it's not uncommon to have rate-limiting between login requests. This would have to be implemented in the back-end code to effect all requests to be effective.

  • 13
    It should also be noted that this page appears to implement no delay between login attempts, only before the first attempt. This adds no security benefit. This is not a security feature. – Micheal Johnson Sep 25 '16 at 8:35
  • 4
    My bank's UX is pretty good, at least as far as the design and load times go. – John Dvorak Sep 25 '16 at 14:42
  • OT, but they have won multiple awards for their UX/UI so I'm skeptical when I hear it's terrible. But at least it's settled that this isn't a security featured. – Info5ek Sep 25 '16 at 16:12
  • 1
    @JanDvorak mind sharing which bank it is? – André Borie Sep 25 '16 at 16:26
  • 3
    @user1800340 I doubt most awards focus specifically on authentication. It's possible to have a decent menu system and still have an enragingly stupid login process. In the case of Chase however, I suspect it's more about priorities. Gotta get that low introductory API offer on screen ASAP, login, shmogin. – barbecue Sep 25 '16 at 16:48
6

One possible scenario where this delay could be because of a security measure is if the site is using something like a Client Puzzle Protocol (CPP). This does not appear to the case with https://www.chase.com/, but CPPs can be used prevent denial of service attacks against slow hashing functions. It is basically an implementation of Proof-of-Work system. More details here.

The basic idea is to force the client to do a significant amount of work, and prove it has done so, before you will accept a username/password pair and try to validate it. Basic overview of the approach from the linked post:

The server generates a random puzzle, and sends the puzzle to the client. The server generates the puzzle in a way that it can predict reasonably well how much effort will be required to solve the puzzle (e.g., 100ms of computation). The client solves the puzzle, and then sends the solution along with the user's username and password.

In a web setting, this would probably be implemented with Javascript: the login page would contain the Javascript code to solve the puzzle and the puzzle description. A legitimate user's web browser would run the Javascript on the page, which would solve the puzzle and include the solution in the form along with the username and password.

Based on how this is implemented, a site could delay loading of the login page until the client (your browser) solves the puzzle. Again a bad UI design -- I'd just disable the login button until the puzzle is solved and enable the button for login form submission once the client has a solution.

  • 1
    +1 to "CPPs can be used prevent denial of service attacks against slow hashing functions" – Bryan Field Sep 26 '16 at 13:39
1

Looking at the source code using Chrome:

view-source:https://www.chase.com/

the

<form name="homeLogonForm" class="container-fluid chase-home-login" action="https://mfasa.chase.com/auth/alogin.jsp" method="post" autocomplete="off">

element is present when the page loads so it's definitely not "hidden" from simple bots via JavaScript but rather appears to be a UX decision to delay it's presence.

Without asking Chase Bank I can only provide conjecture that this was done for usability reasons discovered during their testing phase.

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.