Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!pbox!romed!svo!okstate!ks From: ks@a.cs.okstate.edu (Kurt F. Sauer) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple 331 password responses in FTP protocol Message-ID: <2536@okstate.UUCP> Date: Mon, 7-Sep-87 14:44:56 EDT Article-I.D.: okstate.2536 Posted: Mon Sep 7 14:44:56 1987 Date-Received: Wed, 9-Sep-87 07:28:24 EDT References: <8709041634.AA11908@topaz.rutgers.edu> Reply-To: ks@okstate.UUCP (Kurt F. Sauer) Organization: Decision Studies Group, Inc., Box 701401, Tulsa OK 74170-1401 Lines: 64 Keywords: trusted path; ftp (file transfer protocol) Summary: Agrees that FTP is not the right place for password changes, and provides some suggestions for design criteria, with referen 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.