social.coop

1 post1 participant0 posts today

XenoPhage :verified:Why is it that Home Depot has passkey support and my bank still wants me to answer those three questions?<a href="https://infosec.exchange/tags/security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#security</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://infosec.exchange/tags/FacePalm" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#FacePalm</a>

Suzanne Aldrich (she/her)Critical Next.js Middleware Vulnerability (CVE-2025-29927)A major auth bypass vulnerability in Next.js middleware (prior to v14.2.25 / v15.2.3) allows attackers to inject the x-middleware-subrequest header and bypass authorization entirely. Exploitable via simple HTTP requests—no user interaction, no special permissions.Patch. Now. Or block the header manually.GitHub scored this 9.1 CRITICAL, but the real issue? This flaw exposes a systemic weakness in middleware validation, and some vendors weren’t exactly upfront about the risks.Details + POC: <a href="https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-auth-bypass" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-auth-bypass</a> NVD: <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-29927" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://nvd.nist.gov/vuln/detail/CVE-2025-29927</a>Security theater is easy. Secure defaults and transparency are harder—but essential.<a href="https://hachyderm.io/tags/infosec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#infosec</a> <a href="https://hachyderm.io/tags/AppSec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#AppSec</a> <a href="https://hachyderm.io/tags/NextJS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NextJS</a> <a href="https://hachyderm.io/tags/CVE202529927" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CVE202529927</a> <a href="https://hachyderm.io/tags/middleware" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#middleware</a> <a href="https://hachyderm.io/tags/securityfail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securityfail</a>

Todd A. Jacobs | Pragmatic CybersecurityThis isn't Apple's fault, as it still has to follow local laws to sell its products. However, this is a huge <a href="https://infosec.exchange/tags/securityfail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securityfail</a>.Even though Apple no longer fights for mindshare in the enterprise computing market as it once did, this will force companies that require secure data to either avoid iCloud-enabled apps altogether—which can be hard to do on a Mac—or stop using Macs altogether for anything that processes <a href="https://infosec.exchange/tags/PII" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PII</a>, <a href="https://infosec.exchange/tags/PHI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PHI</a>, or even proprietary <a href="https://infosec.exchange/tags/sourcecode" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#sourcecode</a>. In particular, many <a href="https://infosec.exchange/tags/softwaredevelopers" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#softwaredevelopers</a> prefer <a href="https://infosec.exchange/tags/MacBooks" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MacBooks</a> since they offer a mainstream user experience but run <a href="https://infosec.exchange/tags/Unix" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Unix</a> under the hood. If they can't use MacBooks anymore for security reasons, companies will have to rethink some of their long-standing laptop and desktop <a href="https://infosec.exchange/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cybersecurity</a> practices.<a href="https://www.bbc.com/news/articles/cgj54eq4vejo" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.bbc.com/news/articles/cgj54eq4vejo</a>

Frank FilipponeWas slightly amused earlier today when looking at Task Manager on a Windows server and found a properly ancient version of TeamViewer running on it.Did I mention this server has direct internet access?And is part of the security system for this site?<a href="https://aus.social/tags/it" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#it</a> <a href="https://aus.social/tags/itsecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#itsecurity</a> <a href="https://aus.social/tags/securityfail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securityfail</a>

Dyne.org foundationIn a surprising twist, the very backdoors designed to keep out the badGuys™ were used by the badGuys™. Who could've seen this coming? It's shocking that no one ever warned the clueless legislators behind these backdoors. If only there were some sort of experts they could listen to. 🤦🔓 <a href="https://toot.community/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://toot.community/tags/BackdoorBlunder" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#BackdoorBlunder</a> <a href="https://www.reuters.com/technology/cybersecurity/chinese-hackers-breached-us-court-wiretap-systems-wsj-reports-2024-10-06/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.reuters.com/technology/cybersecurity/chinese-hackers-breached-us-court-wiretap-systems-wsj-reports-2024-10-06/</a>

🅰🅻🅸🅲🅴 (🗑️🔥)I know I'm late to the NPD-bashing party, but the complete disregard for other's privacy they've shown warrants another go at them.The fact that these companies buy, scrape, and steal our data, then compile it into a dox-bomb and secure it behind a "do not breach k thx" high-security post-it note, just fucking riles me.And because it's "publicly available" data, the repercussions of any breach typically amount to having to write a whoopsie apology email and maybe offer an identity scraping—er protection—subscription.It blows my mind that these parasites are legal-ish businesses. They basically provide doxxing as a service.<a href="https://infosec.exchange/tags/NPD" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NPD</a> <a href="https://infosec.exchange/tags/Data" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Data</a> <a href="https://infosec.exchange/tags/Breach" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Breach</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Sevoris<a href="https://conduition.io/coding/ticketmaster/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://conduition.io/coding/ticketmaster/</a>"Quite hilariously, TicketMaster actually makes token-extraction easy on us: The token is logged to the browser console automatically when the barcode renderer component is mounted on the web page."<a href="https://mastodon.social/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://mastodon.social/tags/securitytheater" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securitytheater</a>

