@pierostrada

Not topping my shortlist in https://infosec.exchange/@ErikvanStraten/with_replies, but:

3. Make backups. Multiple, stored at different physical locations.

4. Be prepared for account lockout.

@LukefromDC : it won't be that bad (it will be bad, but in a different way).

ANY website may ask a user to confirm they are 18+ (or whatever age).

There will be a huge amount of AitM (Attacker in the Middle) websites where naive people will be lured to (using fake emails, SMS, chat app messages or falsified QR-codes) and asked to confirm their age.

That AitM website will subsequently obtain a "ticket" (session cookie) from a real "relying party" website (with a potentially very different type of content than the victim is told).

Those "tickets" will be sold (or traded for watching ads and/or paying with privacy).

Reliable authentication requires a trustworthy identity verifier (even if identification is restricted to age+).

@drgroftehauge @fabio @SylvieLorxu

@VXShare @StarkRG @jay @vildis @vxunderground OFC, if their corporate firewall didn't blocklist your domain, most #MITM-based "#NetworkSecurity" solutions and "#EndpointProtection" will checksum files and instantly yeet them into the shadow realm.

• Researchers should OFC only run those said malware only for research purposes and on #airgapped, sanctioned systems but they need to get their hands on them in the first place.

And lets be honest: Like with chemistry and medicine, one wants to have a supplier that isn't shady af but actually transparent.

• The "alternative" would be to go into some "dark corners" and risk getting something else entirely.

@relishthecracker : that's make belief.

"Wow, asymmetric encryption, even quantum-computer-proof", "military-grade", etcetera.

Right after logging in using a passkey with an unbreakably protected private key, the website sends a session cookie (or similar) to the browser - which is NOT protected like private keys. If a website (like most of them) does not log you out if your IP-address changes, such a cookie is nearly as bad as a password. And fully if the cookie never expires.

Therefore:

Even if attackers cannot copy private keys: if the user device is sufficiently compromised (i.e. on Android, running an accessibility service), they can take over all of the user's accounts;

If the user's browser is compromised, attackers can copy session cookies and use them to obtain access to accounts the user logs in to;

An AitM (Attacker in the Middle) using a malicious website can copy/steal authentication cookies. Such AitM-attacks are possible in at least the following cases if either:

