Call for testing for 3.6: password expiry?

[Ben Lindstrom]

On Fri, 21 Mar 2003, Chris Adams wrote:

> Once upon a time, Ben Lindstrom <mouring at etoh.eviladmin.org> said:
> > Why password expiry?  Have you looked at the RFC?  If we implement v2
> > password expiry the way the RFC requires we will break a lot of platform
> > and the code would be massive.
>
> As Tru64 is kind of odd... how does password expiry work in the RFC that
> might break platforms?
>

I still don't know enough about SIA, but the way the RFC works is they
want the password change to occur in an non-interactive way to try and
remove timing attacks for passwording guessing.

So for us to implement (in general) RFC SecSH v2 password change method it
would mean we would not only need the generic strucor handling it, but
also checks for every method that you could expire passwords (PAM, shadow,
SIA, HP/UX Trust, etc) plus feed through any of those systems for password
changing.

So the code base would bloat massively.

Also, keep in mind that if you are not using some system level API to
enforce password rules we end up with people whining because their passwd
policies (enforced by /bin/passwd) are being ignored.

As a result, we pretty much agreed that we will be opening up a TTY before
the session starts and do password change the same as v1 did.

BTW.. the other thing we have to watch out for is that all port
forwarding and advanced ssh features are denied or delayed until the
password has been changed.

Then the question comes up.  Password expires and your using public key?
do you deny the public key and require them to change their password
first?  Do you warn them?  Do you allow the public key to be done ignoring
all expiration?

These are some of the issue that all need to be discussed and agreed on
(not just community/portable, but with OpenBSD group too).

And I'm sure all of this will be rehashed again before the final patches
are commited.

- Ben