Latest issue of my curated #cybersecurity and #infosec list of resources for week #18/2025 is out!
It includes the following and much more:
France has linked Russian APT to 12 #cyberattacks on French Orgs.;
Cybersecurity experts demand the reinstatement of Chris Krebs' security clearances and the withdrawal of the investigation;
#Vulnerabilities in Apple's #AirPlay Protocol;
New York's Metropolitan Transportation Authority plans to use #AI and cameras to detect potential subway crimes before they happen;
@SentinelOne Targeted by Chinese #PurpleHaze Group;
#Microsoft sets all new accounts #passwordless by default;
The #Trump administration plans to cut $491 million from #CISA's budget;
Subscribe to the #infosecMASHUP newsletter to have it piping hot in your inbox every week-end
https://infosec-mashup.santolaria.net/p/infosec-mashup-18-2025
LemonLDAP::NG 2.21 is out!
Read our release notes: https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-21-0-is-out/
Been a while since someone tried to break into one of my #passwordless accounts. Those always leave me a bit on edge.
With no password, the only thing between and attacker and me is a slip of my thumb in an authenticator app. If I sneeze while opening the app to click "Deny" or "No, it's not me" I could let the attacker in.
At lease Microsoft now gives up some details about the attacker: 20.151.178.114
Oh, except that IP is Microsoft. Which doesn't help a lot. If it didn't say "Firefox" I might even believe it was some kind of technical error within Microsoft's systems.
What does your password manager set up look like?
This post discusses the real-world complexity of going passwordless and explores why strengthening your existing password protocols may be the simpler solution.
#password #passwordless #authentication #2fa
https://thehackernews.com/2024/09/why-is-it-so-challenging-to-go.html
It's even WORSE than I thought.
If a miscreant steals your iPhone or iPad, either unlocked or after watching you enter its passcode, they may be able to access all of your data in iCloud and in your AppleID cloud settings using a browser - even if you configured Screen Time Restrictions to limit access to critical data.
Here's how (where it reads "Touch ID" replace that with "Face ID" if your iDevice isn't equipped with a fingerprint scanner);
Assuming that you've NOT configured biometrics to unlock your iPhone or iPad (OR you've turned off 'Settings' > 'Touch ID and Passcode' > 'Password Autofill'), and:
You open, for example using Safari,
https://appleid.apple.com/sign-in
or
https://icloud.com and tap 'Sign in'
and:
You tap the (x) at the top right of the box that pops up at the bottom of the screen, and:
You tap in the field labeled "Email or phone number", and:
At the bottom of the screen, in the light gray box reading "Sign in to apple.com with your saved passkey?", you tap the blue button that reads:
Use "<your icloud.com email address>"
then the browser you're using is logged in to your AppleID account or to your iCloud account respectively.
Consequences
In your Apple ID account, you (or an attacker who does this) can see all -and edit most- of your account details. I've not tested it but they may now be able to lock *you* out of your account.
In your iCloud account they can choose 'Locate device' and disable *any other* iDevice you may have.
This is *even* true if you've configured "Screen time" restrictions in such a way [1] that a thief of your iDevice, who succeeds in unlocking it's screen (*), CANNOT view your account details ar the top of 'Settings', while it even fully hides the 'Touch ID and Passcode' submenu entry in 'Settings'.
(*) For example, after they watched you enter your passcode (see WSJ's Joanna Stern's video's that I referred to in my previous toot) - OR IF THEY SIMPLY STOLE IT FROM YOU IN AN UNLOCKED STATE!
[1] https://www.ghacks.net/2024/01/31/how-to-block-account-changes-on-iphone-using-screen-time/
Mitigations
Screen Time Restrictions [1] *does* seem to add an extra defensive layer, albeit probably insufficient.
After enabling it (note that it takes about a minute or so before all protections are actally in place, so be patient), when logged in to your Apple ID account using a browser, doing most (if not all) things labeled 'Continue on device...' do not work (no notification will be received by the iDevice). However, an attacker can probably still wreak havoc.
It's best to configure biometrics EVEN if you don't intend to use it to unlock your iDevice(s).
Note: personally I've configured only my pinky finger to unlock the screen of my iPhone SE2. One advantage is that I can unlock my iPhone in public places without (most of the times) having to enter my screen unlock passcode.
IMPORTANT: after configuring biometrics, confirm that 'Settings' > 'Touch ID and Passcode' > 'Password Autofill' is ON.
@MarcusAnthonyCyganiak : albeit not really what you meant, but IMO that's *another* good example of passwordless.
It's he fact that most email programs/apps (such as Apple mail on my iPhone) ask you to enter your server credentials ONCE - and never again. And that's scary if an attacker obtains access to an unlocked device.
The same probably applies when saving passwords in browsers that do not require a master password (every time) to unlock them (I've never used the "Remember me" feature/bug).
One more: WiFi.
Thanks for the tip, without realizing it Ithere appear to be more passwordless systems than I figured. I guess it's time (for me) to make a list of such shortcuts.
@webhat : Passwordless actually exists on iPhone or iPad under realistic circumstances - that is, not taking into account unlocking the screen (using a PIN, a password or biometrics).
Consider the situation when some stranger borrows your iPhone to make a phone call, or you let your child play a game on your iPad: in such cases they may be able to log in as you onto various websites. That is, without knowing your screen unlock code (or somehow being able to simulate your biometrics).
On specific websites this even also works when using passkeys (no PIN, password or biometrics is required to use the passkey).
It obviously is a vulnerability. But after I filed a bug report in June 2023, Apple denied that it is. And they've not fixed it either.
BTW this works (on iPhone or iPad) in Safari, Firefox, Edge and Chrome (except that in Chrome, "passkey without local auth", only works if, in condition below, only iCloud Keychain is enabled and no other 'optional' password manager - such as KeePassium).
The conditions are:
The password or passkey is stored in iCloud KeyChain;
EITHER: you've NOT configured any biometrics to unlock the screen (meaning that you must use a pincode or a password to unlock the screen - a use case quite common because some people don't like to use, or don't trust, biometrics),
OR: (not common, I found it during testing) 'Settings' > 'Touch ID and Passcode': 'Password Autofill' is OFF;
In 'Settings' > 'Passwords' > 'Password Options' (all quite common):
• 'Autofill Passwords and Passkeys' is ON;
• ' iCloud Keychain' is ON;
• Optionally another password manager is enabled (in my iPhone 'KeePassium' is ON).
Passkeys only: (this is irrelevant for passwords, and applies only to iOS and iPadOS versions that support passkeys): the website you (or the borrower of your iDevice) want to sign in to (using your account) must support "WebAuthn Conditional UI" [1] AND it must specify:
'User Verification': 'Preferred'
(the latter value, stupidly, is the WebAuthn default; the other options are 'Discouraged' and 'Required').
[1] https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI
In short, "WebAuthn Conditional UI" means that the website ALSO accepts a passkey in case you activate (tap in and see a blinking cursor) the user-ID input field (instead of tapping a button labeled e.g. "Sign in using passkey"). Doing that will invoke iCloud KeyChain and lets you select the right passkey.
Two examples (there are more) of such websites (for free testing purposes) are:
• https://passkeys-demo.appspot.com
• https://webauthn.io
AND, NOTABLY, Apple's production SSO site: https:⧸⧸idmsa.apple.com
Note that your browser is redirected to the idmsa site (in order to SSO to Apple) when you open the bugreport that I filed in June 2023:
• https://security.apple.com/signin?path=reports/OE19476493072
Here's the recipe for passwords:
Ensure that conditions
,
and
mentioned above are met;
Open a website where you have an account with it's credentials saved in iCkoud Keychain. Invoke the log in screen and tap into the user-ID field;
Tap the proposed account name. Now iCloud Keychain autofills your user-ID and passwords into the right fields.
And the recipe for passkeys:
Ensure that conditions
,
, and
mentioned above are met;
Open https://security.apple.com/signin?path=reports/OE19476493072
A box pops up from the bottom of the screen. Tap the X at the top-right to close it.
Tap in the input field "Email or Phone Number", then tap your iCloud ID at the bottom of your screen. Now you will be logged in to Apple without using local auth.
Note that you'll probably see a "403 access denied" error, because (although you HAVE logged in) you are not *authorized* to view te bug report.
This is passwordless 1FA because the possession of the (unlocked) device suffices.
️ Le Passkey di Google migliorano: un unico login per tutti i tuoi dispositivi. Nessuna password da ricordare #Google #Passkey #userfriendly #passwordless
https://blog.google/technology/safety-security/google-passkeys-update-april-2024/
Sicurezza vs Usabilità: il dilemma del mondo #passwordless. Soluzioni come #MFA e #SSO possono migliorare la sicurezza senza frustrare gli utenti. Ma la strada per un mondo senza password è ancora lunga. #cybersecurity #tecnologia
https://www.melamorsicata.it/2024/04/22/vogliamo-un-mondo-password-less/
@nitrokey I fear it will be another decade before we can expect to actually go #passwordless on major websites, but its a good start
I am happy to announce our next #meetup! @deepu105 will tell and show us how to pave the way into a #passwordless future with #passkeys. Register for free via https://www.eventbrite.de/e/a-passwordless-future-tickets-846253606317 #okta #security #java
Why don't Microsoft publish technical details on passwordless? Do we need to wait for a hacker to point out incorrect assumptions?
#passwordless #mfa #microsoft #tpm
I'm trying to manage my Microsoft Account protections, with an ultimate goal of protecting it with a passkey and maybe dropping my password to make the account truly paswordless. However I'm running into some weird idiosyncracies on https://account.live.com/proofs/manage/additional that have prevented me from achieving this:
I couldn't actually see the WebAuthn option at all in the latest macOS Safari - I had to switch to macOS Chrome before the "Windows Hello" option appeared that let me then register an iCloud Keychain-synced passkey.
I removed my phone number as a second factor because SIM jacking is a thing. However the next time I tried to log in I was prompted to add my phone number to "never lose access to your Microsoft account"...but I have other BETTER second-factors configured, so why would I want to continue to allow use of weak SMS OTP? At least I could cancel out and continue on without giving them my phone number again...
Attempting to turn on "Passwordless account" forces you down a path that wants you to set up the Microsoft authenticator app. But I already have a synced passkey in the mix, so why are you bothering with app-based push? Push bombing is also an easy way to get past 2FA protections.
Another example of how the left hand doesn't know what the right hand is doing...
It's been six months — half a year — since Firefox 114 was released with support for FIDO2/WebAuthn. Microsoft 365 support is still broken, particularly for Linux users. You can register a security key but cannot authenticate using it.
Amusingly, Microsoft doesn't even support its Edge browser on Linux.
https://learn.microsoft.com/en-us/entra/identity/authentication/fido2-compatibility#browser-support