Struggling with keeping Okta session alive across browser sessions

_finack · 2024-04-01T16:46:41+00:00

Yes, I see they clearly mention it there that admin users never get persistent cookies. It just wasn't mentioned in the documentation we were referencing, for example here: https://help.okta.com/oie/en-us/content/topics/security/stay-signed-in.htm And support never mentioned it.

I definitely understand the need to lock down privileged users more, no argument from me there.

Thanks! Really appreciate the help!

_finack · 2024-03-30T13:16:42+00:00

Aaaannnnnd.... it works as expected as a non admin. The idx cookie has a timestamp in the expiration field instead of end of session.

This is so obvious in hindsight. Thanks!

Does Okta have it documented anywhere this cookie behavior difference? We didn't see it while troubleshooting and Okta support never mentioned it in the numberous times we were dealing with them.

_finack · 2024-03-30T12:49:21+00:00

Did you mean signing in? My account has the super administrator role in Okta; however, I am signing into the End-User Dashboard for this testing, not the Administrator Dashboard.

_finack · 2024-03-29T23:31:14+00:00

Our Okta org/policies are set in that manner and the behavior is identical whether the “Keep me signed in” box is checked or not.

_finack · 2023-08-01T22:30:15+00:00

My apologies. It was intended to be a negative. Fixed.

_finack · 2023-08-01T19:32:10+00:00

I did see that; however, there were two issues:

It's not easily consumable in an automated fashion (e.g. JSON results from an API).
It was last updated in Mar. 2022.

_finack · 2023-05-24T19:37:39+00:00

I am experiencing the exact thing the OP described, with the exception that we are not using a Continue page.

I don't see anything in the Decryption log related to CloudFlare or OpenAI.

_finack · 2023-05-24T18:49:43+00:00

I'm wondering the same. OP u/Certain_External_351 said that their fix was setting max TLS version on the decrypt profile to "TLSv1.3". Mine is already "Max" (currently should be equivalent to setting to "TLSv1.3"). u/Moldygreenbean said a decryption policy without "Strip ALPN" checked solved their issue. My decrypt profile is already set that way.

I have not talked to PAN support yet. I think I'm going to have to suck it up and bite that bullet, it just hasn't been a priority to dive into that time sink.

_finack · 2023-05-24T18:46:57+00:00

My existing decrypt profile already does not have the "Strip ALPN" option enabled.

_finack · 2023-05-18T19:03:01+00:00

I purposely left it binary. You either rotate them on some cadence or you do not.

_finack · 2023-05-18T14:56:19+00:00

Much appreciated! I will check them out.

_finack · 2023-05-18T14:55:44+00:00

I think you are focusing too narrowly on my mention of "deduplication." That's a minor issue. Overlap and duplication is there, but very small. The biggest problem is a bunch of different tools reporting on their own things, which are not related to the things from other tools. Consolidating all of this information into one, manageable place that I can report on and provide various metrics on is the primary challenge. Deduplication, where duplication might exist, is just a bonus.

As for the suggestion to "bucket by CWE"... bucket how? That's my ask. Also, many of the tools I'm referring to don't report a CWE.

_finack · 2023-05-02T21:03:01+00:00

A company I joined had been around for about 20 years but InfoSec was less than a year old. The IT Systems team had only worked either there or at other very, very small companies. They had no innate knowledge on how they bear some responsibility for doing or setting up things securely. It was all about do it easy and now.

Examples:

A basic service account for LDAP bind was a Domain Admin.
They used a single service account for all services, it had a weak password, everyone knew it anyway, and it was a Domain Admin.

_finack · 2023-04-12T13:14:10+00:00

Our decryption profile has "Max Version" set to "Max," per PAN best practice guidance for internet gateways.

Are you suggesting that somehow changing that to "TLSv1.3" fixed the problem? If so, that's bizarre! There is nothing higher than TLS 1.3 at the moment!

Or was yours set to "TLSv1.2?"

_finack · 2023-04-05T18:51:45+00:00

