Multi-Factor Authentication Explained

What multi-factor authentication actually is

Multi-factor authentication (MFA) means you need more than one type of proof to log in. The common categories:

Something you know: a password or PIN.
Something you have: a phone, hardware token, or security key.
Something you are: biometrics like fingerprint or face.

Adding a second factor does not fix bad passwords, but it raises the cost for attackers:

Password dumps and credential stuffing are less effective.
Phishing campaigns need to capture both password and one-time code.
Automated attacks at scale become more expensive and noisy.

For systems that hold encryption keys or personal data, MFA is one of the simplest and highest impact defensive moves you can make.

How TOTP-based MFA works under the hood

The most common MFA mechanism today is a time-based one-time password (TOTP):

During setup, client and server agree on a shared secret.
Both sides run the same algorithm:
Take the current time slice (for example, 30-second window).
Compute an HMAC over that time using the shared secret.
Truncate to a short numeric code (for example, 6 digits).
You see that code in an authenticator app; the server recomputes and verifies it.

Security properties:

Codes are short-lived (typically 30 seconds).
Without the shared secret, codes can’t be predicted.
Stealing one code is not enough to impersonate you later.

MFA sits above your encryption model:

It protects access to accounts and keys.
It does not replace the need for strong encryption like AES-256-GCM or strong KDFs such as PBKDF2 with high iteration counts.

MFA in the context of zero-knowledge systems

In a zero-knowledge design, the provider:

Never sees your decryption keys.
Cannot decrypt stored ciphertext.
Cannot reset or bypass your password-derived keys.

This is how Inkrypt behaves for notes:

Encryption happens client-side via the Web Crypto API.
Keys are derived from your password using PBKDF2 with 310k iterations.
Notes are encrypted with AES-256-GCM with a random IV per save.

Where does MFA fit?

MFA is ideal for accounts and systems where the provider controls login and key access.
In a password-per-note model with no global account (like Inkrypt), the “second factor” is usually how you share and store the password, not an app-provided MFA flow.

In other words: use MFA for:

Identity providers.
Admin panels.
Systems that guard access to encryption keys or management actions.

Use zero-knowledge models where you don’t want anyone—MFA or not—to have the power to bypass encryption on your behalf.

Common MFA pitfalls and how they affect security

MFA can be deployed in ways that look secure, but aren’t:

SMS-based codes:
Vulnerable to SIM swap and interception.
Better than nothing, but not great against targeted attackers.
Push fatigue attacks:
Attackers spam push approvals until a user taps “allow” just to stop the noise.
Weak shared secret handling:
Backup and export features can leak TOTP seeds.
Poor storage on the server side weakens assurances.

Practical guidance:

Prefer TOTP apps or hardware security keys over SMS.
Educate users that surprise prompts are a red flag.
Treat TOTP seeds as secrets; store them like passwords or keys.

MFA does not remove the need for:

Strong passwords (or passphrases).
Correctly implemented encryption (AES-256-GCM, PBKDF2).
Good key management and endpoint hygiene.

It adds a layer; it doesn’t erase existing responsibilities.

How Inkrypt’s model intersects with MFA

Inkrypt intentionally avoids accounts:

You choose a URL and a password per note.
The browser derives an AES key via PBKDF2 (310k iterations).
Notes are encrypted with AES-256-GCM through the Web Crypto API.
The server never sees your password or decryption key.

With no central account, there is no single login to wrap in MFA. Instead:

Your “first factor” is the note password.
You can treat password managers, secure channels, or separate devices as de facto second factors:
Store the note password in a password manager protected by MFA.
Share link and password over different channels (for example, link via email, password over a call).

MFA still matters for the services around Inkrypt:

Your email account (where links may flow).
Your password manager (if you use one).
Your device logins.

Securing those with MFA indirectly hardens your use of any zero-knowledge encrypted tool.

For more detail on the encryption side, see:

FAQ: Multi-factor authentication

Q1. Is MFA still necessary if I use strong passwords?

Yes. Strong passwords help against brute force and guessing, but MFA protects against credential reuse and phishing. An attacker who steals or guesses a password still has to bypass a second factor.

Q2. Is SMS-based MFA good enough?

SMS is better than no MFA, but it has known weaknesses like SIM swapping and interception. Prefer TOTP apps or hardware security keys where possible, especially for high-value accounts.

Q3. How does MFA relate to encryption like AES-256-GCM?

MFA protects who can log in and obtain keys; AES-256-GCM protects the actual content. They operate at different layers and are complementary, not interchangeable.

Q4. Can I add MFA to a zero-knowledge note system like Inkrypt?

Inkrypt doesn’t use accounts, so there is no central login to wrap in MFA. Instead, you secure the environment around it: password manager, email, and devices, all protected with MFA, while the notes themselves use client-side encryption with PBKDF2 and AES-256-GCM.

Q5. What’s the minimal MFA setup for a small team?

At a minimum, enable MFA for identity providers, email, password managers, and admin consoles. Those systems gate access to encryption keys, secrets, and configuration that affect everything else.

Where to go next

To understand how strong client-side encryption and MFA work together:

Then make sure your own environment is set up with MFA on the accounts that matter, and use a zero-knowledge encrypted note tool like Inkrypt at https://www.inkrypt.online for the sensitive text that shouldn’t live in plain sight anywhere.