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

WordPress Trac noreply at wordpress.org
Thu May 7 10:11:50 UTC 2015


#31772: Browser unresponsive with long password
-------------------------------------+-------------------------------------
 Reporter:  BevanR                   |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Users                    |     Version:  3.7
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-unit-    |     Focuses:  javascript,
  tests                              |  performance
-------------------------------------+-------------------------------------

Comment (by mattheweppelsheimer):

 > WP fails silently when a new password is greater than its threshold of
 about 1 or 2 thousand characters

 Oh, I wasn't aware of that. Good to know. The DDoS vector mitigation
 reason makes sense. That silent failure might concern me for reasons
 below… but that's a separate issue that I'll think on.

 > Why and how do you create such long passwords?

 How: I generate them automatically with a KeePassX client — a dynamic
 generator and encrypted personal password store similar to 1Password or
 LastPass, but GPL. https://www.keepassx.org/

 Why: It's a measure to virtually eliminate the chance of brute forcing or
 a rainbow table match.

 I should say that I am not a security expert, so it's possible there is a
 flaw in what I've synthesized from reading about how these things work,
 but here's how I think about it:

 200 characters is arbitrary, and probably ridiculous in that it's far
 beyond what is imaginably necessary — but that's kind of the the point.
 When using a system like KeePassX, the process of generating and using
 passwords is identical regardless of the password length. Given that, and
 considering how the time required to brute force crack hashes increases
 exponentially with each additional bit added to a password's length, from
 a user perspective you may as well use the longest possible password that
 the application will allow.

 I doubt this practice is currently a very widespread, but ideally the only
 barriers to growing adopt are education — not technical UI limitations
 like our slow password strength checking script.

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


More information about the wp-trac mailing list