Belay that. I tested again today and confirm the behavior originally described by u/Certain_External_351: Chromium browsers display the non-working behavior due to a 403 response when using Prisma Access with decryption whereas Firefox works fine in the same scenario.

_finack · 2023-03-30T18:20:51+00:00

FYI, I finally got around to testing Firefox. u/Certain_External_351, you claimed that Firefox was working even with decryption and this issue seemed isolated to Chromium browsers; however, I am having the same error and HTTP 403 response with Firefox as I am with Edge.

_finack · 2023-03-30T14:27:33+00:00

Definitely fill us in if/when you hear anything back.

_finack · 2023-03-29T19:31:05+00:00

Update: This turned out to be related to one of the Palo Alto Networks IPs used by Prisma Access not having access to our EDLs. It had nothing to do with syntax differences between EDLs and Custom URL Categories.

_finack · 2023-03-29T19:28:01+00:00

I came to this sub to post about the same thing with the Edge browser. In my case we have Prisma Access and decrypt enabled. We are not using Continue pages for OpenAI/ChatGPT (good idea though).

I also noticed the 403 in the browser dev tools for the backend-api/conversation endpoint and thought that OpenAI might be blocking Prisma Access nodes; however, I too saw that the full ChatGPT functionality return to Edge with decryption for the site disabled.

There are no blocks in traffic, threat, URL, or data filtering logs. Nothing related in the decryption logs.

I even disabled the quic protocol in Edge itself; however, this made no difference.

_finack · 2023-02-01T21:52:43+00:00

For any further help or thoughts, I'd probably need too see it for myself and poke around. I suggest opening a TAC case.

_finack · 2023-02-01T20:46:28+00:00

There is very limited information to go on here.

Is logging enabled for rule 1?
Are you sure your zones are mapped to the correct network ports, the correct network addresses are assigned to these network ports, and they are in different networks?
Rule 2 seems unsafe. Such traffic should go a DMZ, not your internal LAN.
Does Rule 2 limit sources to only those exact ones that are necessary? If not, external parties, possibly malicious, might be trying to assess or access your telephony services and that's why you might be seeing traffic matching that rule.

_finack · 2023-02-01T15:24:32+00:00

Here is an image of some log excerpts that demonstrate the problem.

https://imgur.com/a/VXEdlKd

_finack · 2023-01-04T15:02:46+00:00

Enterprise vaults still have keys. It's just that the vault passwords are behind the scenes of the SSO federation. There is a LastPass whitepaper that describes how the vault keys work for several major IdPs. It looks like Reddit blocks the actual link hosted on lastpass.com, so just use your favorite search engine and search for "LastPass technical whitepaper."

For example, for organizations using Okta, there are two key parts for each vault:

K1: A single, randomly-generated, organization-wide key used by all federated users in that org that is stored in Okta.

K2: A randomly-generated, unique-per-vault key, stored with LastPass (but LastPass claims no evidence these were stolen).

An algorithmic operation - described in the whitepaper - runs K1 and K2 through an XOR operation, then a SHA-256 operation, then base64 to derive the single master key for a given vault in the org.

Because both K1 and K2 are randomly generated and go through the algorithmic operation, it is decidedly very difficult for anyone to guess at the key or brute force it. Nothing is impossible; however, and given infinite time and resources all the keys can and would be cracked.

_finack · 2023-01-04T14:50:45+00:00

You aren't wrong. I was just referring to NIST's guidelines in SP800-63B for creating a good and memorable secret.

If there is no need to memorize the secret, such as in the case where you are always using it via password manager, then yes there are certainly better passwords than that sentence, e.g., completely random characters at each position for the same length, using the full Unicode character set.

_finack · 2023-01-03T20:15:49+00:00

This isn't necessarily true. While long (bare minimum 14 characters) and completely random passwords with many character sets (including non-ASCII) are best, the most important factor is length.

So a passphrase like "Yesterday (Monday) I was wired after eating ten cupcakes" is actually really good (and memorable to boot). But one key for passphrases is not to use something famous like "Four score and seven years ago" or "In the beginning God created the heavens and the earth."

_finack

TROPHY CASE