Expire passwords

[Paul Everitt]

"require password change every 180 days"

We'll require a new piece of information on the profile/user, with a date/time that is set whenever a password is correctly set. Then, during the Appropriate Time, if the current time is 180 days over, send them to the change password screen with a message explaining that their password is expired and requires a change.

"Appropriate Time" will have some rough edges. Let's describe some situations:

1) A not-logged-in user tries to login.

2) A logged-in user has the 2 week cookie which expires.

3) A logged-in user has the 2 week cookie for another couple of days.

4) (I forgot this one) Correctly handle the case of "Remember me" not being checked.

If someone has the cookie, I believe its going to be a bit of work for us to override the default cookie checking and do our own thing. I propose that we don't try to handle (3)...the user might go 185 days or even 193 days before being forced to change their password.

This means we only need to do "Appropriate Time" on the login screen.

However, the next step is also complicated. The simplest is to wipe their password and force a password reset. But that's not very user-friendly. We probably want to let them use their current password (to prove they are who they say they are) but immediately pick a new password.

This is a little bit dicey...we can't let them do anything else on the site with their old password, except change their password. That means we don't really log them in. We need to make sure that, even though their previous password is still there, it doesn't allow "login" to proceed.

[Paul Everitt (paul-agendaless)]

Some update on this:

- I later checked, and our cookie is currently valid for 10 years, I believe

- Today OSF decided to dial that down to 10 hours and remove the "Remember Me" checkbox
  (but have remember me happen implicitly, though 10 hours)

Nat, I think the topic of the last two paragraphs is still in play. What happens when someone uses KARL one day, and the next day, passes over the 180 day limit? They'll be logged out and presumably, can't log in to change their password.

[Paul Everitt (paul-agendaless)]

(Nat wasn't subscribed to this ticket. Let me re-add the comment.)

Some update on this:

- I later checked, and our cookie is currently valid for 10 years, I believe

- Today OSF decided to dial that down to 10 hours and remove the "Remember Me" checkbox
  (but have remember me happen implicitly, though 10 hours)

Nat, I think the topic of the last two paragraphs is still in play. What happens when someone uses KARL one day, and the next day, passes over the 180 day limit? They'll be logged out and presumably, can't log in to change their password.

[Nat Katin-Borland (nborland)]

Thanks Paul. I think you captured the cookie changes correctly - enforce 10 hr cookie and remove the "Remember me" checkbox.

For the use case of users whose passwords expire in between long spells of not using KARL, I agree that the most elegant thing to do is to let the user login and then immediately display a prompt letting them know that their password has expired and have them create the new one. If that can't be done, then I guess we just display the password reset screen. Am I reading it correctly that passwords set via password reset aren't tracked as part of the "remember the previous 10 passwords and prevent user from reusing them"?

[Paul Everitt (paul-agendaless)]

From Nat: "Users receive an email notification 24 hours in advance of password expiration letting them know that their KARL password will expire and that they should take immediate action to reset it"

I propose:

- A console script

- With an argument for the hours ahead of their last_password_change defaulting to 24

- I'll then hook that into the generated cron template

[Paul Everitt (paul-agendaless)]

Thinking more about it, I’m going to shoot down my proposal for creating a special security condition for these sorta-expired users. Fiddling with the groups they are in and adding a new set of permissions for some doppleganger group is a tricky wicket.

[Paul Everitt (paul-agendaless)]

If someone tries to login when they are over the expiration date, we give them a notice saying they need to reset their password, perhaps even redirect them to the reset process.

[Paul Everitt (paul-agendaless)]

Nat, another point to document for action...nobody currently has a password expires date, so we need to assign one to everybody (Carlos: an "evolve" script).

You wanted to avoid everybody expiring on the same day. I proposed randomly assigning people to a date 180+-10 days in the future, thus each day in that 180-day-ish future, roughly 1/20th of the people will expire.

Nat does this general idea sound ok?

Also, do you want to make it a broader range than +/- 10 days?

[Nat Katin-Borland (nborland)]

Thanks Paul. I think that sounds like a good approach. 10 days sounds like good spacing.

--
Nathaniel Katin-Borland
Business Analyst | Information Systems
Open Society Foundations | New York | 224 W 57th Street, NY, NY 10019
Office: [phone]
<email address hidden>
http://www.opensocietyfoundations.org

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Paul Everitt
Sent: Friday, September 09, 2016 2:10 PM
To: Nathaniel Katin-Borland
Subject: [Bug 1613274] Re: Expire passwords

Nat, another point to document for action...nobody currently has a password expires date, so we need to assign one to everybody (Carlos: an "evolve" script).

You wanted to avoid everybody expiring on the same day. I proposed randomly assigning people to a date 180+-10 days in the future, thus each day in that 180-day-ish future, roughly 1/20th of the people will expire.

Nat does this general idea sound ok?

Also, do you want to make it a broader range than +/- 10 days?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1613274

Title:
  Expire passwords

Status in KARL4:
  New

Bug description:
  "require password change every 180 days"

  We'll require a new piece of information on the profile/user, with a
  date/time that is set whenever a password is correctly set. Then,
  during the Appropriate Time, if the current time is 180 days over,
  send them to the change password screen with a message explaining that
  their password is expired and requires a change.

  "Appropriate Time" will have some rough edges. Let's describe some
  situations:

  1) A not-logged-in user tries to login.

  2) A logged-in user has the 2 week cookie which expires.

  3) A logged-in user has the 2 week cookie for another couple of days.

  4) (I forgot this one) Correctly handle the case of "Remember me" not
  being checked.

  If someone has the cookie, I believe its going to be a bit of work for
  us to override the default cookie checking and do our own thing. I
  propose that we don't try to handle (3)...the user might go 185 days
  or even 193 days before being forced to change their password.

  This means we only need to do "Appropriate Time" on the login screen.

  However, the next step is also complicated. The simplest is to wipe
  their password and force a password reset. But that's not very user-
  friendly. We probably want to let them use their current password (to
  prove they are who they say they are) but immediately pick a new
  password.

  This is a little bit dicey...we can't let them do anything else on the
  site with their old password, except change their password. That means
  we don't really log them in. We need to make sure that, even though
  their previous password is still there, it doesn't allow "login" to
  proceed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/karl4/+bug/1613274/+subscriptions