QC<a href="https://mastodon.social/@Edent" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@Edent</a> If you call Bank of America, they will verify you using a code sent by SMS that contains, “DO NOT share this Sign In code.” I’ll confirm with the agent that they’re asking for the one that says under no circumstances am I to share with anyone, and they reply cheerfully, “yeah that’s the one.” 🤦‍♂️<a href="https://mastodon.social/tags/bank" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#bank</a> <a href="https://mastodon.social/tags/security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#security</a> <a href="https://mastodon.social/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://mastodon.social/tags/phishing" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#phishing</a>

Asta McCarthy<a href="https://mastodon.nl/@AlmereSP" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@AlmereSP</a> Want USA "publieke"cloud bedrijven zijn echt de enige die veilig een mailserver kunnen draaien :blobfacepalm: <a href="https://arstechnica.com/information-technology/2024/04/microsoft-blamed-for-a-cascade-of-security-failures-in-exchange-breach-report/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://arstechnica.com/information-technology/2024/04/microsoft-blamed-for-a-cascade-of-security-failures-in-exchange-breach-report/</a> <a href="https://mastodon.pirateparty.be/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://mastodon.pirateparty.be/tags/cloud" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cloud</a> <a href="https://mastodon.pirateparty.be/tags/cascadefailures" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cascadefailures</a> <a href="https://mastodon.pirateparty.be/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Andres SI installed <a href="https://social.ridetrans.it/tags/LibreElec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#LibreElec</a> on a pi4. During setup, it asked if I wanted to enable sshd (which, like, *of course* I do).Then it told me the default login and password, and suggested that I change the password. Okay, sure, good idea. I tried a shared, memorable password I use for home appliance devices (NAT'd & only accessible via sudo, as I use ssh keys). "Password too weak", and it didn't allow it. I tried two other passwords, both rejected. So I left it at the default. <a href="https://social.ridetrans.it/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Asta McCarthy<a href="https://mastodon.online/@bartgroothuis" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@bartgroothuis</a> Security by obscurity is een slecht idee. <a href="https://mastodon.pirateparty.be/tags/opensource" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#opensource</a> werken en onafhankelijke code reviews zijn een veel veiligere aanpak. <a href="https://mastodon.pirateparty.be/tags/microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#microsoft</a> <a href="https://mastodon.pirateparty.be/tags/securityfail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securityfail</a>

Emelia 👸🏻This form here transmits your encryption key to Backblaze's servers, but they pinky promise never to use it or store it. <a href="https://hachyderm.io/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://hachyderm.io/tags/Security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Security</a> <a href="https://hachyderm.io/tags/Backblaze" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Backblaze</a>

Emelia 👸🏻I'm trying out Backblaze for backups, and setup an encryption key. Turns out if you ever use the “View/Restore Files" feature on their website, they send the full encryption key to their remote server.Which completely and absolutely defeats the point of the encryption key, because now they have a copy of the encryption key.<a href="https://hachyderm.io/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://hachyderm.io/tags/Security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Security</a> <a href="https://hachyderm.io/tags/Backblaze" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Backblaze</a>

Fraser Smith🏴󠁧󠁢󠁳󠁣󠁴󠁿This morning I checked my email and there was a standard name change email from Discord for a user name that I never created, to a variation of my gmail address that I have never used.As I never use Discord these days, I instigated a password change for that gmail variation, changed the password and logged in. Sure enough, here was a Discord account that I had never created. It hadn't joined any servers, indeed it looked as if it had never had any activity, so I deleted it. For good measure, I logged in again with my main Discord login (the one I rarely use) and deleted that too. I doubt I'll miss it.I'm not sure what happened (or when it happened) but I really don't know how somebody could create an account without email verification.<a href="https://octodon.social/tags/Discord" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Discord</a> <a href="https://octodon.social/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://octodon.social/tags/SecurityFailure" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFailure</a> <a href="https://octodon.social/tags/IdTheft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#IdTheft</a>

C.Bank emails: Never click links in emails claiming to be from us, your bank! It's not safe.Also Bank emails: To complete this transaction, click this link.<a href="https://mindly.social/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://mindly.social/tags/security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#security</a> <a href="https://mindly.social/tags/fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#fail</a> <a href="https://mindly.social/tags/stupidity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#stupidity</a> <a href="https://mindly.social/tags/idiocy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#idiocy</a> <a href="https://mindly.social/tags/email" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#email</a> <a href="https://mindly.social/tags/scam" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#scam</a>

