ptcrash

Happy to see the effort! Fresh blood in the authn space is always welcomed.

Without rehashing the other good points commenters have made already, I’ll just say that every project starts out immature. What makes a project great is how willing the maintainers will be to grow along with the project and incorporate feedback. I’m excited to see future evolutions of this one.

I think it's more of a logic problem. I suspect the engineers made a false assumption that bcrypt can hash a trivial amount of data like some other hashing algos.

If you want to validate a username/password authn attempt against a cache, then yes the username and password have to be someone in the mix.

Yes but PIV/CAC identity is not related to break-glass passwords. They both serve different purposes and it's safe to assume that the typical government worker will only ever need to use their smart card to authenticate into systems.

Ignoring obvious flame-bait, it sounds like the termination was an amicable feeling then, yeah?

Would you care to share for those of us who haven’t written a grant application before?

Both situations seem possible. I guess time will tell how Unity wants to move forward.

Others mentioned it earlier but it looks like Godot had a big boost in users from this fiasco. Perhaps Unity is concerned about real financial damages done to their bottom line because of all this? I’d expect them to try a lot of stuff and see what sticks to make sure they don’t miss their targets this year.

Well, the transition in leadership is uncommon but they don’t officially give us a reason, so we’re left to speculate until someone inside gives us more info.

But from a purely speculative standpoint, it seems very possible that they were ousted because of the pricing debacle. I could see a world where the stakeholders aren’t thrilled with the damage the pricing changes did to their brand and took action.

Non-paywall link: https://web.archive.org/web/20221215195859/https://www.washi...

Same here. I also switch to light mode when I'm in a very bright environment and it seems to have helped a lot with eye strain since last year. I feel like these studies are being a bit 1-dimensional... but then again, maybe that's my own confirmation bias.

I'd argue it's because the risk is not worth the reward. Pingback and Trackback is used to send a monsoon of spam and I'd wager site maintainers are not too keen on enabling the new version of an old problem.

I've read through the spec along with the FAQ that epeus so graciously shared here. The idea of mentioning beyond the scope of one website's walled garden seems like a very natural progression of ActivityPub and the new-found hype surrounding Mastodon. My concern is that I haven't seen much thought into the security implications.

The spec makes it clear that they're trying to simplify pingbacks but they don't address the fundamental security problems with pingbacks in the first place. And anyone who's maintained a Wordpress site will tell you, the first thing you do is turn off the Trackback and Pingback features [1] because not only does it attract the scummiest deluge of spam [2] but they've also been useful for disclosing internal network info and [3] leveraged to target other websites in DDoS attacks. [4]

The only thought given to preventing abuse is as follows from Section 4.1:

>The verification process SHOULD be queued and processed asynchronously to prevent DoS attacks per section 3.2.

>Receivers MUST verify Webmentions per section 3.2.2.

The first directive isn't a guarantee a DoS attack won't block all IO, it just means don't make it trivial to bring a site down with webmentions. The second directive sounds nice but if you read through section 3.2.2 of the recommendation, it just mandates that you should validate the application data that's submitted. [5] There's no mechanism to authenticate messages, validate the sender, nor limit mentions to a set of trusted parties.

Am I missing something or is this recommendation just splitting the pingback feature from the XML-RPC protocol? In my opinion, that's not providing a lot of value because the feature is still so very easy to abuse.

[1] https://www.wpbeginner.com/beginners-guide/what-why-and-how-...

[2] https://blog.hubspot.com/website/trackback-spam

[3] https://www.acunetix.com/vulnerabilities/web/wordpress-pingb...

[4] https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b...

[5] https://www.w3.org/TR/webmention/#h-webmention-verification

Is this a new iteration in fail2ban? I gave it a cursory look and I couldn’t find any new features that make it a better tool than its predecessor

It's not just arcane it's a horrible idea from an infosec perspective. Thinking about all my wonderful developers having local trusted root CAs just sitting on their hard drives is making my blood pressure skyrocket.

I didn’t know what NeRFs were so I had to look it up. This article seems like a good introduction for anyone else that’s out of the loop like me: https://www.matthewtancik.com/nerf

I think it's neat to see company's like VMWare try to amalgamate containerization into their portfolio. Tanzu is like all the cons of on-prem like inelasticity applied to K8s

I don't have an easy answer for you because I'm still struggling to find the "proper" solution myself. That's why I'd kill to have the agencies weigh in.

I'm not a fan of SealedSecrets or managing secrets in-code at all because of this scenario: Secret rotation requires pushing updated code which may take too much time in a compromised situation. Ie, I don't want to hinder secret rotation with CI tests and merge approvals when there's an active incident triage - I want to kill the pwned secret with fire and get a fresh secret in there ASAP.

I've gotten better results by treating secrets as state instead of infrastructure... Like, by coupling your pod to a secret vending service like Vault or Secrets Manager, you can remove potential for programmers to introduce anti-patterns that weaken our posture.

