#Private #cloud for your #memories, with apps for #mobile, #desktop and web.
#End-to-end encrypted, #FOSS cloud for #Photos, #2FA secrets and more!
Ente is a #service that provides a fully open source, end-to-end encrypted platform for you to store your data in the cloud without needing to trust the service provider. On top of this platform, we have built two apps so far: Ente Photos (an alternative to Apple and Google Photos)
#Private #cloud for your #memories, with apps for #mobile, #desktop and web.
#End-to-end encrypted, #FOSS cloud for #Photos, #2FA secrets and more!
"Ente is a #service that provides a fully open source, end-to-end encrypted platform for you to store your data in the cloud without needing to trust the service provider. On top of this platform, we have built two apps so far: Ente Photos (an alternative to Apple and Google Photos)"
#TroyHunt fell for a #phishing attack on his mailinglist members: https://www.troyhunt.com/a-sneaky-phish-just-grabbed-my-mailchimp-mailing-list/
Some of the ingredients: #Outlook and its habit of hiding important information from the user and missing #2FA which is phishing-resistant.
Use #FIDO2 with hardware tokens if possible (#Passkeys without FIDO2 HW tokens are NOT phishing-resistant due to the possibility of being able to trick users with credential transfers: https://arxiv.org/abs/2501.07380) and avoid Outlook (or #Microsoft) whenever possible.
Further learning: it could happen to the best of us! Don't be ashamed, try to minimize risks and be open about your mistakes.
Note: any 2FA is better than no 2FA at all.
Zwangsmigration von IMAP-Postfächern zu Microsoft:
"Daten würden künftig auf allen Geräten synchronisiert […], heißt es in der Mail. Zudem sei Zwei-Faktor-Authentifizierung möglich"
Synchronisation war doch der Gedanke hinter der Entwicklung von IMAP. Und 2FA sollte doch inzwischen jeder anbieten können.
(Ok, bei "klassischem" IMAP läuft es auf Anwendungspasswort hinaus. Aber auch da gibt es Möglichkeiten.)
#IMAP #2FA #HostEurope
https://www.heise.de/news/Host-Europe-bittet-zur-Kasse-Mailmigration-ab-Mai-10326806.html
Gezielte Umgehung der Zwei-Faktor-Authentisierung (#2FA) durch Voice Phishing (#Vishing) - #Telekom und #DHL warnen aktuell, der Angriffsvektor gilt aber generell für alle Online-Konten mit schwacher SMS-Absicherung:
"Betrüger geben sich derzeit am Telefon als Mitarbeitende der Telekom oder von DHL aus und versuchen die Angerufenen dazu zu bringen, empfangene SMS-Codes durchzugeben."
blog! “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 about the current TOTP spec being 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…
Read more: https://shkspr.mobi/blog/2025/03/towards-a-test-suite-for-totp-codes/
⸻
#2fa #CyberSecurity #HTOP #MFA #OpenSource #totp
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
Time-based One Time Passwords. Not the TV show you remember from your youth, grandad. ↩︎
2FA codes sent over ActivityPub when?
The #Security #Trinity - spotted at @bitwarden explains how to secure your accounts with 2FA:
https://bitwarden.com/resources/presentations/the-triangle-of-security-success/
And rightly so: Because #encrypted email get even more secure with #2FA and #passwordmanagers 
Check out our top 3:
https://tuta.com/blog/best-password-manager
@lauren : in 2020 I wrote a "Secure SMS 2FA Proposal" (https://security.nl/posting/638976) - there's English and Dutch text.
The main idea is for the recipient to modify the received code using a shared secret, before entering it as the second factor.
Of course weak 2FA (without E2EE channel binding) is not phishing proof, but my proposal should prevent successful SIM-swap attacks (and redirecting calls and messages by manipulating the telco backbone as shown in https://www.youtube.com/watch?v=wVyu7NB7W6Y).
I cannot change anything in those postings anymore (and I'm in no way related to security.nl apart from being a regular -unpaid- contributor).
Feel free to pass this idea to your contacts at Google as an alternative to QR-codes - from which I fail to understand how they'd improve security. In fact, the unprotected channel from screen with QR-code to the camera recording it, allows for all kinds of (AitM) phishing attacks.
Gmail: Google sostituisce i codici SMS con i QR code per l’autenticazione
https://gomoot.com/gmail-google-sostituisce-i-codici-sms-con-i-qr-code-per-lautenticazione/
I really find it weird when I activate a #Passkey for a page and it completely removes the #2FA options.
Are Passkeys not supposed to be the better alternative to passwords? Why is it make my login less secure?
PayPal is especially confusing here. It states 2FA is enabled. But it's only asked for, when I log in with a password. If I use the Passkey it's skipped.
That's definitely more convenient but, in my opinion, way less secure. It makes me consider to opt-out of Passkeys altogether.
I think I've created the *least* secure multi-factor authentication code.
Please can you try adding this to your MFA app and tell me if it *doesn't* work.
THANKS GANG!
A tale from the shithole of #Microsoft #Outlook. 1/2
For reasons outside my control I had to setup an #IMAP account with #Microsoft #Exchange Online with #2FA #OAuth2. After some ado, it worked on 2 Linux computers with Mozilla #Thunderbird.
#Privacy is bad because you have to enable cookies for all parts of the Thunderbird profile, but it works.
On the 3rd computer, the 2FA failed. Error 50058, a Microsoft-window with the email address flashing along but no way to enter anything. 1/2
How Symantec VIP Access Holds Your Security Codes Hostage
https://spectra.video/videos/watch/df42ea11-191f-4fde-9834-1583e16ed8b2
I’ve Avoided Owning a Cell Phone Until Today. This is What it Was Like
I've been experimenting my entire life to see what it's like to not own a cell phone and see how difficult it is to do.
https://www.freezenet.ca/ive-avoided-owning-a-cell-phone-until-today-this-is-what-it-was-like/
FFS, #Duo, if I wanted my accounts backed up to Google I'd have used Google Authenticator instead, so stop asking!
#2FA #Cisco #enshittification
Well, that was dumb. If you setup #2FA for @1password with 1password storing the security key, you account goes offline and you can't signin in the app because it wants a physical security key and can't use the one stored in 1password.
G◍M◍◍T 
