WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#25810 closed enhancement (invalid)

Add nonce to wp-login.php

Reported by: strangerstudios Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Security Keywords:
Focuses: Cc:

Description

Shouldn't we have a nonce on the login page to help against automated login attempts?

Here is a plugin that adds a nonce to the login page and also lowers the lifetime of the login nonces to 30 seconds (vs 12-24 hours).

https://github.com/elyobo/wp-login-nonce

We might be able to pull from the plugin code and/or the idea to limit the nonce length on login. (I haven't personally used the plugin before. The code is straight forward enough.)

Change History (6)

#1 @alexvorn2
6 years ago

I don't this will help ( a lot ) against automated log in.
As I imagine a automated log in is made with a script created with a browser module that simulates a regular browser ex: IE 8 or Firefox 17, so nonce will show up in the source and will not affect the automated log in.

Does google or facebook use such type of security like nonce on their log in page?

#2 @bpetty
6 years ago

  • Keywords dev-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Nonce values are designed to protect against CSRF and replay attacks, and they rely heavily on an authenticated user to provide unique nonce values (not just based on time).

They are not designed to protect against (unauthenticated) brute force requests. Even given your shortened 30 minutes, bots would simply make another request for a valid nonce to continue brute force attacks for the next 30 minutes (assuming the first 30 wasn't enough already).

#3 @adamsilverstein
6 years ago

This might just cause the bots to load each page before submitting to get the correct nonce, potentially increasing server load.

It would stop the current strain of brute force attacks where bots hit the login page repeatedly trying common logins. If the bots had to have a valid nonce, they would have to load the login page before submitting their login attempt, potentially slowing down the process and also potentially increasing load on the server.

#4 @adamsilverstein
6 years ago

  • Cc adamsilverstein@… added

#5 @strangerstudios
6 years ago

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

#6 @elyobo
6 years ago

Thanks for suggesting including it in the core :) I'm fine with it or without it, but we have found it useful against automated attacks for two reasons.

By requiring the attacker to request the page beforehand, you are rate limiting the number of authentication attempts that they can make; it doesn't prevent it, it just slows it down significantly. Complaining that it increases system load is sort of missing the point; the attacker can already generate just as much load using only POSTs to log in, whereas with this they will need to execute GETs as well. I don't think the load profile will really change, although it might get a little lighter if they have to do more GETs (which don't involve an lookup to check if the login is correct) and if we can reject attempts with missing nonces (again, no lookups).

It also requires a slightly smarter attack; the dumb attacks that we were experiencing across our networks was not doing a GET first, so while it didn't prevent the system from being loaded by the attack, it did guarantee that the attacker would not gain access even if they hit upon the correct password. So there is in fact a security advantage against stupid attacks :)

Complaints about the uniqueness of the nonce should be directed to Wordpress :) Because Wordpress doesn't actually have nonces (they can all be reused, so they're not a nonce) the system is less than ideal, but you can adjust the timeout to reduce the replayability (we use a very similar plugin with a timeout of 15 seconds or so; @bpetty, the timeout here is 30 seconds, not minutes). This is discussed in the README.md for the plugin. I would happily use a real nonce here, but didn't want to add the DB storage overhead or force users to enable sessions or some other caching mechanism.

@strangerstudios, the key takeway should probably be that you need to think before putting a nonce on a front end form; in many situations they do actually make sense, but they are not a silver bullet, they only mitigate certain problems and they do make whole page caching more difficult.

Note: See TracTickets for help on using tickets.