The blog post details a sophisticated, low-and-slow password spray attack targeting Microsoft 365 accounts. Instead of rapid, easily detected attempts, the attackers used a large botnet to try a small number of common passwords against a massive list of usernames, cycling through different IP addresses and spreading attempts over weeks or months. This approach evaded typical rate-limiting security measures. The attack was discovered through unusual authentication patterns showing a high failure rate with specific common passwords across many accounts. The post emphasizes the importance of strong, unique passwords, multi-factor authentication, and robust monitoring to detect such subtle attacks.
The popular GitHub Action tj-actions/changed-files was compromised and used to inject malicious code into projects that utilized it. The attacker gained access to the action's repository and added code that exfiltrated environment variables, secrets, and other sensitive information during workflow runs. This action, used by over 23,000 repositories, became a supply chain vulnerability, potentially affecting numerous downstream projects. The maintainers have since regained control and removed the malicious code, but users are urged to review their workflows and rotate any potentially compromised secrets.
Hacker News users discussed the implications of the tj-actions/changed-files compromise, focusing on the surprising longevity of the vulnerability (2 years) and the potential impact on the 23,000+ repositories using it. Several commenters questioned the security practices of relying on third-party GitHub Actions without thorough vetting, emphasizing the need for auditing dependencies and using pinned versions. The ease with which a seemingly innocuous action could be compromised highlighted the broader security risks within the software supply chain. Some users pointed out the irony of a security-focused action being the source of vulnerability, while others discussed the challenges of maintaining open-source projects and the pressure to keep dependencies updated. A few commenters also suggested alternative approaches for achieving similar functionality without relying on third-party actions.
Azure API Connections, while offering convenient integration between services, pose a significant security risk due to their over-permissive default configurations. The post demonstrates how easily a compromised low-privilege Azure account can exploit these broadly scoped permissions to escalate access and extract sensitive data, including secrets from linked Key Vaults and other connected services. Essentially, API Connections grant access not just to the specified API, but often to the entire underlying identity of the connected resource, allowing malicious actors to potentially take control of significant portions of an Azure environment. The article highlights the urgent need for administrators to meticulously review and restrict API Connection permissions to the absolute minimum required, emphasizing the principle of least privilege.
Hacker News users discussed the security implications of Azure API Connections, largely agreeing with the article's premise that they represent a significant attack surface. Several commenters highlighted the complexity of managing permissions and the potential for accidental data exposure due to overly permissive settings. The lack of granular control over data access within an API Connection was a recurring concern. Some users shared anecdotal experiences of encountering similar security issues in Azure, while others suggested alternative approaches like using managed identities or service principals for more secure resource access. The overall sentiment leaned toward caution when using API Connections, urging developers to carefully consider the security implications and explore safer alternatives.
Despite being a simple, beneficial, and standardized way for security researchers to report vulnerabilities, adoption of security.txt files (as defined by RFC 9116) remains disappointingly low. A 2025 study by Hartwork found that the vast majority of IT companies, including many prominent names, still do not provide a security.txt file on their websites. This lack of adoption hinders responsible vulnerability disclosure and potentially leaves these organizations more susceptible to exploitation, as researchers lack clear reporting channels. The study emphasizes the continued need for greater awareness and adoption of this straightforward security best practice.
Hacker News users generally agreed with the premise that security.txt adoption is disappointingly low, with several expressing frustration at the security industry's failure to implement basic best practices. Some commenters pointed out that even security-focused companies often lack a security.txt file, highlighting a general apathy or ignorance towards the standard. Others discussed the potential downsides of security.txt, such as increased exposure to automated vulnerability scanning and the possibility of it becoming a target for social engineering attacks. A few suggested that the lack of adoption might stem from the perceived lack of clear benefits or fear of legal repercussions for disclosed vulnerabilities. The overall sentiment reflects a concern for the slow uptake of a seemingly simple yet beneficial security measure.
CSRF and CORS address distinct web security risks and therefore both are necessary. CSRF (Cross-Site Request Forgery) protects against malicious sites tricking a user's browser into making unintended requests to a trusted site where the user is already authenticated. This is achieved through tokens that verify the request originated from the trusted site itself. CORS (Cross-Origin Resource Sharing), on the other hand, dictates which external sites are permitted to access resources from a particular server, focusing on protecting the server itself from unauthorized access by scripts running on other origins. While they both deal with cross-site interactions, CSRF prevents malicious exploitation of a user's existing session, while CORS restricts access to the server's resources in the first place.
Hacker News users discussed the nuances of CSRF and CORS, pointing out that while they both address security concerns related to cross-origin requests, they protect against different threats. Several commenters emphasized that CORS primarily protects the server from unauthorized access by other origins, controlled by the server itself. CSRF, on the other hand, protects users from malicious sites exploiting their existing authenticated sessions on another site, controlled by the user's browser. One commenter offered a clear analogy: CORS is like a bouncer at a club deciding who can enter, while CSRF protection is like checking someone's ID to make sure they're not using a stolen membership card. The discussion also touched upon the practical differences in implementation, like preflight requests in CORS and the use of tokens in CSRF prevention. Some comments questioned the clarity of the original blog post's title, suggesting it might confuse the two distinct mechanisms.
The Okta bcrypt incident highlights crucial API design flaws that allowed attackers to bypass account lockout mechanisms. By accepting hashed passwords directly, Okta's API inadvertently circumvented its own security measures. This emphasizes the danger of exposing low-level cryptographic primitives in APIs, as it creates attack vectors that developers might not anticipate. The post advocates for abstracting away such complexities, forcing users to interact with higher-level authentication flows that enforce intended security policies, like lockout mechanisms and rate limiting. This abstraction simplifies security reasoning and reduces the potential for bypasses by ensuring all authentication attempts are subject to consistent security controls, regardless of how the password is presented.
Several commenters on Hacker News praised the original post for its clear explanation of the Okta bcrypt incident and the proposed solutions. Some highlighted the importance of designing APIs that enforce correct usage and prevent accidental misuse, particularly with security-sensitive operations like password hashing. The discussion touched on the tradeoffs between API simplicity and robustness, with some arguing for more opinionated APIs that guide developers towards best practices. Others shared similar experiences with poorly designed APIs leading to security vulnerabilities. A few commenters also questioned Okta's specific implementation choices and debated the merits of different hashing algorithms. Overall, the comments reflected a general agreement with the author's points about the need for more thoughtful API design to prevent similar incidents in the future.
Summary of Comments ( 15 )
https://news.ycombinator.com/item?id=43512944
HN users discussed the practicality of the password spraying attack described in the article, questioning its effectiveness against organizations with robust security measures like rate limiting, account lockouts, and multi-factor authentication. Some commenters highlighted the importance of educating users about password hygiene and the need for strong, unique passwords. Others pointed out that the attack's "slow and steady" nature, while evasive, could be detected through careful log analysis and anomaly detection systems. The discussion also touched on the ethical implications of penetration testing and the responsibility of security researchers to disclose vulnerabilities responsibly. Several users shared personal anecdotes about encountering similar attacks and the challenges in mitigating them. Finally, some commenters expressed skepticism about the novelty of the attack, suggesting that it was a well-known technique and not a groundbreaking discovery.
The Hacker News post titled "Unmasking a slow and steady password spray attack" (linking to a Petra Security Substack article) generated a moderate number of comments, primarily focusing on the technical aspects and implications of the described attack.
Several commenters discussed the effectiveness and practicality of the described attack method. Some expressed skepticism about its widespread applicability, highlighting that the specific vulnerability exploited (allowing unlimited login attempts without lockout) is becoming increasingly rare due to improved security practices. They pointed out that many modern systems implement robust rate-limiting and account lockout mechanisms, making such slow and steady password spraying significantly less effective.
Others acknowledged the potential danger, particularly in environments where security practices are less mature. They noted that legacy systems or organizations with inadequate security configurations could still be vulnerable to this type of attack. There was some debate around the trade-offs between security and usability, with some suggesting that overly aggressive lockout policies can negatively impact legitimate users.
A few commenters delved into the technical details of the attack, discussing methods for detection and mitigation. They mentioned techniques like analyzing login logs for suspicious patterns, implementing multi-factor authentication, and using honeypot accounts to trap attackers. The use of threat intelligence feeds to identify commonly used passwords and block them proactively was also suggested.
Some comments focused on the attacker's persistence and methodology. The slow and steady nature of the attack, designed to evade detection, was highlighted as a key characteristic. The discussion also touched upon the resources and infrastructure required by the attackers to execute such campaigns, suggesting that they might be more sophisticated than initially assumed.
Finally, there was a brief discussion about the broader implications of this type of attack, including the potential damage to reputation and financial losses for affected organizations. The importance of proactive security measures and ongoing vigilance was emphasized as a key takeaway.