[Paul Everitt (paul-agendaless)]

Carlos, think you understand this evolve script?

Sent from my iPhone

> On Sep 9, 2016, at 14:18, Nat Katin-Borland <email address hidden> wrote:
>
> Thanks Paul. I think that sounds like a good approach. 10 days sounds
> like good spacing.
>
> --
> Nathaniel Katin-Borland
> Business Analyst | Information Systems
> Open Society Foundations | New York | 224 W 57th Street, NY, NY 10019
> Office: [phone]
> <email address hidden>
> http://www.opensocietyfoundations.org
>
>
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Paul Everitt
> Sent: Friday, September 09, 2016 2:10 PM
> To: Nathaniel Katin-Borland
> Subject: [Bug 1613274] Re: Expire passwords
>
> Nat, another point to document for action...nobody currently has a
> password expires date, so we need to assign one to everybody (Carlos: an
> "evolve" script).
>
> You wanted to avoid everybody expiring on the same day. I proposed
> randomly assigning people to a date 180+-10 days in the future, thus
> each day in that 180-day-ish future, roughly 1/20th of the people will
> expire.
>
> Nat does this general idea sound ok?
>
> Also, do you want to make it a broader range than +/- 10 days?
>
> --
> You received this bug notification because you are subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1613274
>
> Title:
> Expire passwords
>
> Status in KARL4:
> New
>
> Bug description:
> "require password change every 180 days"
>
> We'll require a new piece of information on the profile/user, with a
> date/time that is set whenever a password is correctly set. Then,
> during the Appropriate Time, if the current time is 180 days over,
> send them to the change password screen with a message explaining that
> their password is expired and requires a change.
>
> "Appropriate Time" will have some rough edges. Let's describe some
> situations:
>
> 1) A not-logged-in user tries to login.
>
> 2) A logged-in user has the 2 week cookie which expires.
>
> 3) A logged-in user has the 2 week cookie for another couple of days.
>
> 4) (I forgot this one) Correctly handle the case of "Remember me" not
> being checked.
>
> If someone has the cookie, I believe its going to be a bit of work for
> us to override the default cookie checking and do our own thing. I
> propose that we don't try to handle (3)...the user might go 185 days
> or even 193 days before being forced to change their password.
>
> This means we only need to do "Appropriate Time" on the login screen.
>
> However, the next step is also complicated. The simplest is to wipe
> their password and force a password reset. But that's not very user-
> friendly. We probably want to let them use their current password (to
> prove they are who they say they are) but immediately pick a new
> password.
>
> This is a little bit dicey...we can't let them do anything else on the
> site with their old password, except change their password. That means
> we don't really log them in. We need to make sure that, even though
> their previous password is still there, it doesn't allow...

