A password is one secret, and secrets leak. A second factor means that a
stolen password on its own doesn’t reach your research.
Setting it up
On your account page, choose Set up two-factor authentication.
Scan the code with any authenticator app: 1Password, Authy, Google
Authenticator, your password manager, or type the key by hand.
Then enter the code the app shows. Nothing is switched on until that code
matches. A scan that silently failed would otherwise lock you out of your
own account, which is the most common way people lose access to a system that
was trying to protect them.
Getting a new phone
Choose Replace my authenticator on your account page. We ask for your
password first, then show a fresh code to scan with the new app.
Your existing authenticator keeps working the whole time, and so do your
recovery codes. Nothing changes over until a code from the new app is
confirmed, so a scan that silently failed costs you nothing — you can walk
away and your old app still signs you in. Keep my current authenticator
abandons the replacement.
Your recovery codes are not reissued: they are independent of which app holds
the secret, and the ones you already have keep working.
Recovery codes
When two-factor authentication goes on, you get ten recovery codes. Each one
signs you in once, and they are shown exactly once. We store only their
digests, so nobody, including us, can read them back to you later. Keep them
somewhere you can reach without your phone.
Generating new codes invalidates the old set. Your account page says how many
you have left, and sign-in warns you when the last one is gone.
Signing in afterwards
Sign-in becomes two steps: password, then code. The password step alone
creates no session. It only unlocks the code prompt, which expires after five
minutes and gives you five attempts. A code works once: replaying one that has
already been used is refused, so a code read over your shoulder is worth
nothing.
A recovery code can be entered in the same box.
Staff cannot turn it off
Staff accounts reach the admin console, impersonation, courtesy subscriptions
and the warehouse. A password alone isn’t enough for that, so super users are
walked through enrolment before they can use the platform, and the turn off
button isn’t offered to them.
If a staff member loses both their device and their recovery codes, another
super user can clear the second factor from /admin/users, which returns the
account to enrolment rather than to open access.
Your organization can require it
An administrator of a department, team or university can require a second
factor of every member, from the organization’s settings. Members without
one are emailed once and get seven days, counted from the mandate or
from joining, whichever is later. A banner at the top of every page counts
the days down and links to the setup page; nothing is blocked until the
deadline. After it, the platform opens only the setup page, exactly as it
does for staff, and the turn off button is withheld for as long as the
mandate stands.
The organization’s members list shows where each member stands: enrolled,
the date their grace runs out, overdue, or not enrolled where there is no
mandate. Turning the mandate on or off is recorded in the organization’s
audit log.
Signing in through your institution’s identity provider does not change
this. The mandate is about your dfrds account, whichever way you reach it;
see Single sign-on.
Passwords
Twelve characters or more. Length is the one property of a password that
reliably resists guessing, so we ask for length and nothing else: no
required digit, no required symbol.
We also refuse a password that has appeared in a known data breach. The
check is done the way Have I Been Pwned recommends: five characters of a
hash of your password leave our server, a few hundred hashes come back, and
the comparison happens here. Neither your password nor its full hash goes
anywhere. If that service is down, the check is skipped rather than blocking
you from signing up or resetting a password.
Wrong passwords
Ten wrong passwords in a row lock the account for an hour. The ninth warns
you. When the account locks we email you a link that unlocks it at once, and
the sign-in page offers to resend it. If you didn’t try to sign in, someone
was guessing at your password and did not get in; choose a new one once you
are back.
Separately, the sign-in form refuses more than ten attempts a minute from
one address, and more than five a minute for one email address, with a
plain “Too many attempts” reply. Those refusals never count against your
account.
Confirming your email
A new account gets a confirmation link by email and can use the platform
straight away. The link keeps the account open past the first three days;
without it, sign-in stops on the fourth day until a fresh link is used
(Resend the confirmation link, on the sign-in page).
Membership waits for the link. An invitation to a university or team, and
the automatic membership a university grants to addresses on its
verified domain, take effect
when the address is confirmed, not when it is typed. If the organization has
no seat left at that moment, the confirmation page says so and its
administrators are emailed. Changing
the email on your account page works the same way: the old
address stays in use, and is told, until the new one confirms.
Signing in with Google skips all of this, because Google has already
verified the address.
Sessions
A session left idle for twelve hours ends, and you sign in again. Tick
Remember me to keep a session open across days on a machine that is yours.
The account page lists your last five sign-ins (when, how, and the
address they came from) under Signing in and sessions. Sign out
everywhere else ends every session but the one you are using: a browser
left open on a shared machine, a phone you no longer have. It is recorded in
the audit log as Signed out everywhere, and your API keys are not touched;
revoke those on the organization’s page.
What it doesn’t cover
Signing in with Google, or through your institution’s identity provider,
goes through that provider’s own verification and doesn’t ask for a dfrds
code as well, unless your organization requires one. API keys are separate
credentials with their own revocation: see the API docs.