different_sort

That is indeed the case.

Untrue, any valid access key pair set can call “GetSignInToken” and access the aws console.

Maybe I’m just an unimpressed security professional but I’ve still not seen evidence I’d call a breach. At least not a significant one if you want to argue sublantics.

Workers at organizations get compromised all the time. This doesn’t mean their systems/products are compromised.

The screenshots on the linked tweet make it look like okta dog foods their own product for access to various services and someone has access to one of their admin accounts. Which is bad, but that could mean “we phished this one person who works at okta” and not “we compromised okta and have unfettered access to their customers/valuable assets”.

The news of the coming days may well prove me wrong, but i am not assuming the worst from this yet. Many companies whether or not they use an idaas do things like login anomalie detecting, and users coming in from weird locations and weird times of day would be sure to set of alarm bells at some of the big targets. Heck, AWS does it for customers with guard duty.

AWS Backup does exist.

Implicit grant is depecrated, in the forthcoming OAuth 2.1 [1] standard this is solidified.

We start using the language "public client" and "private client", where a public client is an OAuth client like a mobile app or SPA that does not have a client secret, but has an access token delegated to it(+optional refresh token). Public clients must use implicit+PKCE.

Private clients are what we would have previously thought of as an Authorization code grant client where a server process has an access token to take actions on behalf of a user.

Depending on the OAuth use case, maintainers of the system may need to keep track of what clients are public or private, and limit their entitlements accordingly.

Public clients have the obvious issue that they're on an end-user device and thus the tokens may be stolen, proposed standards like JWT DPOP [2] and token binding [3] aim to address this.

[1] https://oauth.net/2.1/

[2] https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

[3] https://tools.ietf.org/html/rfc8471 . Though I should say token binding does seem like it will never go anywhere.

This space is insane and hard to keep up with.

I'm glad adblockers are back. I'm not sure if it ever truly left, but the moment there was a bit of resistance I was happy to jump ship to FF.

That is definitely not lost on me. Life imitates art.

Job Role/Further details are risky to discuss because this forum is read by my colleagues and likely the nerdier execs. I could leave it at I am someone very senior and actively involved in trying to tackle our problem, so I see the efforts and the challenge first hand.

I can tell you that execs are very aware of the problem. Higher ups have spoken about it at townhalls, though they use softer language than I do. Since 2017 a lot of modernization attempts have been made(go cloud, use standards, use off the shelf software as much as possible), with very little to show for it so far.

Obviously it isn't all just tech that causes this, culture has a big part to do with it.

It feels like the scenario in the phoenix project almost, it'd be funny if it wasn't so serious.

I think it represented poorly. It's more than just code in one system. It's systems built upon systems built upon systems. It encompasses our network, our software deployment stack, our proprietary extensions to standards and much much more. Unknown dependencies on unknown dependencies on unknown dependencies (and it's not like we're slacking on trying to map that/keep the asset inventory up to date).

It's basically paralyzing. It's so hard to get a release done, add capacity, or add new features for our lines of business (we have dozens!).

I work in an huge enterprise. We have incredibly customized software and stacks that have not changed much for 30 years, because they did not need to.

Now the people who wrote those stacks and who understand them are retiring/quitting. Kids coming out of school don't want to learn these systems, nor do people off the streets. You can only pay people to come out of retirement so many times to keep the plant running. This is above and beyond mainframes, and is intertwined deep in the code that powers every single application that runs the plant today.

We can't run off the shelf software on-prem, a huge level of customization is needed to bring it in.

We cannot pivot quickly to new things or support new languages.

We really struggle to add new features/releases and add new software to drive revenue. The IT overhead that just goes into keeping the plant running every day is astounding.

This is what I think of when I hear technical debt.

Going down this road did give us advantages for a long time, but now we're in an enormous crisis. It's not an insurmountable challenge, but I would be surprised if there aren't a lot of large companies who are brought down by their technical debt as faster moving competitors move around them. I certainly feel that unless we get our act together, we will be disrupted.

That's a great example, thank you for sharing it.

