Ideally one would allow anonymous users to browse via HTTP, and as soon as they log in, switch to SSL, where they can store a cookie.

Doesn't this also apply to the session cookie that is used by most application servers to track sessions? Intercepting that over HTTP would allow a session to be hijacked correct? I believe that cookies can be marked as 'secure', which would mean that the browser should only transfer the cookie through an SSL connection. So perhaps the option should be for the cookie for cookie-based logins should be marked as 'secure'?

This should apply to Confluence as well, not just Jira. Also, the cookie stored on a user's machine should be encrypted and tied to the machine as well.

> Also, the cookie stored on a user's machine should be encrypted and tied to the machine as well.

The cookie is encrypted, for what that's worth. I don't think cookies can be tied to a machine (or a client IP). If there is a risk of clients being compromised, set jira.option.allowcookies=false in jira-application.properties to disable the "Remember me" checkbox altogether.

"The cookie is encrypted, for what that's worth."

So it is, my apologies, I should have looked before making that generic statement. I found several Confluence cookies on my system, one of which has encrypted contents and a reference to Seraph which is, I believe, the security framework you guys use, yes?

As for the next part, I'm not a coder nor do I play one on tv:

"I don't think cookies can be tied to a machine (or a client IP)"

A couple of years back we put in an application that our security guys raved about because they said the cookie was a> encrypted, b> tied to the client machine, c> tied to the specific server and d> only responded to SSL calls. That was the foundation for my comment. Basically, we don't want someone being able to take the cookie to another machine and have it work, or have another server try to call it and receive it successfully. Welcome to the days of paranoia, eh?

"jira.option.allowcookies=false in jira-application.properties"

The age old problem of balancing convenience versus security. In any case, where might one set this in Confluence, should our security department mandate this approach? Thanks!

> So it is, my apologies, I should have looked before making that generic statement. I found several Confluence cookies on my system, one of which has encrypted contents and a reference to Seraph which is, I believe, the security framework you guys use, yes?

Yes, the Seraph cookie is the encrypted one containing username/password. I said "for what that's worth", because it's worth very little. As a token it will still allow a person to log into JIRA.

> A couple of years back we put in an application that our security guys raved about because they said the cookie was a> encrypted, b> tied to the client machine, c> tied to the specific server and d> only responded to SSL calls. That was the foundation for my comment.

Perhaps tying cookies to client IP is possible. I didn't see a reference in the RFC and I can't see how it could be reliably enforced.

> "jira.option.allowcookies=false in jira-application.properties"
>
> The age old problem of balancing convenience versus security. In any case, where might one set this in Confluence, should our security department mandate this approach? Thanks!

I don't think Confluence has that yet. You could put in a feature request if it is needed.

Cheers,
Jeff