openssh unix dev - Jan 2015 - Usability issue when forced to change password when logging in to a system

Hi,

What I am about to describe is something that has existed for a very 
long time, but it is still a usability issue. :)

When logging in to a system and the system detects that the password has 
expired and needs to change this happens

Login As: Foobar
Password:
Your password has expired. Choose a new password.
Old Pasword:


Now the user has just read the text

"Your password has expired. Choose a new password.".

This means that the user has already started thinking about what 
password to change to. The mind is set on the new password. And almost 
always (consistently) the "Old " prefix is lost. You just start typing
the new password. And *bam* you are in password change hell and get 
extremely frustrated as a result.

This has been observed with numerous people.

If you combine this with draconian password policies you are very close 
to snapping. ;)


In the OpenSSH source code it looks like OpenSSH does not cache and copy 
the authentication password back to the PAM stack when password change 
is invoked. Instead OpenSSH gets it again from the tty leading to the 
above usability issue.

So I am wondering if there is any reason for doing like this? And if 
not, could this please be fixed in an upcoming release of OpenSSH? Or 
prehaps there is already a configuration setting for tweaking this behavior?


/John

-- 

John Olsson
Ericsson AB
GSM BSC/BSS System Management

John Olsson M wrote:
> it looks like OpenSSH does not cache and copy the authentication password
..
> So I am wondering if there is any reason for doing like this?
Data hygiene is one.


//Peter

On Fri, Jan 23, 2015 at 11:52:13 +0100, John Olsson M
wrote:
> In the OpenSSH source code it looks like OpenSSH does not cache and
> copy the authentication password back to the PAM stack when password
> change is invoked. Instead OpenSSH gets it again from the tty
> leading to the above usability issue.
> 
As I recall, OpenSSH does not use PAM to implement password changes;
instead, it executes the system's passwd binary. This was done to avoid
a variety of problems. This allows password expiration to work on
platforms that do not have PAM support, and it probably also simplifies
the handling of password expiration when public-key or hostbased
authentication is used.

In short, executing passwd is simpler and much more portable.

-- 
Iain Morgan

On Fri, Jan 23, 2015 at 10:59 AM, Iain Morgan <imorgan at nas.nasa.gov>
wrote:
>
> As I recall, OpenSSH does not use PAM to implement password changes;
>
Actually it does (via pam_chauthtok() but only when you are using
keyboard-interactive and it has a reliable way to talk to to the user.

> instead, it executes the system's passwd binary.

It does that when you are not using PAM, or when you are using PAM with
"password" authentication (it can't call pam_chauthtok() in the
latter case
because by the time it can talk to the user via a tty, it has long since
dropped the privilege required to actually change the password.

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

On Fri, Jan 23, 2015 at 10:50 AM, Peter Stuge <peter at stuge.se>
wrote:
> John Olsson M wrote:
>> it looks like OpenSSH does not cache and copy the authentication
password
> ..
>> So I am wondering if there is any reason for doing like this?
>
> Data hygiene is one.
Also, in my opinion as more of an admin than a developer, any bug in a
routine that stores psswords temporary in plain text is *begging* to
have a bug or get an unexpected modification that publishes the
passwords somewhere else.  Basically, never handle or store dangerous
information that you don't *have* to store.