[wp-trac] [WordPress Trac] #25810: Add nonce to wp-login.php

WordPress Trac noreply at wordpress.org
Mon Nov 4 19:06:23 UTC 2013


#25810: Add nonce to wp-login.php
-----------------------------+----------------------
 Reporter:  strangerstudios  |       Owner:
     Type:  enhancement      |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Security         |     Version:
 Severity:  normal           |  Resolution:  invalid
 Keywords:                   |
-----------------------------+----------------------

Comment (by strangerstudios):

 When I posted this, I was mostly curious as to why there was no nonce on
 the login form since it's a best practice to add nonces to your forms.
 Turns out, the best practice is really to add nonces (of the WP variety)
 to _authenticated_ links and forms, but not public facing forms.

 I see we're closed, so I'll just post one more counterpoint here as devils
 advocate.

 FWIW, both Google (GALX hidden input) and Facebook (lsd hidden input) seem
 to have a kind of nonce on their login pages.

 Having a nonce on the login form would prevent a certain kind of attack.
 The current set of brute force login scripts (at least the ones I looked
 at) are hitting the login page over POST, not simulating form input. They
 would have to switch to simulating the browser or -more likely as pointed
 out here- preload the login page to get the nonce before trying a login
 (that's how the Google and Facebook brute force login scripts I saw work).
 They could also run against the XML-RPC API since that's on by default
 now.

 We have a chance to basically shut down the current gen of brute force
 logins with relatively little effort (although any change takes time). Why
 not add a nonce unless the downsides are bad. What are the downsides?

 (1) May break some caching of login pages.
 (2) May put more load on server when brute force attacks are preloading
 pages. (I'm not so sure of this.)
 (3) Would break valid forms to log into a WP instance across domains. (The
 WP management tools perhaps?)

 Those might be good enough reasons to avoid the login form nonce besides
 the effort required or the fact that this doesn't stop attacks that get
 smarter or hit the XML-RPC API anyway.

 The key take away for me from this discussion (thanks guys) is this:

 Nonces on public (non-authenticated) forms don't make sense since
 attackers will have access to the public form to get the nonce anyway. On
 the other hand, when logged-in, an attacker can't gain access to one of my
 user-specific nonces (unless they've compromised my computer or browser).
 Nonces that are really one-time in use, are still useful to keep users
 from accidentally submitting a form more than once, but don't really
 provide that much added security.

 TL;DR: It's security through obscurity.

 For posterity, some other resources on the subject:
 http://markjaquith.wordpress.com/2006/06/02/wordpress-203-nonces/
 http://kovshenin.com/2012/nonces-on-the-front-end-is-a-bad-idea/
 http://en.wikipedia.org/wiki/Cryptographic_nonce

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25810#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list