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?

Improve this question
14
  • 37
    Could just be terrible coding practices.
    – Mark Buffalo
    Commented Sep 25, 2016 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
    Commented Sep 25, 2016 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
    Commented Sep 25, 2016 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
    Commented Sep 25, 2016 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
    Commented Sep 25, 2016 at 17:09

3 Answers 3

Reset to default
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.

Improve this answer
6
  • 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.
    – micheal65536
    Commented Sep 25, 2016 at 8:35
  • 4
    My bank's UX is pretty good, at least as far as the design and load times go.
    – John Dvorak
    Commented Sep 25, 2016 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
    Commented Sep 25, 2016 at 16:12
  • 1
    @JanDvorak mind sharing which bank it is?
    – André Borie
    Commented Sep 25, 2016 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
    Commented Sep 25, 2016 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.

Improve this answer
1
  • 1
    +1 to "CPPs can be used prevent denial of service attacks against slow hashing functions"
    – 700 Software
    Commented Sep 26, 2016 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.

Improve this answer

You must log in to answer this question.

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