[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