• A malicious third party website manages to obtain a fraudulently issued certificate (examples: https://infosec.exchange/@ErikvanStraten/112914050216821746);

• An attacker obtains unauthorised write access to the website's DNS record;

• An attacker manages to obtain access to a server where a "dangling" (forgotten) subdomain name points to, *AND* the real authenticating server (RP) does not carefully check for allowed subdomains (see https://github.com/w3ctag/design-reviews/issues/97#issuecomment-175766580);

The server is compromised or has a rogue admin: the attacker can add their passkey's public key to your account, or replace your public key with theirs (note that passkey pubkeys are not encapsulated by certificates issued by trusted issuers, stating who owns the public key).

Phishing using fake websites is probably the number one problem on the internet. *THE* major advantage of passkeys is that they make phishing attacks VERY HARD.

Indeed, if your device is sufficiently compromised, the risk of all of your passwords being stolen if you use a password manager is BIG.

However, as I wrote, if your device is sufficiently compromised, an attacker does not need access to your private keys in order to obtain access to your accounts.

@oliversampson @kaye

@oliversampson @kaye

Primary passkeys advantage:
• With some uncommon exceptions, you cannot (be persuaded to) log in to a phishing website with a (slightly) different domain name *USING A PASSKEY* (see below) - because software (not you) checks the domain name.

Some passkeys disadvantages:
• Typically you yourself do not have access to each passkey's private key (*)(usually you can't back them up/export them). Risks: vendor lock-in and losing access to accounts.

• Because there's a risk of losing access to passkeys and thus to accounts, usually accounts can also be accessed using a rescue code - which renders them phishable again.

• Implementation errors (both Apple and Android suffered from them, and probably still do - I did not check today).

(*) For each new passkey, your device generates a unique complementary keypair. The public key is stored in your account on the server and is used to verify that your device has access to the complementary private key, which is kept secret. However, even if attackers do not have access to your private key(s), there are other ways for them to obtain access your account(s).

A reasonable alternative to passkeys is using a password manager that "integrates" with the browser to verify the domain name of the site you're logging in to. Android and iOS "Autofill" provide such a bridge between password managers and browsers (without requiring browser plug-ins).

@tychotithonus : thank you for responding. I'm not trying to be aggressive but to make the internet safer.

In your original toot, you wrote: "It's comforting to know that I'm significantly protected from these attempts" while showing phishing messages.

From https://blog.talosintelligence.com/how-are-attackers-trying-to-bypass-mfa/ (a year ago):
"In the latest Cisco Talos Incident Response Quarterly Trends report, instances related to multi-factor authentication (MFA) were involved in nearly half of all security incidents that our team responded to in the first quarter of 2024".

From my own research I know that the number of phishing-sites is exploding. PhaaS makes it easy to take over accounts where weak MFA is used.

The more people use weak MFA, the more of these sort of attacks we'll be seeing. IOW, the security of weak MFA (TOTP, SMS, number matching) will decrease over time (it does since Alex Weinert wrote this in 2019: https://techcommunity.microsoft.com/blog/microsoft-entra-blog/all-your-creds-are-belong-to-us/855124).

Furthermore, from the page referenced by you, https://meta.wikimedia.org/wiki/Steward_requests/Global_permissions#Requests_for_2_Factor_Auth_tester_permissions:
"Testing this service may result in the loss of your access and is not recommended for inexperienced users."

TOTP effectively means a unique strong (server supplied) password per account that people can impossibly remember. A TOTP app simply is a disguised password manager.

There have been lots of incidents where people lost access to multiple MFA-proteced accounts because they lost access to the shared secrets on their phones. Nobody tells people to make sure that backups are made of such secrets, let alone in a secure and privacy-respecting manner.

Note: a lot of TOTP apps had serious security issues a couple of years ago, as documented by Conor Gilsenan et al. in https://www.usenix.org/conference/usenixsecurity23/presentation/gilsenan (source: https://infosec.exchange/@conorgil/109542074585730853). I doubt that things have significantly improved (Authy was really bad, and at the time, Google's app blocked backups of the shared secrets).

Here's an, IMO, way better advice: use a password manager that checks the domain name. Use it to generate long random passwords, and make sure that it's (encrypted) database is backed up after every change you make.

I wrote about the caveats of password managers in, for example, https://infosec.exchange/@ErikvanStraten/113022180851761038.

Recommending people to use TOTP because they use weak passwords is a bad idea IMO: you effectively make them use a password manager (which a TOTP app is, while it does not check domain names) instead of solving the primary problem: weak passwords.

@conorgil

@tychotithonus : can you explain which protection(s) are provided by weak MFA?

@Linux #ClownFlare is literally a #ValueRemoving #RentSeeker that #MITM's traffic to capture #Logins in #PlainText & also acts as #RogueISP hosting everything from #CSAM to #Cybercrime and #Terrorism.

• There is no legitimate reason to use #CloudFlare for anything!

@mensrea : if you visit a shop (or a bank) in the center of the city, chances are near zero that it's run by impostors.

However, if you go to some vague second hand market, chances are the you will be deceived.

Possibly worse, if there's an ATM on the outside wall of a shack where Hells Angels meet, would you insert your bank card and enter your PIN?

On the web, most people do not know WHERE they are.

Big Tech is DELIBERATELY withholding essential information from people, required to determine the amount of trust that a website deserves.

DELIBERATELY, because big tech can rent much more (cheap) hosting and (meaningless) domain names to whomever if website vistors cannot distinguish between authentic and fake websites.

You are right that some people will never understand why they need to know who owns a website.

However, most people (including @troyhunt ) would enormously benefit.

Like all the other deaf and blind trolls, you trash a proposal because it may be useless for SOME, you provide zero solutions and you keep bashing me.

What part of "get lost" do you not understand?

@aral @EUCommission @letsencrypt @nlnet

@mensrea : it is not the UI/UX that is the problem. It is missing reliable info in the certs.

Image from https://infosec.exchange/@ErikvanStraten/114224682101772569

@aral @EUCommission @letsencrypt @nlnet

@aral : most Let's Encrypt (and other Domain Validated) certificates are issued to junk- or plain criminal websites.

They're the ultimate manifestation of evil big tech.

They were introduced to encrypt the "last mile" because Internet Service Providers were replacing ads in webpages and, in the other direction, inserting fake clicks.

DV has destroyed the internet. People loose their ebank savings and companies get ransomwared; phishing is dead simple. EDIW/EUDIW will become an identity fraud disaster (because of AitM phishing atracks).

Even the name "Let's Encrypt" is wrong for a CSP: nobody needs a certificate to encrypt a connection. The primary purpose of a certificate is AUTHENTICATION (of the owner of the private key, in this case the website).

However, for human beings, just a domain name simply does not provide reliable identification information. It renders impersonation a peace of cake.

Decent online authentication is HARD. Get used to it instead of denying it.

REASONS/EXAMPLES

Troy Hunt fell in the DV trap: https://infosec.exchange/@ErikvanStraten/114222237036021070

Google (and Troy Hunt!) killed non-DV certs (for profit) because of the stripe.com PoC. Now Chrome does not give you any more info than what Google argumented: https://infosec.exchange/@ErikvanStraten/114224682101772569

https:⧸⧸cancel-google.com/captcha was live yesterday: https://infosec.exchange/@ErikvanStraten/114224264440704546

Stop phishing proposal: https://infosec.exchange/@ErikvanStraten/113079966331873386

Lots of reasons why LE sucks:
https://infosec.exchange/@ErikvanStraten/112914047006977222 (corrected link 09:20 UTC)

This website stopped registering junk .bond domain names, probably because there were too many every day (the last page I found): https://newly-registered-domains.abtdomain.com/2024-08-15-bond-newly-registered-domains-part-1/. However, this gang is still active, open the RELATIONS tab in https://www.virustotal.com/gui/ip-address/13.248.197.209/relations. You have to multiply the number of LE certs by approx. 5 because they also register subdomains and don't use wildcard certs. Source: https://www.bleepingcomputer.com/news/security/revolver-rabbit-gang-registers-500-000-domains-for-malware-campaigns/

@EUCommission @letsencrypt @nlnet

@0xF21D #ClownFlare is a #RogueISP and their #MITM-based approach eould've always allowed that.

• Why is ANYONE here surprised of that?

Seriously!

@0xF21D wrote: "[...] something we technically knew was going on before but didn't consciously consider a threat, until now."

I've been warning for CDN's like Cloudflare and Fastly (and cloud providers in general) for a long time.

Here's a recent toot (in Dutch, the "translate" button should do the job): https://infosec.exchange/@ErikvanStraten/114042082778156313.

If you trust Google to translate it (guaranteed NOT error-free, it *may* work in other browsers than Chrome): https://infosec-exchange.translate.goog/@ErikvanStraten/114042082778156313?_x_tr_sl=nl&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp

P.S. Fastly knows your https://infosec.exchange login credentials.

@malanalysis