The benefit is that we can keep things encrypted, auto-rotate things behind the scenes, remove the chance of developers to have even an encrypted copy of secrets, and we can get better turn-around on IRs when secrets inevitably get leaked. And, you can still write out the secret as IaC.

To mitigate the potential for single-points of failure when the secrets service goes down is to allow for secret caching client side. Vault and AWS Secrets Manager, which are the only services I can vouch for, both have client-side caching capabilities.

Take that with a grain of salt. I admit, I'm opinionated

The guideline was updated this month but released last year. That dupe link probably has a lot of relevant discussion.

One of the most common misconfigurations I've seen is improper secrets handling. I'm glad to see it called out but I wish they would go into a little deeper detail on detection and remediation. Overall looks pretty good! I'm excited to have some baselines for K8s.

Yes. While many agencies have a bad reputation post-Snowden, CISA and NSA have for many years - and will continue to release hardening guides that are invaluable to security engineers.

That's enlightening; thanks. Hopefully the steps forward for determining scope and affected objects is easy

Okay, opinions up front: I don't think this is worthy of "declaring a security incident. Having some experience working behind the scenes, just because this policy was changes this way doesn't mean "All AWS Support personnel had unrequited access to your S3 objects." To me, this reads as Twitter inflammatory nonsense. Here's why:

* KMS Encrypted objects would not be accessible because the support personnel would need permission policies that grant `kms:decrypot` permissions to encrypted objects. The only way this could wind up happening is if you are granting the AWS Support principal access in the KMS Key Policy.

* Objects with a default-deny bucket policy could not have been circumvented with the support team's escalated privilege. So if you have a policy that looks something like this, that data was not exposed:

{

  "Action": "Deny",

  "NotPrincipal": [...]

}

* Internal Checks. AWS has a lot of protections and checks in place to prevent their support personnel from accessing metadata about S3 objects. They don't have tools to fetch the actual objects unless your really high up the food-chain. Think like, people with a legal or security related reason to need to review data.

Nevertheless, I'll share some nuggets of wisdom I've accrued over the years, in a hopes to save y'all some time:

If you have an NDA with AWS, I'd recommend reaching out to your TAM and asking them about what the potential exposure was; and make sure to ask about the internal access control mechanisms.

But everyone who's concerned and DIDN'T set up data access logging already: 1) Consider turning that on to trace potential disclosures in the future. 2) Open up a case with Premium Support under the CloudTrail, state that you have a security incident and you need to retrieve data events for the time of 2021-12-23 to 2021-12-22. If granted to you, save that sucker in S3 and query it for requests coming from `support.amazonaws.com` in Athena. [0]

Hopefully this helps some of y'all.

[0] https://aws.amazon.com/premiumsupport/knowledge-center/analy...

Having some authority on the subject because I've seen how both GCP and AWS handle their public status pages internally. They are manually updated by hand and are the last step in raising a large-scale issue.

Automated issue notifications get pushed to the Personal Health Dashboard for AWS and to my knowledge, GCP doesn't have automated status updates available to customer. (But AWS requires a support plan to gain access to their PHD, so it can be considered inaccessible to many as well).

When did AWS lie? On their status page? That's the last place to receive updates on service status. It sucks but it's also common knowledge. I'll give you a little insider knowledge: The SHD is updated manually. If it's any consolation, GCP does the exact same thing.

I saw notifications in the AWS Personal Health Dashboard pretty very early into the issue. Did you see something different?

Also, I've seen issues logging into the default console a lot, so I keep one of the backup endpoints bookmarked. Might come in handy for you too!

https://us-east-2.console.aws.amazon.com/

Let's try to remember the guidelines, be kind, and have curious conversation. Hacker News isn't the place for baseless speculation and generalization.

AWS publishes postmortems for major outages here: [1]

This outage was significant enough to expect a public PES but it's typical for it to take at least a few weeks for that page to get updated. At least, that's been the trend for all previous publications. If the PES is anything like previous PESes, it will have a detailed explanation of the root-cause and an explanation of what will change to prevent the issue from happening again but it will still be technologically abstract because cloud providers are very secretive of how they orchestrate resources behind the scenes. Enterprise-tier support customers can ask for RCA's but as I understand it, the account managers don't have any official wording internally yet either. But, it's only been 48 hours, so something of this significance will likely have a large chain of sign-offs it has to go through before official wording is announced.

This type of quietness from AWS before their official wording gets published is standard practice for them. They have a large legal team, PR team, and executive team that will all be interested in controlling the narrative but that's not uncommon for other large companies either.

If I were to take a stab in the dark, I'd say we'll see a PES in ~2 weeks. Maybe sooner, maybe later. If they don't announce a PES, I'll be really shocked because last year's Kinesis outage had arguably smaller impact but ended up getting a publication. [2]

[1] https://aws.amazon.com/premiumsupport/technology/pes/

[2] https://aws.amazon.com/message/11201/

Edit: Typos