I actually have never seen it's kubernetes security platform.

If it's using RQL for that I would take that as a redflag that it won't support much customization or logic that would allow you to tailor it to your organization.

Prisma cloud (the cloud monitoring part) is not a great product. It lags pretty far behind cloud provider capabilities.

I also got the email that orca probably sent to everyone in their CRM about this, and while I didn’t need any reason to think less of prisma, I now associate Orca as a competitor and probably an earlier call than palo alto for cloud.

You're responsible for managing the server in beanstalk, but it's not far off. I suppose it's just an earlier generation of the same idea. WHat I mean is, beanstalk runs on EC2 instances that you are responsible to make sure are patched, configured correctly and have everything you need for your application to run.

Fargate/Cloud Run are probably better serverless examples - you bring a container and config and the cloud provider will handle the rest.

"You Can't Run Entire Applications".

I mean, what are we really calling serverless. Many serverless platforms, like fargate allow you to bring a container image, and whatever happens in that container image is non of fargate's business.

I agree with many of the points made though, and admit I am writing this reply mostly because the ckick baity headline got me.

Bit, bite? I see what you did there

This was a great read, thank you for sharing. I deal with identity and federation problems all day at work because I am one of those annoying enterprise customers.

We’re just getting our external openid connect capability enabled and I’m excited to start getting everything moved over. We’re also moving all our internal apps over to openid connect for auth as well, exciting times.

Where in Canada is socializing banned?

I love how you're using workers there. I've been on workers for years (only for static content mind you) and it's super cool.

Hashicorp vault? You probably have more secrets than SSH to protect.

If you’re on AWS also consider high value add built ins like EC2 instance connect or ssm session manager so you can manage host access via IAM.

I saw ssh keys and was ready to get on my moral high horse about ssh certs, only to read the article to be talked down. Nice guide!

This is neat, thank you for sharing.

I'm using the publii default theme on my website and it ranks quite high. It said to get an even higher ranking I should consider denser content, which makes sense given I just moved to publii and it's a bit light right now.

Thank you for your replies and insight, it's really appreciated.

The way I see it with SPA and tokens in JS accessible space is that you're exposing your users to the possibility of token theft and user impersonation if someone is able pull off an XSS. This is not so different than using a session cookie that is not marked as 'httponly'. What's old is new again :)

I have also heard the argument that we shouldn't worry about token theft, because it's already too late if you're XSS'd, but I don't buy into that rhetoric(not saying XSS isn't incredibly bad).

Unfortunately I work in financial services, so we can't just skate by and assume that we're so uninteresting that an adversary with advanced capabilities wouldn't look to exploit our external or internal users somehow.

One another thing we're looking into is access tokens, like having the user re-authenticate or use a stronger factor(or multiple) to get the AS to grant them a very short lived, non-refreshable token to do their sensitive operation.

I'm going to check out the fusionauth blog for a bit more inspiration, if you're interested in continuing this discussion I would be interested in carrying it on.

Storing tokens in cookies would be against the spec wouldn’t it? I’m not putting rfc6749 on some sort of pedestal, but it clearly states that the tokens are in the response body and not set in cookies.

Do you have any examples of Authorization servers in the wild doing this or front end SDKs that work with that?

I’m very curious, I’m doing an SPA security research project at work and I’m very interested in these stories and learning more.

I’ve seen some folks do refresh in an httponly cookie, and Access in the js space. I’ve seen another example (auth0) put the refresh token in a web worker and access token accessible in js.

And I’ve seen things like msal.js just say F it and make them all accessible to js.

Could you indulge me with any details? Not AWS or someone who works on k8s, I'm just always interested in war stories, and cloud providers "not working" is an interest too.

Reminder it's time to get off 1.16 now. Only 3 versions (current-2) are supported upstream.

https://kubernetes.io/docs/setup/release/version-skew-policy...

What are the 'obvious privacy reasons' to not use google DNS/NTP?

I am being 100% serious when I ask: What bad does someone expect to happen as a result of this.

big exhale Woah.

Thank you for your reply!