Call for testing for 3.6: password expiry?

[Darren Tucker]

Hi All. 
	Before I follow up Ben's post I wanted to say that, for anyone who
hasn't been following the saga, dealing with the password expiration
issue is *not* as simple as it seems at first glance.  Indeed, I thought
it was simple when I started on it, but that was roughly 5 months and 20
patches ago :-).  Every solution to involves some compromise.

	Although I'm disappointed that the patch didn't make 3.6p1 I do
understand the reasons why.  I will work to get it merged post-3.6 and
will maintain the patch until then.  I will also publish a patch against
3.6p1 for those who can't wait.

Ben Lindstrom wrote:
[about password expiry]
> 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.

Could you elaborate on these timing attacks, and would password change
via keyboard-interactive be succeptible to them?

> 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.

You need the checks for expired passwords anyway (and some of them are
already there) but yes, the platform-specific change functions do add a
lot of code (50-120 lines or so per platform) that runs as root.  

> 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.

Also true.

> 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.

Yep, this gives you the maximum coverage (ie protocols 1&2) for the
smallest amount of code.  Doing it any other way results in fewer
platforms/configurations supported, more code, or both.

> 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?

Well at the moment an expired password (on the platforms that currently
support them, eg /etc/shadow) will result in an authentication failure
even with public-key.  Warning and forcing a change in that case seems
reasonable, and that's what I would recommend.

I've also had some experience with the no-expiry-on-public-key scheme
(on AIX which is not supported for password expiry yet).  It's fine
until you need to get in some way other than ssh (eg on the console when
the network is broken) and your password has been expired too long then
you are well and truly snookered.

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

Agreed!  There's no ideal solution to it, all the solutions we've looked
at so far have pros and cons.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.