Re: Multiple 331 password responses in FTP protocol


Kurt F. Sauer (pbox!romed!svo!okstate!ks@RUTGERS.EDU)
7 Sep 87 18:44:56 GMT


In article <8709041634.AA11908@topaz.rutgers.edu>, Ron Natalie writes:
>Beyond that conceptual problem, if I understand what is going on here,
>you're second password string actually changes the password? This is
>a horrendous security problem and really ought not to be done in FTP.
>Better to just return an error (EXPIRED PASSWORD) and leave the user
>to correct the situation through other channels.

I absolutely concur. Implementations of FTP were designed to perform file
transfers, not the changing of authenticators used in login situations.
This leaves one with a situation where subversion of local software (not
normally regarded as a trusted implementation) would render distant-end
protection useless. I suggest you think this design issue out with a
security engineer, and I suspect that the median solution will probably
be something like Ron's suggestion above. We would never allow user
programs to control foreign host access; this is somewhat akin to doing
just that.

A couple of guidelines which might be helpful from a more generic stand-
point: [PassMgtGuide85]

        4.2.2.3 [Password] Change Procedure
             ...If the change is necesary due to an expired password,
             the user should be so informed. The user should be pre-
             sented with a brief summary of the major steps in
             changing a password, including a caution that the user
             should ensure that no one else is watching what the user
             is doing. ... The user should then enter the new password
             twice so the procedure can verify that the user can con-
             sistently enter the password correctly. The new password
             should be obliterated by techniques such as overprinting
             or terminal screen erasing. ...

While it is true that many (tho not all!) UNIX implementations include a
passwd program that gives instructions, some do. The more important con-
sideration is immediate: Few FTP implementations here (none?) keep the
value supplied for ACCT from being displayed. Further, it's true that several
implementations of FTP don't even protect the PASS value when it's entered
(unlike 4.3bsd UNIX implementations)!

        4.3.2 [Password] Entry
             ... It is recommended that the system not echo pass-
             words that users type in. When the system cannot pre-
             vent a password from being echoed ..., it is recommen-
             ded that a random overprint mask be printed before or
             after the password is entered, as appropriate, to con-
             ceal the typed password.

             The complete password as entered by the user should be
             an exact match, character for character, with the user's
             current password.

And, of course, using the ACCT feature won't allow for retyping the password
for correctness, which is a big "lose."

Think this out again and let us know what you decide.

Kurt F. Sauer
Tulsa, OK

----------
References:
[PassMgtGuide85] National Computer Security Center, _D_e_p_a_r_t_m_e_n_t__o_f__D_e_f_e_n_s_e
        _P_a_s_s_w_o_r_d__M_a_n_a_g_e_m_e_n_t__G_u_i_d_e_l_i_n_e, Report CSC-STD-002-85 (Fort George G.
        Meade, MD: NCSC), April 1985.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:15 GMT