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.
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.
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.
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.
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
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.
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.