#33635 closed defect (bug) (invalid)
$nonce_life is actually twice nonce life
Reported by: | ericlewis | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.5 |
Component: | Security | Keywords: | |
Focuses: | docs | Cc: |
Description
wp_nonce_tick() creates a deterministic string that changes when a nonce expires.
The value $nonce_life
is made available for filtering. The default says a nonce lasts a day. This is incorrect because of the division by two used in the return expression.
Here's some scratch math because yes I had to type this out
time() nonce_life return 0 86400 0 (Jan 1, 1970, 00:00:00) 1 86400 1 (Jan 1, 1970, 00:00:01) 43200 86400 1 (Jan 1, 1970, 12:00:00) 43201 86400 2 (Jan 1, 1970, 12:00:01) 86400 86400 2 (Jan 2, 1970, 00:00:00) 86401 86400 3 (Jan 2, 1970, 00:00:01)
Change History (3)
#1
@
9 years ago
- Component changed from General to Security
- Focuses docs added
- Keywords needs-patch needs-docs added
- Milestone changed from Awaiting Review to Future Release
- Version set to 2.5
#2
@
9 years ago
- Milestone Future Release deleted
- Resolution set to invalid
- Status changed from new to closed
Nevermind — just saw wp_verify_nonce()
back-validates nonces from 12-24 hours ago.
Although the math presented earlier does expose that corner cases here can occur with nonces, because of the time-window that wp_nonce_tick()
creates.
e.g.
It's 8/31/2015 20:12:02 UTC (1441051922 in Unix epoch), wp_nonce_tick() returns 33358
.
When it turns 9/1/2015 00:00:01 UTC (1441065601 in Unix epoch), wp_nonce_tick() returns 33359
. The nonce I made earlier is still valid.
When it turns 9/1/2015 12:00:01 UTC (1441108801 in Unix epoch), wp_nonce_tick() returns 33340
. The nonce I made earlier is invalid, even though it is only 14 hours old.
We should modify the documentation block for the
nonce_life
filter to describe this, and perhaps move the divide-by-two operation up to the$nonce_life
instantiation.