Quiz Entry - updated: 2026.07.14
How do common login/2FA schemes (iTAN, mTAN, TOTP, manual C/R, semi-/full-automatic C/R) compare against attacks like phishing, session hijack, MITM, and man-in-the-browser?
Streichliste/iTAN fails everything. mTAN and TOTP protect login confidentiality but lose transaction integrity. Manual and semi-/auto C/R (chipTAN, PhotoTAN) protect both — they're the only ones that survive a man-in-the-browser.
The full comparison matrix:
| Method | Login (Confidentiality) | Transactions (Integrity) | Offline-Phishing | Live-Phishing | Session Hijack | MITM | Man-in-Browser |
|---|---|---|---|---|---|---|---|
| Streichliste (iTAN) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| mTAN (SMS-TAN) | ✓ | ⚠ (depends on user; SIM-swap) | ✓ | ✗ | ✗ | ✗ | ✗ |
| TOTP (App-Code) | ✓ (at login) | ✗ (no transaction binding) | ✓ | ✗ | ✗ | ✗ | ✗ |
| C/R manual (chipTAN, PhotoTAN visible) | ✓✓ | ✓✓ (transaction binding!) | ✓ | ✓ | ✓ | ✓ | ✓ |
| C/R semi-/fully-automatic (QR-TAN) | ✓ to ✓✓ | ✓✓ (if data displayed) | ✓ | ✓ | ✓ | ⚠ (depends on interface) | ✓ |
The decisive feature: does the device show what you're signing?
- iTAN, mTAN, TOTP — show no transaction context. Attacker who hijacks the session can do anything once you're in.
- chipTAN, PhotoTAN — show the transaction details on a separate, malware-free screen. You see the real amount + recipient and only then confirm. Even total browser compromise can't hide a wrong amount.
Why iTAN died: a paper list of pre-computed numbers ("use TAN #47 for your next transaction") gave zero protection against phishing — attackers asked for a sequence of TANs and exhausted the list.