PL
Owen Winkler
logs you out after 20 minutes of inactivity. This can be a problem if
it takes you longer than that to write a post, since it'll lose your
post when making you log in after the timeout.
There are probably a few ways to improve this situation. One suggestion
was to increase the timeout to an hour. Another thought I had was to
make the login page forward any submitted data to the original
destination upon successful login.
There is another approach that might be useful, too:
http://jaspan.com/improved_persistent_login_cookie_best_practice
This employs the use of multiple levels of logged-in-ness. If you
authenticate via cookie only (and haven't otherwise verified your
identity during a session), then you might only have access to
non-essential features. For example, you wouldn't be able to activate
plugins or change site options without first authenticating.
Does anyone have any additional security needs in this regard? Do you
have any other ideas how we could improve the session/login/timeout
situation?
Owen
Chris J. Davis
used to help with this situation.
Chris
Scott Merrill
> logs you out after 20 minutes of inactivity. This can be a problem if
> it takes you longer than that to write a post, since it'll lose your
> post when making you log in after the timeout.
I like the idea of extending the timeout to at least 1 hour.
In addition to Chris' auto-save plugin, a simple AJAX component could
probably provide a keep-alive function, to keep your session alive as
long as you're in the Admin area.
> There is another approach that might be useful, too:
> http://jaspan.com/improved_persistent_login_cookie_best_practice
>
> This employs the use of multiple levels of logged-in-ness. If you
> authenticate via cookie only (and haven't otherwise verified your
> identity during a session), then you might only have access to
> non-essential features. For example, you wouldn't be able to activate
> plugins or change site options without first authenticating.
I like the idea that cookie-based persistent login might allow one to
compose and publish posts, while not permitting them to make
significant configuration changes to the site.
Should cookie-based logins permit one to manage comments? If someone
hijacked your session, they could conceivably approve a spam comment,
and then open the floodgates for additional spam (if the pre-approved
plugin were already enabled, for example). I don't think this is too
big a deal: it's not so hard to delete spam, it's just time consuming.
I think I'm in favor of cookie-based logins permitting one to approve
and delete comments.
Michael Heilemann
Scott Merrill
> I'm wondering why it is Habari needs to log me out at all.
To prevent someone from logging in as you against your wishes.
Let's turn the question back on you: Why _shouldn't_ Habari log you out at all?
> Consider how Google whom I trust with my most valuable private data (mail,
> calendar, feeds, notes and so on), don't feel the need to do this. On a very
> fundamental level, I don't want my software to do this, whether for security
> or not.
Do you log into your computers?
Do you log into your email?
Owen Winkler
>
> A 'remember me' checkbox should be available, with appropriate warnings.
> And that functionality shouldn't have to be a plugin.
I guess this checkbox is the key to the issue. If the user says "I
don't care that my session is horribly insecure" when they create it,
then at least it's on them.
Owen
Owen Winkler
>
> In addition to Chris' auto-save plugin, a simple AJAX component could
> probably provide a keep-alive function, to keep your session alive as
> long as you're in the Admin area.
Neither of these, although both good ideas, help me on my phone, which
is where I experience the issue.
> I like the idea that cookie-based persistent login might allow one to
> compose and publish posts, while not permitting them to make
> significant configuration changes to the site.
>
> Should cookie-based logins permit one to manage comments? If someone
> hijacked your session, they could conceivably approve a spam comment,
> and then open the floodgates for additional spam (if the pre-approved
> plugin were already enabled, for example). I don't think this is too
> big a deal: it's not so hard to delete spam, it's just time consuming.
> I think I'm in favor of cookie-based logins permitting one to approve
> and delete comments.
The question here for me is whether it would be worth it to do the work
to add this extra layer of user auth-ness. How does this affect the
permission system in place? Could be tricky.
Owen
Michael Heilemann
Do you log into your computers?
Do you log into your email?
Scott Merrill
> Nope.
I do.
> > Do you log into your email?
> Nope.
I do.
I also never, ever click the "Remember this password" dialog box when
filling out web forms. I _do not_ want my computer to remember my
passwords, and I _do not_ want an automatic login process.
> See? :)
Yes, I see that you are not as concerned about security as I am.
Neither of us is empirically correct on this issue, and to force
Habari to satisfy one of us will frustrate the other.
As application developers, I feel we have an obligation to make the
right choices with our software so that a fresh installation is secure
and presents the best practices -- as defaults -- to the users. To
me, the right choice is to expire logouts on a timely basis and to not
permit permanent authentication cookies.
I feel strongly that a "remember me" button belongs in the realm of a
plugin. It should be something that one _intentionally_ applies to
one's installation in order to weaken the default security.
Scott Merrill
> Scott Merrill wrote:
> > In addition to Chris' auto-save plugin, a simple AJAX component could
> > probably provide a keep-alive function, to keep your session alive as
> > long as you're in the Admin area.
>
> Neither of these, although both good ideas, help me on my phone, which
> is where I experience the issue.
Perhaps it's not Habari's place to solve this problem for you. I
recommend composing your posts in a text editor on your phone, and
then copying and pasting it into Habari when you're ready to publish
it. Or perhaps an Atom Publishing Protocol client can ease your pain.
> > Should cookie-based logins permit one to manage comments? If someone
> > hijacked your session, they could conceivably approve a spam comment,
> > and then open the floodgates for additional spam (if the pre-approved
> > plugin were already enabled, for example). I don't think this is too
> > big a deal: it's not so hard to delete spam, it's just time consuming.
> > I think I'm in favor of cookie-based logins permitting one to approve
> > and delete comments.
>
> The question here for me is whether it would be worth it to do the work
> to add this extra layer of user auth-ness. How does this affect the
> permission system in place? Could be tricky.
I think the persistent login providing limited access to Habari
administrative features might be the best compromise between security
and convenience for those users (like Heilmann) who want an
always-logged-in experience. It allows them to do what they need to
do most of the time, while not permitting an attacker to muck about
too much with the system configuration.
Geoffrey Sneddon
On 30 Nov 2007, at 18:15, Scott Merrill wrote:
> I feel strongly that a "remember me" button belongs in the realm of a
> plugin. It should be something that one _intentionally_ applies to
> one's installation in order to weaken the default security.
To me that sounds like Habari by default forcing a certain behaviour.
I feel strongly that it should be in core — if implemented properly
persistent login causes very few security issues.
--
Geoffrey Sneddon
<http://gsnedders.com/>
Christian Mohn
Sure, provide a plugin that lets you lessen the security if you want, but
make it as secure as possible out of the box.
Christian
-----Original Message-----
From: habar...@googlegroups.com [mailto:habar...@googlegroups.com] On
Behalf Of Geoffrey Sneddon
Sent: 30. november 2007 19:27
To: habar...@googlegroups.com
Subject: [habari-dev] Re: PL
On 30 Nov 2007, at 18:15, Scott Merrill wrote:
> I feel strongly that a "remember me" button belongs in the realm of a
> plugin. It should be something that one _intentionally_ applies to
> one's installation in order to weaken the default security.
To me that sounds like Habari by default forcing a certain behaviour.
I feel strongly that it should be in core - if implemented properly
Caius Durling
On 30 Nov 2007, at 20:08, Christian Mohn wrote:
> In simple terms, my take on it is: Secure by Default
I agree with Christian here. By default we should be secure, _but_ if
the user wishes to lessen the security of the blog then we should
provide an easy way for them to do it, be it via a remember me tickbox
or via a plugin.
C
____________________________________
Caius Durling
UK Student -- +44 (0) 7960 268100
ca...@caius.name -- nemo...@mac.com
http://caius.name/ -- http://hentan.eu
____________________________________
Michael Heilemann
> In simple terms, my take on it is: Secure by DefaultI agree with Christian here. By default we should be secure, _but_ if
the user wishes to lessen the security of the blog then we should
provide an easy way for them to do it, be it via a remember me tickbox
or via a plugin.
broke...@gmail.com
What about having the logging out as a default function (to keep all the security conscious peeps happy) and having a little tickbox option in one of the admin setup page, in core , enable you to remove that function.
For the record I am with mike h on this one as I have two computers that I use from that no one else has access to and no I don't log in, waste of time for me. However I understand where Scott is coming from so let's just out it as a tickbox with clear instructions in one of the setup admin options
------------------
-----Original Message-----
From: "Michael Heilemann" <heil...@gmail.com>
Date: Sat, 1 Dec 2007 07:45:27
Owen Winkler
> There might be a happy medium that would make everyone happy.
Security should ALWAYS be considered when thinking about assets people
might care about. Think about what could be stored in Habari and what
could be at stake for all users, not just your personal preference or
what will make the most people marginally happy.
You can't consider only the common scenarios, when things are working as
normal. If everything is normal, no one is trying to illicitly get into
your system, so you may as well not have a password at all. Think about
the unexpected cases where security becomes more important. Persisted
login could even be a problem in situations outside of hackers stealing
your cookies, like if your entire laptop is physically stolen.
By making the system as secure as possible by default, you help prevent
people from having an unintentionally insecure machine. Since most
users don't stray from the defaults, making that default secure is
crucial. If it's possible to convey the ramifications of reducing
security in checking a box that you would only see once if you checked
it, I would be interested in hearing it. It is certainly not solely the
words "remember me". It's more along the lines of, "Lower the security
of this system and increase the probability someone can steal your login
by persisting your logins between sessions." Still, this is like
clicking OK on an error message you don't understand, or clicking
through the EULA on a software installation without reading it. It's
not the user's fault that the software/interface poorly conveyed the
full impact of their click decision or that they don't have the
background in computer security to truly understand its impact.
As the designers of this software, it is our responsibility to take its
users' security seriously, and not consider just ourselves. There are
going to be plenty of people who opt for a persisted login that doesn't
timeout, and there's nothing inherently wrong with that as long as they
undertake those risks informed.
What we need to consider is that making decisions about the defaults in
Habari is essentially making decisions for all of our future users. We
should make sure to make them wise, secure decisions. It's unlikely
anyone will thank us for making them secure (in fact, they'll probably
complain, as many have so far), but it's a guarantee we'll hear it if we
make bad decisions and people get exploited because of them.
Owen
Christian Mohn
one but not activated by default. Adding it to core means that you can't
remove it without touching the code, and that makes the potential attack
surface of Habari larger.
-----Original Message-----
From: habar...@googlegroups.com [mailto:habar...@googlegroups.com] On
Michael Heilemann
Robin Adrianse
AJ
not be via a plugin but in core.
Maybe make it a selectable admin option that users should be allowed
persistent login sessions, on setting of which, the "remember me"
checkbox and no-timing out functionality is used.
AJ
Scott Merrill
> not be via a plugin but in core.
> Maybe make it a selectable admin option that users should be allowed
> persistent login sessions, on setting of which, the "remember me"
> checkbox and no-timing out functionality is used.
In an effort to put my money where my mouth is, I've created a
"convenience over security" plugin. It adds a select box to the user
profile page allowing you to select convenience over security. It
presents to you a fairly mild warning.
The checkbox should only appear when you edit your own profile page: I
don't think any site administrators should be permitted to weaken the
security of their users if their users don't consent to that.
I _think_ I got the session preservation bit correct: it simply
doesn't permit the session handler to delete a session, ever. This
might need some tweaking. I haven't tested it very hard, because
frankly I'm not going to use this. If you think it's something you'd
like, feel free to step forward and claim ownership of it.
Cheers,
Scott
Scott Merrill
> "convenience over security" plugin. It adds a select box to the user
> profile page allowing you to select convenience over security. It
> presents to you a fairly mild warning.
> I _think_ I got the session preservation bit correct
No, I didn't get the session stuff correct: the previous version of
the plugin disabled session deletion for _everyone_, which is clearly
not what I had in mind (thanks, Owen, for pointing that out).
Attached is a revised plugin that honors an individual's convenience setting.
Owen Winkler
Persistent logins, regardless of how you implement them, permit you to
enter a site by providing only a cookie value. There are many ways to
implement this, some better than others, all less secure than
implementing it at all.
The current default login implementation issues a cookie to the browser
with a temporary code that permits the browser access to areas that
require a login. Using this method conveniences the user to browse
restricted areas of the site without having to submit their password to
each restricted page. Nonetheless, this allows an additional vector of
access to restricted pages independent of logging in with username and
password. Attackers with access to that cookie value (or an ability to
guess it) could potentially use it to compromise the system. The
vulnerability of the system increases because you can now access the
system via a regular username/password login or providing a
pre-authenticated cookie.
It is additionally bothersome in that cookies are normally stored on the
browser system without the user's explicit consent, unlike the any
password they might enter. As such, inspecting the system for these
cookie values even after a browser has closed may yield results that
allow login access. You need only obtain physical access to the PC
after a login to get these values, which is very easy to do in a school
computer lab or on any other public access system.
To mitigate this issue, Habari expires a login cookie after 20 minutes.
So even if an attacker gains access to a cookie, the cookie is only
valid for 20 minutes after the last valid use. This should minimize the
ability for an attacker to exploit the cookie.
The main trouble with instituting persistent login is that it would
effectively extend session expiration indefinitely. This would allow an
attacker both an extended amount of time to collect login cookies and an
extended amount of time to engineer an opportunity to use them.
It may be possible to construct a method that makes it more difficult
for the attacker to use the cookies that enable persistent login, but
the unassailable fact remains that if it is allowed, then there is less
security.
"if implemented properly persistent login causes very few security
issues." Literally, this is correct. It causes the few security issues
that I have outlined above, which are more issues than we would have
without it.
A more convincing argument for the institution of persistent logins
might be that the security implications are outweighed by the
convenience for and expectations of Habari's users. For that, as I have
been requesting in more recent email, we would need a way to educate the
user on the decision they are making. I think that the message that
Mike Heilemann recently suggested might be appropriate.
Still, it stands that if I am having this much trouble convincing people
who think they know enough to make decisions on Habari's security that
this is a valid concern, then it's probably true that the average user
of Habari has absolutely no clue about the implications of such a
decision. I doubt that any of the above technical jargon has persuaded
anyone who can't be bothered beyond the re-login prompts annoying them.
This is why it is so important that Habari makes it difficult to make
poor security choices - because we should expect that common users will
chose ease over security when the implications aren't brilliantly obvious.
That said, if someone can produce good code and solid reasoning for
implementing persistent logins in a way that affords users more
convenience, properly informs them of the ramifications of any security
choices we leave in their hands, and - of primary importance - is still
secure enough that we can feel good about the security our product
provides, then I'll be happy to commit that code myself.
My personal reason for why this thread has dragged on so long rather
than being resolved by throwing the first solution presented at it, is
because I'm genuinely concerned that we take time to adequately consider
what we do in terms of security. With none of the solutions so far (and
if I am incorrect in that, please bring it to my attention) has anyone
said something to the effect of, "This solution isn't perfectly secure,
but I think it's a good trade-off." That gives me the perception that
we're not thinking about those implications, and that truly worries me.
As minor of an issue this seems, how will we deal with security
decisions in the future that are more meaningful? Hopefully not by
jumping at the first option that looks good without considering the
ramifications.
Until there is a consensus that what we're committing actively degrades
Habari's security but at reasonably significant benefit to the user,
I'll continue to actively oppose any such thing being included in core.
Owen
tinyau
Michael Bishop
from the camp of, the most secure by default option, but under the
current situation, I have allowed my browser on my main desktop, which
no one else touches, to "remember my login". Thus, when I navigate to
example.com/admin, I'm met with the login screen from my theme, with
the user name and password filled in, I hit submit, and I get to where
I'm going, quickly. This was a conscious decision by me, not the
application, which I like. Much as I set my browser to open any links
attempting to open in a new window in a tab. I don't like being told
how I'm supposed to interact with such things. However, if I were
to need to visit my site from another machine, I would feel secure in
knowing that my login would be less capable of being compromised after
I walk away from said machine. So, if someone's inclined to create a
plugin that allows a site to be accessed by whom ever, when ever, more
power to them. But I'd not like it to be spoon fed out in the core.
I've dealt with support enough in the past, that any way to
potentially help beginners, the better. Especially knowing they are
going to be using their first pet, Muffy, as a password.
Am I missing something here in the discussion?
~miklb
Michael C. Harris
Attached is a patch for Skippy's convenience over security plugin that
adds a link to the wiki with a longer explanation, in which I just
reworded what Owen's been saying.
cheers, Michael
MattRead
Scott Merrill wrote:
> No, I didn't get the session stuff correct: the previous version of
> the plugin disabled session deletion for _everyone_, which is clearly
> not what I had in mind (thanks, Owen, for pointing that out).
>
> Attached is a revised plugin that honors an individual's convenience setting.
session data which will essentially log you out. This is my
implementation of something similar, I just chage the expire time to 3
hours after login. But there's no check box or anything...
http://drunkenmonkey.org/source/user/plugins/stayloggedin/stayloggedin.plugin.php