Replied in thread
The solution to this problem is not MFA.
When you have a problem with passwords getting compromised/phished/bruteforced, and you solve it with #MFA, now you have two problems.
The solution to this problem is smart cards.
Recent searches
Search options
Administered by:
#mfa
1 post1 participant0 posts today
(sophos.com) Evilginx: How Attackers Bypass MFA Through Adversary-in-the-Middle Attacks https://news.sophos.com/en-us/2025/03/28/stealing-user-credentials-with-evilginx/
A short descriptive article about Evilginx and how stealing credentials work, a few suggested ways of detecting etc.
Summary:
This article examines Evilginx, a tool that leverages the legitimate nginx web server to conduct Adversary-in-the-Middle (AitM) attacks that can bypass multifactor authentication (MFA). The tool works by proxying web traffic through malicious sites that mimic legitimate services like Microsoft 365, capturing not only usernames and passwords but also session tokens. The article demonstrates how Evilginx operates, showing how attackers can gain full access to a user's account even when protected by MFA. It provides detection methods through Azure/Microsoft 365 logs and suggests both preemptive and reactive mitigations, emphasizing the need to move toward phishing-resistant FIDO2-based authentication methods.
Sophos News · Stealing user credentials with evilginxA malevolent mutation of the widely used nginx web server facilitates Adversary-in-the-Middle action, but there’s hope
New Privacy Guides article 
by me:
If you are using a YubiKey,
you might get in some situations where you need to reset your key to factory default, and/or set up a backup of it on a spare key.
This tutorial will guide you
through each step to reset and back up your YubiKey successfully, with clear instructions and plenty of visual support.
I hope you find it helpful!
https://www.privacyguides.org/articles/2025/03/06/yubikey-reset-and-backup/
Towards a test-suite for TOTP codes
https://shkspr.mobi/blog/2025/03/towards-a-test-suite-for-totp-codes/
Because I'm a massive nerd, I actually try to read specification documents. As I've ranted ad nauseam before, the current TOTP0 spec is irresponsibly obsolete.
The three major implementations of the spec - Google, Apple, and Yubico - all subtly disagree on how it should be implemented. Every other MFA app has their own idiosyncratic variants. The official RFC is infuriatingly vague. That's no good for a security specification. Multiple implementations are great, multiple interpretations are not.
So I've built a nascent test suite - you can use it to see if your favourite app can correctly implement the TOTP standard.
Please do contribute tests and / or feedback.
Here's what the standard actually says - see if you can find apps which don't implement it correctly.
Background
Time-based One Time Passwords are based on HOTP - HMAC-Based One-Time Password.
HOTP uses counters; a new password is regularly generated. TOTP uses time as the counter. At the time of writing this post, there have been about 1,740,800,000 seconds since the UNIX Epoc. So a TOTP with an period of 30 seconds is on counter (1,740,800,000 
30) = 58,026,666. Every 30 seconds, that counter increments by one.
Number of digits
How many digits should your 2FA token have? Google says 6 or 8. YubiCo graciously allows 7. Why those limits? Who knows!?
The HOTP specification gives an example of 6 digits. The example generates a code of 0x50ef7f19 which, in decimal, is 1357872921. It then takes the last 6 digits to produce the code 872921.
The TOTP RFC say:
Basically, the output of the HMAC-SHA-1 calculation is truncated to obtain user-friendly values 1.2. Background
But doesn't say how far to truncate.
There's nothing I can see in the spec that prevents an implementer using all 10. The HOTP spec, however, does place a minimum requirement - but no maximum:
Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code. Depending on security requirements, Digit = 7 or more SHOULD be considered in order to extract a longer HOTP value. RFC 4226 - 5.3. Generating an HOTP Value
(As a minor point, the first digit is restricted to 0-2, so being 10 digits long isn't significantly stronger than 9 digits.)
Is a 4 digit code acceptable? The security might be weaker, but the usability is greater. Most apps will allow a one digit code to be returned. If no digits are specified, what should the default be?
Algorithm
The given algorithm in the HOTP spec is SHA-1.
In order to create the HOTP value, we will use the HMAC-SHA-1 algorithm RFC 4226 - 5.2. Description
As we now know, SHA-1 has some fundamental weaknesses. The spec comments (perhaps somewhat naïvely) about SHA-1:
The new attacks on SHA-1 have no impact on the security of HMAC-SHA-1. RFC 4226 - B.2. HMAC-SHA-1 Status
I daresay that's accurate. But the TOTP authors disagree and allow a for some different algorithms to be used. The specification for HMAC says:
HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1 [Emphasis added] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
So most TOTP implementation allow SHA-1, SHA-256, and SHA-512.
TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions […] instead of the HMAC-SHA-1 function that has been specified for the HOTP computation RFC 6238 - TOTP: Time-Based One-Time Password Algorithm
But the HOTP spec goes on to say:
Current candidates for such hash functions include SHA-1, MD5, RIPEMD-128/160. These different realizations of HMAC will be denoted by HMAC-SHA1, HMAC-MD5, HMAC-RIPEMD RFC 2104 - Introduction
So, should your TOTP app be able to handle an MD5 HMAC, or even SHA3-384? Will it? If no algorithm is specified, what should the default be?
Period
As discussed, this is what increments the counter for HOTP. The Google Spec says:
The period parameter defines a period that a TOTP code will be valid for, in seconds. The default value is 30.
The TOTP RFC says:
We RECOMMEND a default time-step size of 30 seconds 5.2. Validation and Time-Step Size
It doesn't make sense to have a negative number of second. But what about one second? What about a thousand? Lots of apps artificially restrict TOTP codes to 15, 30, or 60 seconds. But there's no specification to define a maximum or minimum value.
A user with mobility difficulties or on a high-latency connection probably wants a 5 minute validity period. Conversely, machine-to-machine communication can probably be done with a single-second (or lower) time period.
Secret
Google says the secret is
an arbitrary key value encoded in Base32 according to RFC 3548. The padding specified in RFC 3548 section 2.2 is not required and should be omitted.
Whereas Apple says it is:
An arbitrary key value encoded in Base32. Secrets should be at least 160 bits.
Can a shared secret be a single character? What about a thousand? Will padding characters cause a secret to be rejected or can they be safely stripped?
Label
The label allows you to have multiple codes for the same service. For example Big Bank:Personal Account and Big Bank:Family Savings. The Google spec is slightly confusing:
The issuer prefix and account name should be separated by a literal or url-encoded colon, and optional spaces may precede the account name. Neither issuer nor account name may themselves contain a colon.
What happens if they are not URl encoded? What about Matrix accounts which use a colon in their account name? Why are spaces allowed to precede the account name? Is there any practical limit to the length of these strings?
If no label is specified, what should the default be?
Issuer
Google says this parameter is:
Strongly Recommended The issuer parameter is a string value indicating the provider or service this account is associated with, URL-encoded according to RFC 3986. If the issuer parameter is absent, issuer information may be taken from the issuer prefix of the label. If both issuer parameter and issuer label prefix are present, they should be equal.
Apple merely says:
The domain of the site or app. The password manager uses this field to suggest credentials when setting up a new code generator.
Yubico equivocates with
The issuer parameter is recommended, but it can be absent. Also, the issuer parameter and issuer string in label should be equal.
If it isn't a domain, will Apple reject it? What happens if the issuer and the label don't match?
Next Steps
- If you're a user, please contribute tests or give feedback.
- If you're a developer, please check your app conforms to the specification.
- If you're from Google, Apple, Yubico, or another security company - wanna help me write up a proper RFC so this doesn't cause issues in the future?
Time-based One Time Passwords. Not the TV show you remember from your youth, grandad. ↩︎
Terence Eden’s Blog · Towards a test-suite for TOTP codesBecause I'm a massive nerd, I actually try to read specification documents. As I've ranted ad nauseam before, the current TOTP spec is irresponsibly obsolete. The three major implementations of the spec - Google, Apple, and Yubico - all subtly disagree on how it should be implemented. Every other MFA app has their own idiosyncratic variants. The official RFC is infuriatingly vague. That's no good for a security specification. Multiple implementations are great, multiple interpretations are…
Replied in thread
System Administration
Week 4, Multiuser Fundamentals
We don't have a video for this segment, but here are the slides discussing group dynamics, foundations of trust (and #ZeroTrust), like Least Privilege, headless users or service accounts, group permissions, many examples of different forms of multi-factor authentication #mfa, and raising privileges (a topic we'll come back to again later in the semester).
I recently saw an interesting thread elsewhere: someone expressing high frustration with two factor/multifactor authentication in their day to day life, and nearly every response being of agreement, sometimes very vehement. I don’t think most of these people worked in infosec or IT. Some were dealing with MFA on university systems, some on work systems. They all loathed it. But the why expressed by many for the loathing was what was really interesting. Sure, many expressed irritation about being interrupted multiple times a day by MFA prompts, some were annoyed that it was in place for what they saw as systems that “didn’t need to be that secure”, etc. The common refrains one hears from people in security awareness discussions and/or about less user friendly implementations. But the broadest sentiment?
That it didn’t matter because their PII - their SSNs, their credit card numbers, so on and so forth - had already been stolen so many times, that nothing was really being done to stop that from happening, that it was happening more and more and the companies responsible for losing the data weren’t being punished. In the face of all that, they didn’t want to have to keep dealing with the pain of being forced to use MFA when they felt it wasn’t helping anything,
Replied in thread
@Tarah : MFA sucks. Alex Weinert wrote in _2019_, in https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/all-your-creds-are-belong-to-us/ba-p/855124:
❝
A few days ago, our team helped someone who had been a target of account takeover (ATO). Despite protecting the account with mandatory two-step verification using SMS and the Authenticator app, attackers had broken into the account and changed the password.
MFA had failed.
❞
Every idiot can now hire an "Evil Proxy" service (using EvilGinx2 or similar).
Watch the animated GIF's in https://phishify.nl/phishing-blog/aitm-de-geavanceerde-phishing-techniek-die-mfa-te-slim-af-is/ (such as https://phishify.nl/img/aitm-phishing.gif).
We need to fix the web (https://infosec.exchange/@ErikvanStraten/113884179304004056) instead of hanging on to old and failing (https://www.heise.de/en/news/Microsoft-Problems-with-Authenticator-for-Microsoft-365-services-10253490.html) technology with flawed implementations (https://www.usenix.org/conference/usenixsecurity23/presentation/gilsenan).
And we need better passkeys (https://infosec.exchange/@ErikvanStraten/113832302818012852).
TIL Proton dropped their maximum supported security keys (some time after mid-August 2024) from 8 to 4 keys?! (Notice the tiny "8 out of 4" label, because I had registered the maximum 8 keys)
I suspect my current config will be stable until I need to explicitly delete a key, in which case I won't be able to add a replacement unless I delete five keys. 
Replied in thread
@GossiTheDog : it's not the lack of MFA that is the problem.
Problem 1) is that a SPOF (*) is permitted access to data of millions (either directly or indirectly). This risk includes compromise of client devices.
2) Weak MFA (+) does not prevent these attacks, because the SPOF may be phished into entering their credentials in a third party page that imitates the intended Citrix Netscaler.
Please do not promote a flawed fix for bad passwords (2019: https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/all-your-creds-are-belong-to-us/ba-p/855124).
(*) Single Point Of Failure
(+) SMS, Voice, TOTP, Number Matchting, Location
TECHCOMMUNITY.MICROSOFT.COMAll your creds are belong to us!Multi-factor Authentication (MFA) matters.
Das #MFA Setup bei #GitLab ist ja auch bescheuert. Hardware tokens (yubikeys und so) kannst du beliebig viele einrichten, #TOTP-authenticator nur einen. Wäre ja kein Problem, aber wenn du den TOTP-Authenticator neu einrichten willst (zb. weil das Smartphone wo er drauf war eingegangen ist) musst du mfa komplett deaktivieren (und damit auch *alle* hardware tokens entfernen), um dann alles wieder neu zu registrieren..
Wer hat sich diesen Schmarren ausgedacht?
Jason Parker @north (*) referred to an interesting new video: https://www.youtube.com/watch?v=wVyu7NB7W6Y (Jason did that in https://ꩰ.com/@north/113179253606203417).
Among others, Karsten Nohl (https://en.wikipedia.org/wiki/Karsten_Nohl) explains the risks of the old and increasing vulnerable SS7 (Signaling System 7) infrastructure, that is still being used by "modern" (mobile) telecom networks.
It is one of the reasons why SMS is a very weak MFA factor (as I also touched upon in https://infosec.exchange/@ErikvanStraten/113180359056389285).
(*) BTW, Mastodon may hide the domain name, but the ASCII Punycode for the IDN part of the domain name "ꩰ.com" that I do see is "xn--8r9a" (as can be seen in https://www.charset.org/punycode) - which possibly is even more meaningless (see https://crt.sh/?Identity=xn--8r9a.com).
Replied in thread
@north : SMS *is* 2FA, albeit weak.
The problem with "something you know, are, or have" is that users are never told that it is essential that each factor used cannot be easily copied, stolen, guessed etc. or temporarily fall into the wrong hands (literally in this case).
Another problem is that if you loose a factor, you may no longer have access to your account.
So each factor must be strong, carefully kept secret and needs to be backupped. These are extreme requirements that nobody wants (you) to understand.
P.S. both iPhones and Android phones can be configured to *not* show SMS texts (and most other possibly confidential information) on their screen when locked.
P.P.S. Unlocked phones are vulnerable to Time Traveler TOTP attacks. An attacker with temporary access to an unlocked phone may change the system date/time to the future, read a TOTP code for a website, and restore correct system time. When the future arrives they can use your TOTP code at their leisure on their own device to log in to your account, and reuse it (within 30 sec.) if required to pwn your account.
P.P.P.S. Weak 2FA/MFA does not prevent AitM (Attacker in the Middle) phishing attacks if the AitM uses Evilginx2 or some other "evil proxy" website.
2019 "MFA had failed" (by Alex Weinert, Director of Identity Security at Microsoft) https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/all-your-creds-are-belong-to-us/ba-p/855124
TECHCOMMUNITY.MICROSOFT.COMAll your creds are belong to us!Multi-factor Authentication (MFA) matters.
MFA required for the Azure Portal starting in October. I know why it's taking everyone so long to require it, but comeooooooon.
Microsoft Azure Blog · Announcing mandatory multi-factor authentication for Azure sign-in | Microsoft Azure BlogLearn how MFA can protect your data and identity, and get ready for the upcoming MFA requirement for Azure.
fefe zu #MFA:
"NATÜRLICH haben sie ihn erst zugegeben, nachdem die Staatsanwaltschaft die Beweise gegen sie in der Hand hatte. NATÜRLICH haben die da Millionen von Datensätzen herumliegen gehabt. NATÜRLICH kam keiner von deren Auftraggebern auf die Idee, da mal nachzugucken, mit was für einer unseriösen Klitsche sie da ihre Verträge abschließen..."
https://blog.fefe.de/?ts=98782801
blog.fefe.deFefes Blog
Replied in thread
@GossiTheDog It’s a good start! #AWS doesn’t even let admins force #IAM users to use #MFA !
‘Got that boomer!’: How cyber-criminals steal one-time passcodes for SIM swap attacks and raiding bank accounts
Estate is/was a tool/service that allowed threat actors to intercept one time passcodes (often used as #mfa factors) to access targets’ accounts.
Estate claimed to not log/retain data of attackers, but a bug leaked the database, and that turned out to be false.
Never give data/codes to unsolicited callers. If you are called by someone claiming to be from your bank or another sensitive account, always hang up and call from a known good number for the establishment (for banks, the number on the back of your card).
Scammers will try hard to keep you on the phone.
TechCrunch · 'Got that boomer!': How cybercriminals steal one-time passcodes for SIM swap attacks and raiding bank accounts | TechCrunchEstate helped hundreds of cybercriminals make automated calls aimed at stealing account passcodes, according to its leaked database.
Lots of new followers (hi!) recently. Some of you are in the #infosec or #cybersecurity communities, the #privacy community, both, or neither. I post privacy and #security related things for individuals and small/micro organizations.
Some are looking for a place to “get started” with improving their privacy and/or security online. In any case, privacy and security start with some basics that I strongly believe everyone should do:
1. Develop good password management practices, which includes NOT reusing #passwords.
2. Keep your device #software and firmware updated.
3. Use multifactored authentication #mfa / two-factored authentication #2fa
Security is a process. It is also the foundation to online privacy; what good is it to use an encrypted email service if you are reusing weak passwords from your other online accounts?
Avoid the Hack (avoidthehack!) · Getting Started: Basic Personal Cybersecurity for Everyone (3 Easy Tips) | Avoid the Hack (avoidthehack!)
2FA (MFA) beschermt *niet* tegen steeds meer phishingaanvallen:
<<<Tycoon 2FA operates as an adversary-in-the-middle (AitM) phishing kit. Its primary function is to harvest Microsoft 365 and Gmail session cookies. >>>
https://www.proofpoint.com/us/blog/email-and-cloud-threats/tycoon-2fa-phishing-kit-mfa-bypass
U kunt zichzelf hier prima tegen beschermen, zonder passkeys of software van bijvoorbeeld Proofpoint te gebruiken: zie https://security.nl/posting/841126
Proofpoint · Tycoon 2FA: Phishing Kit Being Used to Bypass MFA | Proofpoint USExplore Tycoon 2FA, a sophisticated phishing kit used to bypass MFA. Learn how it works, what an attack looks like, detection techniques and more.
An ESP32 MultiFactor TOTP Generator - MFA, or multifactor authentication, is a standard security feature these days. How... - https://hackaday.com/2024/03/07/an-esp32-multifactor-totp-generator/ #visualstudiocode #esp32-wrover-32 #securityhacks #softwarehacks #platformio #totp #lcd #mfa
Hackaday · An ESP32 MultiFactor TOTP GeneratorMFA, or multifactor authentication, is a standard security feature these days. However, it can be a drag to constantly reach into one’s pocket, scroll to Google Authenticator (other MFA appli…