[wp-trac] [WordPress Trac] #31772: Browser unresponsive with long password

[WordPress Trac]

#31772: Browser unresponsive with long password
--------------------------+--------------------------------------
 Reporter:  BevanR        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Users         |     Version:  4.1.1
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  javascript, performance
--------------------------+--------------------------------------
Changes (by SergeyBiryukov):

 * focuses:  ui, javascript, performance => javascript, performance


Old description:

> == Steps to reproduce
>
> 1. Login
> 1. Navigate to profile
> 1. Click in the text input for "New Password"
> 1. Paste in a long password
>   * E.g. 600 characters:
> `123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890`
> 1. Press the "tab" key
>   - **Expected behaviour**:
>     - The cursor moves to the "Repeat New Password" field.
>     - "Strength indicator" changes to "Strong" or "Weak" (probably should
> be "weak").
>   - **Actual behaviour**:
>     - The cursor does not move.
>     - The cursor stops blinking.
>     - "Strength indicator" does not change.
>     - The browser is not responsive.
>     - After several seconds or a minute, the cursor eventually starts
> blinking, moves to the "Repeat New Password" field and the strength
> indicator changes to "Strong" (probably should be "weak").
> 1. Press the "shift+tab" keys
>   - **Expected behaviour**: The focus moves to the "New Password" field
> and its content is selected.
>   - **Actual behaviour**:
>     - The cursor does not move.
>     - The cursor stops blinking.
>     - The browser is not responsive.
>     - After several seconds or a minute, the focus eventually moves to
> the "New Password" field and the content is selected.
> 1. Press the delete/backspace key
>   - As expected, the password is deleted and the browser is immediately
> responsive.
>
> My testing was as an administrator using Chrome on Mac OS X.  I think
> this issue applies to any role and any browser on any OS.  I expect the
> delay is longer with slower hardware.
>
> == Solutions ==
>
> Certainly the strength checker need not run on `focus` events.  It should
> only be necessary on `change`.
>
> It could also run after a short timeout (~500 ms) if no other `change`
> event has occured, so that it only runs when the user stops typing.
>
> An elaborate solution might be to make the password strength checking
> code more efficient.  Or only run it on the first N characters.
>
> Or alternatively, seek a third party library that checks password
> strengths more performantly.
>
> A simple solution could be to set the `maxlength=""` attribute on
> password `<input>`s.  Rough testing on Chrome on an 18-month old MacBook
> Air suggests The limit would probably need to be less than about 64-256
> in order to keep the browser responsive (without modifying the
> unperformant code).
>
> The disadvantage of this approach is that long passwords can not be input
> by the keyboard, or will be truncated if pasted in.  This might be an
> issue for users that use password managing software like OnePassword.  We
> would need to investigate how long the passwords generated by such
> software is.
>
> For reference and comparison;
> - The server-side limit is currently 4096:
> https://github.com/WordPress/WordPress/blob/master/wp-includes/class-
> phpass.php#L217
> - If a password is set that is longer than 4096 characters, WP silently
> fails to save the password.

New description:

 == Steps to reproduce

 1. Login
 1. Navigate to profile
 1. Click in the text input for "New Password"
 1. Paste in a long password
   * E.g. 600 characters:
 {{{
 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
 }}}
 1. Press the "tab" key
   - **Expected behaviour**:
     - The cursor moves to the "Repeat New Password" field.
     - "Strength indicator" changes to "Strong" or "Weak" (probably should
 be "weak").
   - **Actual behaviour**:
     - The cursor does not move.
     - The cursor stops blinking.
     - "Strength indicator" does not change.
     - The browser is not responsive.
     - After several seconds or a minute, the cursor eventually starts
 blinking, moves to the "Repeat New Password" field and the strength
 indicator changes to "Strong" (probably should be "weak").
 1. Press the "shift+tab" keys
   - **Expected behaviour**: The focus moves to the "New Password" field
 and its content is selected.
   - **Actual behaviour**:
     - The cursor does not move.
     - The cursor stops blinking.
     - The browser is not responsive.
     - After several seconds or a minute, the focus eventually moves to the
 "New Password" field and the content is selected.
 1. Press the delete/backspace key
   - As expected, the password is deleted and the browser is immediately
 responsive.

 My testing was as an administrator using Chrome on Mac OS X.  I think this
 issue applies to any role and any browser on any OS.  I expect the delay
 is longer with slower hardware.

 == Solutions ==

 Certainly the strength checker need not run on `focus` events.  It should
 only be necessary on `change`.

 It could also run after a short timeout (~500 ms) if no other `change`
 event has occured, so that it only runs when the user stops typing.

 An elaborate solution might be to make the password strength checking code
 more efficient.  Or only run it on the first N characters.

 Or alternatively, seek a third party library that checks password
 strengths more performantly.

 A simple solution could be to set the `maxlength=""` attribute on password
 `<input>`s.  Rough testing on Chrome on an 18-month old MacBook Air
 suggests The limit would probably need to be less than about 64-256 in
 order to keep the browser responsive (without modifying the unperformant
 code).

 The disadvantage of this approach is that long passwords can not be input
 by the keyboard, or will be truncated if pasted in.  This might be an
 issue for users that use password managing software like OnePassword.  We
 would need to investigate how long the passwords generated by such
 software is.

 For reference and comparison;
 - The server-side limit is currently 4096:
 https://github.com/WordPress/WordPress/blob/master/wp-includes/class-
 phpass.php#L217
 - If a password is set that is longer than 4096 characters, WP silently
 fails to save the password.

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31772#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform