Page MenuHomePhabricator

Upgrade an old "weakDigest()" inside TOTP synchronization code
ClosedPublic

Authored by epriestley on Dec 13 2018, 8:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Apr 19, 8:10 PM
Unknown Object (File)
Fri, Apr 19, 5:50 PM
Unknown Object (File)
Thu, Apr 18, 1:54 AM
Unknown Object (File)
Sun, Apr 14, 1:39 PM
Unknown Object (File)
Tue, Apr 2, 11:32 AM
Unknown Object (File)
Sat, Mar 30, 7:10 AM
Unknown Object (File)
Thu, Mar 28, 9:37 AM
Unknown Object (File)
Mar 22 2024, 9:44 PM
Subscribers
None

Details

Summary

Ref T13222. Ref T12509. When you add a new MFA TOTP authenticator, we generate a temporary token to make sure you're actually adding the key we generated and not picking your own key.

That is, if we just put inputs in the form like key=123, response=456, users could pick their own keys by changing the value of key and then generating the correct response. That's probably fine, but maybe attackers could somehow force users to pick known keys in combination with other unknown vulnerabilities that might exist in the future. Instead, we generate a random key and keep track of it to make sure nothing funny is afoot.

As an additional barrier, we do the standard "store the digest, not the real key" sort of thing so you can't force a known value even if you can read the database (although this is mostly pointless since you can just read TOTP secrets directly if you can read the database). But it's pretty standard and doesn't hurt anything.

Update this from SHA1 to SHA256. This will break any TOTP factors which someone was in the middle of adding during a Phabricator upgrade, but that seems reasonable. They'll get a sensible failure mode.

Test Plan

Added a new TOTP factor.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable