Verify it's you: confirming who you are before a sensitive action #

This guide explains "Verify it's you" in Exponential 6.0.15. Before a sensitive action, such as changing a password, adding a passkey, assigning a role, clearing caches, exporting data or emptying the trash, a signed-in user confirms who they are again: with their password and one of their passkeys, or, without a passkey, their password and the code of their authenticator app. A confirmation then counts for ten minutes. A session someone else took over (a computer left unlocked, a stolen cookie) can then still read pages, but cannot take over the account or the site.

Guides · Related: Passkeys · Two-step sign-in · Security and audit · Change note: Passkeys and "Verify it's you"

In short #

• Six groups of actions; five are on by default: your own account, users, roles and policies, system settings and setup actions, exporting data, deleting data. The sixth, removing, publishing and saving content, is off and is switched on under Setup > Verify it's you (/setup/reauth), for every siteaccess or one, and for every user or the members of some user groups.
• The ways to confirm follow [ReauthSettings] Factors[]: by default the password and a passkey; without a passkey the password and the app's code; without either the password alone; an account without a password uses a passkey. A way of the same strength is offered beside the first one, never a weaker one.
• The page appears instead of the action. After a right answer the action runs exactly as it was sent; the next ten minutes ([ReauthSettings] Minutes) ask nothing. A sign-in that asked for as much counts as a confirmation.
• Five wrong answers in a row sign the user out.
• Only the web pages ask (index.php and Velocity). The REST interface, SOAP, WebDAV, the expservices login and the command line never ask, and anonymous visitors are never asked.
• Every question, answer and refusal is in the audit: access.session.reauth.ask, access.session.reauth, access.session.reauth.failed.

Contents #

1. The page
2. The ways to confirm
3. The groups and their rules
4. Setup > Verify it's you
5. Rule syntax
6. For extensions
7. What happens to the request
8. Where it is never asked
9. Audit
10. Every setting

1. The page #

The page says what the action is about ("You are about to manage users, roles or policies.") and shows one card per way of confirming offered to the account, the first the one to use:

• Your password and a passkey: type the password and choose Continue with a passkey; the browser then asks for one of your passkeys (fingerprint, face, screen lock or security key).
• Or: Your password and a code from your authenticator app: offered beside it when the account also has an authenticator app, for a browser that cannot use passkeys.
• With your password: an account with neither a passkey nor an app.
• With a passkey: an account without a password.

Cancel goes back to the page you came from without doing the action. A wrong answer says so and how many tries are left. On a browser without passkeys the passkey card's button is disabled and says to use another way.

2. The ways to confirm #

[ReauthSettings] Factors[] lists combinations of password, passkey and code (the authenticator app, see CodeHandlers[]), strongest first:

[ReauthSettings]
Factors[]
Factors[]=password+passkey
Factors[]=password+code
Factors[]=password
Factors[]=passkey

The first combination whose every way the account has is asked; the later ones with as many ways are offered beside it. So an account with a password, a passkey and an app gets "password and passkey" with "password and code" beside it, never "password" alone: a stolen password cannot choose its way around the second step. The password and the code are checked before the passkey. Accounts with e-mail codes of two-step sign-in have no code: they use the password and a passkey, or the password.

A sign-in counts. A web sign-in that asked for one of the combinations the account would be offered counts as a confirmation: the password of an account that has nothing more, the password and the app's code of two-step sign-in, the password and a passkey as the second step, a passkey of an account without a password. The password alone of an account that has a passkey counts for nothing.

3. The groups and their rules #

As shipped in settings/site.ini:

So changing one's own e-mail address asks (it changes credentials), editing one's own name does not; editing another user's account always asks. Signing out one other device of one's own does not wait for a question (someone who sees a strange device acts at once); signing out all of them does. Clearing the session list is setup/session (system); the audit log has no page that clears it.

Approve and Deny of a new user account waiting for approval (an item of the workflow event Approve user accounts, see Approving new editor accounts) ask too: the item addresses that account, so the rule collaboration/action other ... of the users group matches. An ordinary content approval addresses no account and never asks here.

The content group asks when the edit form is sent with Publish, Store draft or Store and exit, or when a removal is confirmed, before the page goes on to the content: a hijacked session or a script cannot publish or delete. The freshness window applies, so an editor confirms once and then saves for ten minutes without being asked.

4. Setup > Verify it's you #

Setup > Verify it's you (/setup/reauth, policy setup/setup) has the switch of the whole feature, the minutes a confirmation counts, a switch per group and, for the content group, the user groups it asks (none ticked: every user). Settings for chooses where the values apply:

• Every siteaccess: written to the global override settings/override/site.ini.append.php.
• Siteaccess <name> (/setup/reauth/<name>): written to settings/siteaccess/<name>/site.ini.append.php, for example to ask on the editors' siteaccess only. A value in settings/override wins over it.

Values are written line by line (the rest of the file stays as it is, a backup goes to var/backup/ini), and the change is recorded as system.setting.write. Saving is itself a system setting, so it asks first. The rules themselves are not edited on the page; they are settings of site.ini, changed by whoever deploys the site.

5. Rule syntax #

A rule is module/view [token ...]:

A group may also name UserGroups[] (content object ids of user groups): it then asks only their members. user/login and user/logout never ask, whatever a rule says.

6. For extensions #

A rule. Add the group's rules again in an INI file of the extension or the siteaccess, for example in extension/myext/settings/site.ini.append.php:

[ReauthGroup_system]
Rules[]=myext/dangerous
Rules[]=myext/download *

or a group of its own, which appears on setup/reauth with its name:

[ReauthSettings]
Groups[]=myext

[ReauthGroup_myext]
Enabled=true
Rules[]=myext/delete DeleteButton

A trigger handler decides where a rule cannot, from the extension's own data. A class implementing expReauthTriggerHandler, listed in [ReauthSettings] TriggerHandlers[], gets reauthGroup( $module, $view, $method, $post, $params, $user ) for every request the rules did not match and names a group, or null. It asks only while that group is on and applies to the user.

From a view. expReauth::requireFresh( $Params['Module'], 'myview', 'system' ) returns null when the user confirmed within the window, else the module result to return instead (the page, which posts the request again after the answer):

if ( ( $result = expReauth::requireFresh( $Params['Module'], 'wipe', 'delete' ) ) !== null )
    return $result;

Codes. [ReauthSettings] CodeHandlers[] names the classes that check codes (expReauthCodeHandler). The shipped expReauthTotpCode reads the authenticator app of sevenx_authentication_2fa when that extension is active: a code counts once per time step, and wrong codes count towards the extension's lock.

Clear the INI cache after changing settings.

7. What happens to the request #

• A POST is not run. The page posts back to the same address with every field of the original request as hidden fields; after a right answer the view runs with exactly those fields.
• A GET (a * rule) is asked again after the answer: the browser is redirected to the same address.
• A file upload cannot be sent twice by a browser: after the answer the form opens again and the files are chosen once more. Only a file actually chosen counts: a form that merely has file inputs, left empty, is a POST like any other.
• A script (XMLHttpRequest, or Accept: application/json without HTML) gets 403 with {"error": "reauth_required", "url": "..."} instead of the page.

The page is never stored by a browser or a shared cache.

8. Where it is never asked #

The check runs in ezpKernelWeb, after the policies allowed the view and before it runs, so only the web pages ask. The REST interface, SOAP, WebDAV, the expservices login and console commands have no such step. Anonymous visitors are never asked.

9. Audit #

A passkey used here is also recorded as access.passkey.use with the purpose reauth. The password re-entry of the audit console counts a confirmation made here.

10. Every setting #

site.ini [ReauthSettings]: