Sounds like Phabricator should have an switch to turn on/off automatic expiration. This is a deal breaker for companies with sensitive code. Using shared secrets management becomes a no go.

I can implement it for my own deployment but then maintaining Phabricator will become a hell since one will need to keep merging.

Yes, if you require these features and aren't comfortable maintaining local patches then Phabricator isn't a good choice for your company.

Would you accept a patch for that?

Not without seeing broader interest first. You're the only person to ever ask for more granular control over session expiration, and I don't want to add configuration options which are only useful for one install.

OK. Can the expiration be taken care of by an app? I guess the reauth can't be. But expiration would already be very nice to have.

(If you add multi-factor auth to your account, Phabricator will now prompt you for factors when establishing a session and before taking sensitive actions.)

Would love to have this feature!

@beeerd, do you have a specific problem / use case driving your interest?

Our security team is driving the request, we have some strict compliance requirements around session expirations for internal services, so I'll be monkey patching this so long as it's unresolved.

Our configuration management software updates our phabricator install to HEAD every hour or so, so it's a little annoying to work around and keep in place.

Thanks for considering it!

T7390 has another compliance-driven request.

This task originally dates to before we implemented MFA. We believe MFA is a good solution for guarding sensitive actions (like authentication management and access to Passphrase secrets), and dramatically better than simply invalidating sessions frequently.

We may eventually implement controls over session time limits for compliance cases, but these policies seem somewhat misguided from a security point of view. I don't see a class of attack which these limits prevent or meaningfully mitigate which isn't better prevented with another mechanism, like allowing sessions to be bound to remote IP. Generally, we are hesitant to implement features which satisfy compliance requirements but don't actually make sense as features.

We'd be more willing to consider implementing these controls if anyone can describe a specific class of threat which they defuse which is not better defused with a different mechanism.

T7390 originates from information privacy rules, not from security related rules. I assume this rule stems from the greater rule that personally identifying information about users shall be kept to a minimum.

Can you walk me through the specific concern? It seems misguided to limit login session cookies for privacy reasons: to get a session cookie, you must uniquely identify yourself to the server and prove your identity. We necessarily know who you are because the entire purpose of a login session is to prove that.

At least in Chrome, you can enforce a session-only cookie policy in Settings > Advanced Settings > Privacy > Content Settings > Cookies. But, as far as I can see, this is entirely pointless for session cookies.

In general, if your organization has a well-meaning policy or compliance guideline which mandates a behavior, but the behavior is not actually desirable on its own in the absence of the compliance concern (i.e., in practice, the mandated behavior is arbitrary), we are very unlikely to implement support in the upstream. We recommend you:

• change the policy so it better achieves the desired effect (e.g., makes specific recommendations or requirements which are desirable even in the absence of the requirement); or
• obtain an exception or exemption to the policy; or
• maintain a local patch which implements the arbitrary rule required for compliance; or
• use other software which is complaint.

D10176 discusses a similar case, where compliance mandates checking a box which says "encryption", but that encryption is totally unprovable and does not protect against any material threat.

This isn't always going to be black-and-white, but we have a large backlog of tasks and consider implementing features to support compliance with questionable policies to be one of the least valuable things we could be working on.

There are actually legitimate security controls when you have sessions that don't expire. Cross site request forgery (CSRF) attacks specifically take advantage of persistent session tokens and use them to take action as the user that was granted the token.

There are also cross site scripting attacks that use similar methods.

Sessions tokens that don't expire within a reasonable timeframe can be used to access sensitive information is a laptop with the token is stolen.

So while it may be more convenient to have a long term session token, there are real security concerns here.

Cross site request forgery (CSRF) attacks specifically take advantage of persistent session tokens and use them to take action as the user that was granted the token.

We rotate CSRF tokens. They are not the same as session tokens.

There are also cross site scripting attacks that use similar methods.

I'm not aware of any such attacks. Can you explain them in more detail?

Sessions tokens that don't expire within a reasonable timeframe can be used to access sensitive information is a laptop with the token is stolen.

For any reasonable expiry, there is a wide window where they can still be used. The account owner can terminate the sessions explicitly, and should as soon as they realize their hardware has been stolen. Other methods, like binding sessions to IPs, are more effective in defusing these attacks. You should also require logins to access devices when they are not in use, encrypt disks, etc. If an attacker who steals your laptop immediately has access to the software running on it, that's a bigger and more general issue and almost certainly gives them access to something more interesting than Phabricator sessions. I'm not aware of a specific, credible line of attack here where Phabricator sessions are the weakest link and there isn't a better, more effective security measure available than timed sessions.

In T4806#98677, @epriestley wrote:

Cross site request forgery (CSRF) attacks specifically take advantage of persistent session tokens and use them to take action as the user that was granted the token.

We rotate CSRF tokens. They are not the same as session tokens.

The tokens that allow for persistent access to a site can be used for CSRF attacks. Do you have specific protections in place to keep this from happening?

There are also cross site scripting attacks that use similar methods.

I'm not aware of any such attacks. Can you explain them in more detail?

XSS attacks come in multiple flavors, client side attacks can be used to steal authentication tokens from the client system. Take a look at the information at owasp.org. They have much more detail available on the various attacks against web apps.

Sessions tokens that don't expire within a reasonable timeframe can be used to access sensitive information is a laptop with >>the token is stolen.

For any reasonable expiry, there is a wide window where they can still be used.

A token that in any way allows access to sensitive data should expire within a relatively short time frame. This is variable based on the sensitivity of the data protected, but the shorter the time frame the smaller the attack surface. A token that doesn't expire for weeks gives an unreasonably massive attack surface.

The account owner can terminate the sessions explicitly, and should as soon as they realize their hardware has been stolen.

I agree, but there are times when the account owner isn't informed of an equipment theft until days after the incident.

Other methods, like binding sessions to IPs, are more effective in defusing these attacks

Binding sessions to specific IPs can be useful, but it is not always practical if there are remote workers on DHCP clients, or if you have an environment where DHCP is used within a segment of the corporate network.

You should also require logins to access devices when they are not in use, encrypt disks, etc. If an attacker who steals your >laptop immediately has access to the software running on it, that's a bigger and more general issue and almost certainly gives >them access to something more interesting than Phabricator sessions.

Agreed, but not relevant to the topic at hand.

I'm not aware of a specific, credible line of attack here where Phabricator sessions are the weakest link and there isn't a better, >more effective security measure available than timed sessions.

Have you had your application tested by a qualified web application penetration tester?

Maybe this is a misread, but it sounds like you're pitching your consulting services without really knowing anything about Phabricator. It's open source; if you have questions about the implementation you can look at the source code. If you identify vulnerabilities, you can submit them through our HackerOne program.

If anyone has a specific, plausible threat scenario that they're concerned about, we can work to defuse it. You should file a separate task (or submit it through HackerOne if you believe it qualifies as a significant vulnerability).

For general or theoretical concerns with no specific threat scenario, whether they are rooted in compliance or an out-of-context read of OWASP, we are very unlikely to pursue changes.

Nope, I'm not pitching consulting services. I joined the conversation at the request of a member of my ops team, I am stating that allowing a token to remain valid for 30 days needlessly increases the attack surface of the application.

I have listed attack scenarios that can be used. I'm sorry that you feel that this is unimportant. When you're protecting sensitive code, you need to have as many reasonable layers of protection as possible. In this case, the ability to shorten the session time would be a useful security feature.

If you're looking for a proof of concept exploit for this specific issue within Phabricator, I don't have it. I do believe that the session length makes the likelihood of someone exploiting the software far greater than it would be otherwise.

I think the point here is that while some math like attack scenarios * session length = risk is good and valid, unless you can talk about specific attack scenarios we're not concerned about the effect session length has on increasing risk. General discussions about how websites can be attacked with no specific technical knowledge of how Phabricator mitigates these attacks are not helpful to us; we really do benefit though from specific discussions.

For example, @epriestley has already briefly explained that CSRF against Phabricator is difficult because we use a separate CSRF token in addition to the session token. I'm no security expert so maybe there's a problem there too, some debate about another race window from that protection, etc. but the high level general stuff has already yielded a loop:

In T4806#98678, @infosecdweeb wrote:

In T4806#98677, @epriestley wrote:

Cross site request forgery (CSRF) attacks specifically take advantage of persistent session tokens and use them to take action as the user that was granted the token.

We rotate CSRF tokens. They are not the same as session tokens.

The tokens that allow for persistent access to a site can be used for CSRF attacks. Do you have specific protections in place to keep this from happening?

(Yeah, the rotating CSRF tokens...)

I can't stress enough that we highly value specific reports on how we can improve -- see the HackerOne program as an example -- so please do let us know if you have anything like that.

Of course; any properly rotated token should form a loop.

@epriestley You asked for reasons for automatic session expiry. Several users of mine expect that their session expires when they close their browser. I think this is the default for many sites: If one wants to login permanently, one has to take specific action to enable it (often a "remember me" checkbox). If one uses a shared computer, the difference between expected and actual behaviour could become a problem.

P.S: Setting the session expiry time to 1h as you suggest is very inconvenient in my case. What I actually need is a "normal" expiry time, but using a session cookie on the client. So he gets automatically logged out when he closes the browser, but can use the session as long as necessary if he does not.

@epriestley I would love to have a configurable session timeout setting in phabricator so that I can set it to something more restrictive than a month.

Specific attack scenario: Phabricator is used to host proprietary code. Someone logs into Phabricator on a shared computer and forgets to log out. That shared computer is now forever logged into his account, allowing anyone using it to access said proprietary code. If the cookie would expire or at least be session-only, the risk would be significantly lower.

Why are users logging into sensitive accounts on shared computers? This action seems inherently unsafe to me.

If I'm an attacker with access to the shared computer, can't I just use the session within the next 24 hours (for whatever value of session expiration has been configured), or install a keylogger ahead of time?