The downloadable backup-codes file opens with the site's full URL. Something less machine-readable would identify the site just as well to the person who saved it, while being less directly useful to anyone who later finds the file.
Line references are against master at 6245be6.
Current behavior
providers/class-two-factor-backup-codes.php:358-362
$title = sprintf(
/* translators: %s: the site's domain */
__( 'Two-Factor Recovery Codes for %s', 'two-factor' ),
home_url( '/' )
);The generated file therefore begins:
Two-Factor Recovery Codes for https://example.com/
1. 12345678
2. 87654321
...
The translator comment says "the site's domain", but home_url( '/' ) emits scheme, host, and path — https://example.com/, or https://example.com/blog/ on a subdirectory install.
Why it might be worth changing
Labelling the file is right, and I am not suggesting removing it — unlabelled recovery codes are unusable at the moment they are needed, which is the failure this feature exists to prevent. The question is only how precisely the label needs to identify the site.
Backup codes are a second factor, so a found file grants nothing on its own; an attacker still needs the password. That genuinely limits the impact here. But a full URL is a copy-pasteable target rather than a human-readable label, and the file is likely to sit in a downloads folder, a synced drive, or a printout for a long time. The recognition value to the owner is the same either way.
Options
get_bloginfo( 'name' ) — the site title. Highest recognition value for a human ("Two-Factor Recovery Codes for Acme Intranet"), no address. Weakness: the default title is "My Blog"/site-name-at-install, and some sites leave it generic, so a user with codes for several WordPress sites could end up with ambiguous files.
wp_parse_url( home_url(), PHP_URL_HOST ) — host only, dropping scheme and path. Smallest possible change, keeps the file unambiguous, and actually matches what the existing translator comment already claims the value is. Probably the lowest-friction fix if the goal is just to stop over-specifying.
Both — sprintf( '%s (%s)', get_bloginfo( 'name' ), $host ). Most useful to the owner, but it is strictly more information than today for anyone who finds it, so it only makes sense if the concern above is judged unimportant.
A filter on the title — lets site owners decide, which suits environments with a specific policy. Worth adding regardless of which default is chosen, and cheap.
The download attribute on the link — an orthogonal improvement. data: URI downloads otherwise land with a browser-generated filename; setting download="recovery-codes-example-com.txt" puts the identification in the filename, where the owner sees it while browsing files, without it living inside the file contents.
My preference would be host-only plus a filter, since it matches the documented intent of the existing translator comment and is a one-line change. But the site name is a defensible alternative if recognition is weighted more heavily than target-minimisation, and reasonable people will land differently on how much any of this matters given codes are a second factor.
Context
Noticed while building an add-on that reuses this download construction verbatim for an enrollment screen, so whatever is decided here I would like to follow rather than diverge from.
The downloadable backup-codes file opens with the site's full URL. Something less machine-readable would identify the site just as well to the person who saved it, while being less directly useful to anyone who later finds the file.
Line references are against
masterat 6245be6.Current behavior
providers/class-two-factor-backup-codes.php:358-362The generated file therefore begins:
The translator comment says "the site's domain", but
home_url( '/' )emits scheme, host, and path —https://example.com/, orhttps://example.com/blog/on a subdirectory install.Why it might be worth changing
Labelling the file is right, and I am not suggesting removing it — unlabelled recovery codes are unusable at the moment they are needed, which is the failure this feature exists to prevent. The question is only how precisely the label needs to identify the site.
Backup codes are a second factor, so a found file grants nothing on its own; an attacker still needs the password. That genuinely limits the impact here. But a full URL is a copy-pasteable target rather than a human-readable label, and the file is likely to sit in a downloads folder, a synced drive, or a printout for a long time. The recognition value to the owner is the same either way.
Options
get_bloginfo( 'name' )— the site title. Highest recognition value for a human ("Two-Factor Recovery Codes for Acme Intranet"), no address. Weakness: the default title is "My Blog"/site-name-at-install, and some sites leave it generic, so a user with codes for several WordPress sites could end up with ambiguous files.wp_parse_url( home_url(), PHP_URL_HOST )— host only, dropping scheme and path. Smallest possible change, keeps the file unambiguous, and actually matches what the existing translator comment already claims the value is. Probably the lowest-friction fix if the goal is just to stop over-specifying.Both —
sprintf( '%s (%s)', get_bloginfo( 'name' ), $host ). Most useful to the owner, but it is strictly more information than today for anyone who finds it, so it only makes sense if the concern above is judged unimportant.A filter on the title — lets site owners decide, which suits environments with a specific policy. Worth adding regardless of which default is chosen, and cheap.
The
downloadattribute on the link — an orthogonal improvement.data:URI downloads otherwise land with a browser-generated filename; settingdownload="recovery-codes-example-com.txt"puts the identification in the filename, where the owner sees it while browsing files, without it living inside the file contents.My preference would be host-only plus a filter, since it matches the documented intent of the existing translator comment and is a one-line change. But the site name is a defensible alternative if recognition is weighted more heavily than target-minimisation, and reasonable people will land differently on how much any of this matters given codes are a second factor.
Context
Noticed while building an add-on that reuses this download construction verbatim for an enrollment screen, so whatever is decided here I would like to follow rather than diverge from.