1) In the beginning there was the password…
… and of course it was created by humans—so it was often simply “1234”, “<first name><birth year>”, or “password”.
“password”: A password as secure, useful, and brave as an umbrella in a hurricane — but hey, it worked for logging in. You logged in, everything was fine, and back then life didn’t yet have password policies—and luckily, at the start there also weren’t worldwide automated attacks via the internet.
Then password security policies were introduced step by step—but let’s be honest: humanity is lazy and most people’s memory isn’t that great. So “password” turned into:
- At least 1 uppercase letter:
Password - At least 1 numeric character:
Password1 - At least 15 characters:
Password1234567 - At least 1 special character:
Password1234567!
What an evolution. Ah, humans are as simple as they are brilliantly constructed.
One of the newer developments is the passphrase, which actually helps. The idea is to combine several words that are easy to remember but have nothing to do with each other, and to remember them using a mnemonic sentence.
Forest!CoffeePowerOn_2001LOR
(I walk through the forest in the morning carefully, then drink a coffee before I start the PC — oh, and in 2001 the first Lord of the Rings movie was released.)
So passwords finally improved. Unfortunately, attackers did too.
And then came: MFA (Multi-Factor Authentication). Finally, a second factor that has nothing to do with the password itself.
2) MFA with TAN lists: brilliant back then — problematic today
The early classic was TAN lists (on paper, offline, simple, and somehow charming).
Back then the advantage was: even if someone knew your password, they still needed a one-time TAN from your list—and after use it was no longer valid.
Why are TAN lists often considered insecure today?
- Copyable: a photo, a scan, once seen and saved — and the “second-factor magic” is gone.
- Reusable attack surface: a list is a stockpile. If it’s compromised, it’s over.
- Phishing-prone: a TAN can be requested in real time and abused immediately if a victim enters it on a fake site.
In short: TAN lists are an outdated form of two-factor authentication—historically important, but no longer a modern shield.
3) Modern MFA: Push vs. TOTP
Today we mainly encounter two variants:
A) Push notifications (Approve/Deny)
You log in → your phone receives a push request → you tap “Approve”, or you may have to manually enter a displayed code.
Pros:
- Very convenient
- Fast
- User-friendly
Cons:
- Vulnerable to MFA fatigue (being spammed with prompts to “force” an approve just to make it stop…)
- Usually requires network/push infrastructure
B) TOTP (Time-based One-Time Password)
You want to log in, enter your password, and then you’re asked for the current OTP. You check your authenticator app/token; it shows a code that changes every ~30/60 seconds → you type it in.
Pros:
- Works without cellular service and without internet
- Very common and standardized
Cons:
- You have to type (yes, actual hard physical work)
- It only works if both sides use exactly the same time base. That means time must be synchronized between OTP generator and the service—ideally to the second, and configured with the same daylight saving settings and time zone.
4) TOTP doesn’t need the internet? How does that work then?
Usually it doesn’t need it. The magic happens locally using time. Just like in Alice in Wonderland, time plays a very important role here—and you have to be quick, because every 30–60 seconds a new valid code is generated.
- During setup, the server/application and your authenticator share a common secret (secret)
- This secret is often contained in a QR code or a long string that you scan or type in.
- After that, your device continually calculates a new code from:
this secret + the current time (in time slices, e.g., 60 seconds)
5) TOTP on multiple devices: is that possible?
Yes—technically that’s possible, because if two devices have the same secret, both generate the same codes at the same time.
Typical variants:
- TOTP on smartphone + second device (e.g., tablet)
- TOTP additionally as a hardware token
Important: the more copies of the secret exist, the greater the responsibility to keep those devices properly protected.
The standard behind this magic is RFC 6238 (TOTP).
Source: IETF RFC 6238
https://datatracker.ietf.org/doc/html/rfc6238
6) TOTP without a phone: what if a smartphone isn’t an option?
There are data centers and environments so regulated that they completely forbid mobile phones (among other things because of the integrated camera and the internet).
But if you still need to use 2FA in such environments, there are two very common options—for those environments and for any other.
Option 1: Hardware-Token
A small device that displays TOTP codes—available with and without cameras and of course without internet. Proven devices include models from Reiner, which offers different models for this:
e.g. Reiner SCT Authenticator mini
Up to 60 TOTP accounts without internet and can be protected with an additional PIN (don’t choose 1234)
For all operating systems and devices incl. USB‑C and battery
Touch display and camera (for QR code scanning)
Price approx. €115
Pros:
- No smartphone required
- Often robust, offline
Cons:
- Must be managed (loss, replacement, storage)
Option 2: Software TOTP outside the phone
Examples include password managers or vault solutions that can store and generate TOTP (e.g., locally like KeePass with TOTP support, or business solutions with team features).
Interesting for teams: some solutions offer
- RBAC (Role-Based Access Control)
- HTML plugins for login
- shared vaults
- controlled sharing of TOTP secrets
Security note: If password and TOTP are in the same vault, that’s extremely convenient—but you should consciously decide whether that matches your risk model.
7) Is MFA annoying?
Yes. A bit. Let’s be honest: security is almost never “more convenient.” It’s always easier to walk through an open door than to get a key and unlock it. Still, we’ve gotten used to it—and we also don’t want someone accessing/crossing into an area without our knowledge.
MFA is basically exactly that extra key.
And in a world where passwords get leaked, guessed, or phished, a second factor is often the difference between:
- “Someone has my password… and causes major damage”
vs - “Someone has my password… and still fails”
8) Enable MFA in Veeam Backup & Replication (VBR)
Veeam Backup & Replication supports multi-factor authentication for the console, Web GUI, and API. The official documentation describes the workflow and options.
Source: Veeam Help Center (VBR User Guide – MFA)
https://helpcenter.veeam.com/docs/vbr/userguide/mfa.html
- Open the security/user and role settings in VBR
- Enable MFA (according to the documentation)
- Users set up MFA (often via QR code / TOTP)
9) Which Veeam services should not have MFA?
Despite all security, you must distinguish between two types of user accounts:
- Interactive users (humans): MFA makes great sense here and should be enabled.
- Non-interactive accounts/services: MFA must be disabled here, because an automated process/service or script cannot automatically “approve” 2FA.
In principle, you should also always have an emergency account (“break glass”). Because you might lose your 2FA device or the service you use might be unavailable.
That emergency account should be very strongly protected—ideally with a hardware token stored in a safe, extremely restrictive monitoring, and used only for real emergencies.
For services/components such as monitoring/automation you should instead rely on other security best practices (even if MFA is disabled):
- proper least-privilege permissions
- strong secrets/key management (not
Password123!) - domain and network segmentation
- logging/alerting
- if applicable, certificate/token-based authentication
With Veeam you need service accounts without MFA, e.g. for
Veeam ONE ↔ VBR
Veeam Enterprise Manager ↔ VBR
or PowerShell scripts.
10) Nice side fact — do you know when and by whom the QR code was invented?
The QR code was developed in 1994 at DENSO WAVE (Japan), strongly associated with Masahiro Hara and his team. They developed it for logistics in automotive manufacturing for the Toyota group. The goal was fast, robust scanning; more data than a barcode; easier recognition; and tolerance against damage.
And today this great invention enables easy scanning everywhere using mobile phones and helps, for example, with secret exchange during MFA setup.