Claudius LinkMoving on to <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> <a href="https://infosec.exchange/tags/Guidance" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Guidance</a> in generalMicrosoft offers the following Password Guidance <a href="https://www.microsoft.com/en-us/research/publication/password-guidance/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.microsoft.com/en-us/research/publication/password-guidance/</a>Side note, the PDF contains no (visible) version information or date :-( Please, if you publish guidance, especially if you are an influential company, include a date in your documents. I treat a guidance form 2016 differently than a guidance from 2023Back to the recommendations. Most of the are solid but some stick out1. Maintain an 8-character minimumThat seem awfully short. <a href="https://infosec.exchange/tags/NIST" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NIST</a> states "Longer is better", the <a href="https://infosec.exchange/tags/HPI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#HPI</a> recommends 15+ characters and, wait for it, Microsoft themself recommends 12 or better 14+ characters.4. Ban common passwords, to keep the most vulnerable passwords out of your system.The <a href="https://infosec.exchange/tags/NIST" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NIST</a> recommendation check against "commonly used and compromised passwords" considerably extends this!Microsoft at other places recommends "Not a word that can be found in a dictionary or the name of a person, character, product, or organization."5. Educate your users not to re-use their password for non-work-related purposes.Work related reuse is OK????I would love to know if <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> internally really follows these password rule. Or if they enforce a stricter set. If anyone knows about this, please let me know (but don't if this would get you fired)BTW, the other place where Microsoft recommends a different/stronger set of password rules is here (again no date): <a href="https://support.microsoft.com/en-us/windows/create-and-use-strong-passwords-c5cebb49-8c53-4f5e-2bc4-fe357ca048eb" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://support.microsoft.com/en-us/windows/create-and-use-strong-passwords-c5cebb49-8c53-4f5e-2bc4-fe357ca048eb</a><a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Claudius LinkSome more context to my rant about the shortcomings of <a href="https://infosec.exchange/tags/EntraID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#EntraID</a> <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Protection:1. The risk is greatly reduced if you use <a href="https://infosec.exchange/tags/MFA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MFA</a> BUT while I'm not sure if <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> enforces MFA they enforce the weak password rules. And a recent event caused me to reevaluate my assumption on how well know <a href="https://infosec.exchange/tags/2FA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#2FA</a>/MFA really is:I gave <a href="https://infosec.exchange/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cybersecurity</a> talk to non-IT people (still technical so) and closed it with a set of recommendation. One was to enable Second Factor Authentication wherever possible. Which lead to the question from one participant "What is Second Factor Authentication"That was quite a 😵 moment. I had the wrong assumptions. How can I assume that MFA reduces a risk if many people don't know about it.<a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Claudius LinkOne more thingAnother shortcoming of <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://infosec.exchange/tags/EntraID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#EntraID</a> <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Protection, I can't wrap my head around:They recommend to not mandate regular password changes (good) BUT they check the password against known bad passwords ONLY when changing it!So, to detect weak passwords I have to enforce a password change which is (rightfully) not recommended 🤡You could simply do this on entry. Every time (or once a day) the user enters the password it is checked if it isn't well known and complies to the current rules.<a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Claudius LinkSleeping over it I noticed another issue with <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://infosec.exchange/tags/Entra" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Entra</a> ID <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Regarding the Global banned password list they write "The contents of the global banned password list aren't based on any external data source, but on the results of Microsoft Entra security telemetry and analysis." (<a href="https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad</a>)Now I have more questions:WHY are passwords part of the security telemetry data?The only case where I see this as ok, would be in a honeypot.And what kind of data would be in the security telemetry data? Usually it's failed attempts, so you risk overestimating passwords attacks which fail (anyway). Again, this would only be OK with honeypots.But if you are getting your data solely from honeypots, I fear you're getting a pre-selected type of data. Namely opportunistic, random attacks not targeted attacks.While I think it's valuable to protect against these kind ob attacks, I really would like passwords to withstand even targeted attacks, even from the inside. E.g when the attackers are in the Lateral Movement or Privilege Escalation. Especially if the attackers can start to crack hashes.For this Microsoft Entra ID Password Protection seems completely useless there.<a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Claudius LinkAnd the Custom banned password list of <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://infosec.exchange/tags/EntraID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#EntraID</a> <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Protection just continues the joke.First, it can only contain 1000 entries. And yes, I really don't want to manage a big custom list.And it gets even worse. The list is intended to contain company specific banned words like brand or product names, company-specific internal terms as well as abbreviations. Entries must be at least 4 characters. WTF, half the companies I worked for had 3 letter names. And there are many other BWM, KIA, SAP, IBM, GM, BBC, NBA, NFL, UPS, DHL, ...And don't get me started on acronyms. <a href="https://infosec.exchange/tags/TLA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TLA</a> (Three-Letter-Acronym) is a term for a reason.This means, taking my current company as an example, that SMA12 would be an accepted password (if it would be for the length) because 'SMA' 3 points + '12' 2 points is 5 points).To reach the necessary length you could simply combine it. E.g. 'SMASolar1' would be an accepted password even if 'Solar' was a banned word.And I CAN'T do ANYTHING!!!Or at least not anything sensible. If I start to put combinations of 'SMA*' in the custom banned pw list, I'm back at an inadequate big list I have to manage myself 🤮.And even then SMASolar1234 stays valid 🤬 <a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> Call for <a href="https://infosec.exchange/tags/Help" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Help</a>: I would be very happy if someone can show me that I'm wrong. The state of Microsoft Entra ID Password Protection is a MUCH bigger pain than that I would have been wrong 😜.

Recent searches

Search options

Administered by:

Server stats:

#securityfail