[Carlos de la Guardia (cguardia)]

Yes, I believe I do.

[Carlos de la Guardia (cguardia)]

Paul, this is ready to test on branch expire_passwords.

[Paul Everitt (paul-agendaless)]

As a note, ready minus the console script.

—Paul

> On Sep 20, 2016, at 3:46 AM, Carlos de la Guardia <email address hidden> wrote:
>
> Paul, this is ready to test on branch expire_passwords.
>
> ** Changed in: karl4
> Status: New => In Progress
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1613274
>
> Title:
> Expire passwords
>
> Status in KARL4:
> In Progress
>
> Bug description:
> "require password change every 180 days"
>
> We'll require a new piece of information on the profile/user, with a
> date/time that is set whenever a password is correctly set. Then,
> during the Appropriate Time, if the current time is 180 days over,
> send them to the change password screen with a message explaining that
> their password is expired and requires a change.
>
> "Appropriate Time" will have some rough edges. Let's describe some
> situations:
>
> 1) A not-logged-in user tries to login.
>
> 2) A logged-in user has the 2 week cookie which expires.
>
> 3) A logged-in user has the 2 week cookie for another couple of days.
>
> 4) (I forgot this one) Correctly handle the case of "Remember me" not
> being checked.
>
> If someone has the cookie, I believe its going to be a bit of work for
> us to override the default cookie checking and do our own thing. I
> propose that we don't try to handle (3)...the user might go 185 days
> or even 193 days before being forced to change their password.
>
> This means we only need to do "Appropriate Time" on the login screen.
>
> However, the next step is also complicated. The simplest is to wipe
> their password and force a password reset. But that's not very user-
> friendly. We probably want to let them use their current password (to
> prove they are who they say they are) but immediately pick a new
> password.
>
> This is a little bit dicey...we can't let them do anything else on the
> site with their old password, except change their password. That means
> we don't really log them in. We need to make sure that, even though
> their previous password is still there, it doesn't allow "login" to
> proceed.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1613274/+subscriptions

[Paul Everitt (paul-agendaless)]

Carlos, can you think of how we can test this without waiting 170-190 days?

For example, we could change the values of 170 and 190 in the evolve script to 2 and 4. When we install it on karlstaging, some of Nat’s accounts (and my accounts) will have a distribution of expiry dates. They should then emit an email for a cron’d console script and do the whole routine of forcing a password reset.

Afterwards we could change the values back to 170 and 190. (Or, make them config values.)

—Paul

> On Sep 20, 2016, at 3:46 AM, Carlos de la Guardia <email address hidden> wrote:
>
> Paul, this is ready to test on branch expire_passwords.
>
> ** Changed in: karl4
> Status: New => In Progress
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1613274
>
> Title:
> Expire passwords
>
> Status in KARL4:
> In Progress
>
> Bug description:
> "require password change every 180 days"
>
> We'll require a new piece of information on the profile/user, with a
> date/time that is set whenever a password is correctly set. Then,
> during the Appropriate Time, if the current time is 180 days over,
> send them to the change password screen with a message explaining that
> their password is expired and requires a change.
>
> "Appropriate Time" will have some rough edges. Let's describe some
> situations:
>
> 1) A not-logged-in user tries to login.
>
> 2) A logged-in user has the 2 week cookie which expires.
>
> 3) A logged-in user has the 2 week cookie for another couple of days.
>
> 4) (I forgot this one) Correctly handle the case of "Remember me" not
> being checked.
>
> If someone has the cookie, I believe its going to be a bit of work for
> us to override the default cookie checking and do our own thing. I
> propose that we don't try to handle (3)...the user might go 185 days
> or even 193 days before being forced to change their password.
>
> This means we only need to do "Appropriate Time" on the login screen.
>
> However, the next step is also complicated. The simplest is to wipe
> their password and force a password reset. But that's not very user-
> friendly. We probably want to let them use their current password (to
> prove they are who they say they are) but immediately pick a new
> password.
>
> This is a little bit dicey...we can't let them do anything else on the
> site with their old password, except change their password. That means
> we don't really log them in. We need to make sure that, even though
> their previous password is still there, it doesn't allow "login" to
> proceed.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1613274/+subscriptions

