Password change via HTTP

This seems like such an obvious issue that it's hard to believe it's
not addressed by the existing protocol but, for the life of me, I can't
see it, so I'll "open my mouth and remove all doubt" :

Many password oriented security systems have password expiration mechanisms
that force users to change passwords on a semi-regular basis. When a user's
password has not been changed within a system-specific time interval the
password is considered "expired" and the user is prompted for a new password
the next time she/he logs on. Furthermore, many security systems allow a user
to change his or her logon password at any time. Yet both of these features
are, at best, clunky to implement via HTTP.

Our current hack for allowing users to change password, is to allow users
using our software to change passwords by specify a new password after their
existing password by separating old password from new password with a colon
(:). This deeply unsatisfactory on many accounts.

1. When our server accepts the old-pass:new-pass password, the browser sends
   this same pair the next time it requests a URL from the same server. But,
   on subsequent attempts, old-pass is no longer valid. Unless we do something
   fancy, this results in a 401 going back to the browser, forcing the user
   to just enter new-pass. Yes, it might be possible to check if new-pass is
   now the current password but not until after old-pass is rejected and a
   password violation logged (we can't all control the web server *and* the
   access control facility). Perhaps we can keep a history of successful password
   changes but is a lot of work if one wishes to make this history survive
   server outages. From an aesthetic point of view, it's just plain grody
   that the browser is sending old-pass:new-pass on every request to the
   server.

2. If new-pass is invalid (not enough characters, contains an invalid
   character, whatever), we have no decent way of identifying the problem
   to the user. Perhaps if browsers would display the text of the 401 message
   in the password pop-up windows ? Doing so, however, would produce some
   serious backword compatibility problems. We can also put up a page
   explaining the problem with an indication that the user should hit
   "reload" however that's done on whatever browser the user is using
   (mumble, mumble) and then correct the problem. Unfortunately, when the
   user hits reload, the browser will believe that the user had enterred
   a valid password (after all, it got an HTML page didn't it ?) so will
   re-send it producing the same page indicating the same problem.
   Argggggghhhhh ! Re-directing with a back link produces the same
   result. So what's a poor server to do ? Send an explanation page
   every other time, alternating with 401's ? Horrors ! Another alternative
   is to provide a password change page but this can be a major pain
   depending on the access control facility and would result in the
   loss of any POST data unless many hoops are jumped through.

3. There is no decent way to tell the user that his/her password has
   expired and a new one is required. Once again, the current technology
   is to send down a page that explains the situation to the user,
   explaining that the user must hit reload (mumble, mumble) and then
   respond to the password expiry. But then you're back to the reload
   loop problem outlined in 2.

There are other problems with the current mechanisms but these 3 are
the major ones.

Clearly, I must be missing something because dealing with expired
passwords can't possibly be this bad, can it ? It certainly seems that
the Digest Access Authentication Scheme won't help much because sending
any passwords (new or old) in clear text is antithetical to its
operation. But a new password *must* be sent in clear text (though
advisedly over an SSL connection) unless one can control the encryption
of the passwords on the access control facility and change it to
something the browser understands (we don't and can't).

On the off chance that I'm not missing anything, I would think a new
response header field such as "WWW-Authnewpass:" with values such as
"disallow", "allow", "require" would do the trick. Perhaps a new
response message indicating "Invalid new password" would be useful
to notify the browser of a common error. The browser would need a
new request header ("Authnewpass:" ?) that contains any new password
provided. If the new password appears to be accepted, the browser
would use the new password in subsequent accesses to the server.
Perhaps any browser that supports "Authnewpass:" would send it every
time followed by a null string to indicate that it supports this
facility so that the server can drop back to old/clunky mode of
operation, otherwise.

Yes, yes, I understand HTTP 1.1 is frozen, so I suppose a reasonable
response is to tell me to go bark up another tree. I'm actually kinda
hoping someone will respond and tell me how stupid I am and how
password expirations are easily and elegantly handled by the current
protocols (a little public humiliation never hurt anyone).

Sorry about the long post and thanks for your time.

Alex Kodat
Sirius Software
Cambridge, MA

Received on Saturday, 12 June 1999 20:10:27 UTC