[Nat Katin-Borland (nborland)]

Until we figure out how to artificially expire passwords, this is not something I can actually test, correct?

--
Nathaniel Katin-Borland
Business Analyst | Information Systems
Open Society Foundations | New York | 224 W 57th Street, NY, NY 10019
Office: [phone]
<email address hidden>
http://www.opensocietyfoundations.org

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Paul Everitt
Sent: Tuesday, September 20, 2016 6:59 AM
To: Nathaniel Katin-Borland
Subject: Re: [Bug 1613274] Expire passwords

As a note, ready minus the console script.

—Paul

> On Sep 20, 2016, at 3:46 AM, Carlos de la Guardia <email address hidden> wrote:
>
> Paul, this is ready to test on branch expire_passwords.
>
> ** Changed in: karl4
> Status: New => In Progress
>
> --
> You received this bug notification because you are subscribed to the
> bug report.
> https://bugs.launchpad.net/bugs/1613274
>
> Title:
> Expire passwords
>
> Status in KARL4:
> In Progress
>
> Bug description:
> "require password change every 180 days"
>
> We'll require a new piece of information on the profile/user, with a
> date/time that is set whenever a password is correctly set. Then,
> during the Appropriate Time, if the current time is 180 days over,
> send them to the change password screen with a message explaining that
> their password is expired and requires a change.
>
> "Appropriate Time" will have some rough edges. Let's describe some
> situations:
>
> 1) A not-logged-in user tries to login.
>
> 2) A logged-in user has the 2 week cookie which expires.
>
> 3) A logged-in user has the 2 week cookie for another couple of days.
>
> 4) (I forgot this one) Correctly handle the case of "Remember me" not
> being checked.
>
> If someone has the cookie, I believe its going to be a bit of work
> for us to override the default cookie checking and do our own thing.
> I propose that we don't try to handle (3)...the user might go 185
> days or even 193 days before being forced to change their password.
>
> This means we only need to do "Appropriate Time" on the login screen.
>
> However, the next step is also complicated. The simplest is to wipe
> their password and force a password reset. But that's not very user-
> friendly. We probably want to let them use their current password (to
> prove they are who they say they are) but immediately pick a new
> password.
>
> This is a little bit dicey...we can't let them do anything else on
> the site with their old password, except change their password. That
> means we don't really log them in. We need to make sure that, even
> though their previous password is still there, it doesn't allow
> "login" to proceed.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1613274/+subscriptions

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1613274

Title:
  Expire passwords

Status in KARL4:
  In Progress

B...

[Carlos de la Guardia (cguardia)]

To test this, I changed the expire password date of a couple of users to the current date. That's fairly easy to do in the debugger, but I guess a simple console script for that would be helpful. I can do that.

[Carlos de la Guardia (cguardia)]

Added "set_password_expiration username date" to the karl scripts, for easy testing.

[Carlos de la Guardia (cguardia)]

I added the "password_reset_reminder -H hours" script. Default for hours is 24. There is a template with the text for the email in scripts/templates/.

[Paul Everitt (paul-agendaless)]

An update from Oleg...the policy is, must have 3 of the following 4:

- Special character (anything not A-Z)
- Number
- Upper
- Lower

This means, let's give up on doing it with a regex in config and just put it in the software.

[Paul Everitt (paul-agendaless)]

I just ran the password expiration reminder scripts and it worked. I was sent a reminder. I then set the user's expiration to yesterday.

However, when I went to login with that user, it let me log in. The following shows that I did set the date:

>>> pp = root['profiles']['plonepaul3']
>>> pp.password_expiration_date
datetime.datetime(2016, 10, 3, 0, 0)

As a note, I don't think the evolve scripts have run to completion on staging.

[Paul Everitt (paul-agendaless)]

Good news, Carlos worked tonight and things are now in good shape:

- Expiring passwords sends people to the Expired Password Reset screen, which asks for their old password and new (with confirm)

- He made the changes to the email template as you asked

So this is good news, to have the big work have at least some testing.