>> I see the issue of obscured passwords as one of helping the innocent passerby or sysop respect the privacy of an individual's password.
It's not something that is designed to stop someone with 'evil' intent.
The next User Manager will obscure the passwords in the User Interface, but not enrypt them in anyway. <<
I thought I was not going to pen another security treatise, but...
The idea that hiding data is the same as increasing system security is a common misperception that can be dangerous to users and administrators if allowed to stand without clarification (as you just did by stating that it is not designed to "stop someone with 'evil' intent".) Making that change and statement of what you are intending to accomplish by it is fine, but the approach does not really make the system more secure. If stronger security is really a requirement, then other measures, much more ambitious than hiding the data behind bullets are required to implement it. If the intent is deter the casual curiosity seeker, then this, coupled with control of the CPU/disk holding the user data, is probably sufficient. The admin must also know that the UM and other utilities can be made to reveal the user passwords, so they should exercise care with access to those utilities, as well as access to the CPU/disk holding them. Administrators must recognize the limits of any security mechanism proposed or implemented, to understand what other measures they need to undertake if any.
The task for admins and the users who depend upon the systems, is to identify the requirements for themselves and can either ensure they can tolerate the potential for loss of their data, or losses incurred through un-intentional or inadvertent disclosure of their data to other parties or accept the task of increasing the security on their systems to get to where they need to be.
I have seen a rainbow of assaults and attacks on different systems, and the ones I feel least comfortable with are those that can exploit the plaintext login/passwd process over a TCP connection. This one I can currently do nothing about, if I want to retain my internet connection (which, of course I do). The extent of exposure to the attack extends almost from begining to end of the connection, involving systems on my ISP's lan, his WAN connection, systems from the users' ISP, LAN, and WAN connections, and each host the TCP traffic passes through between sender and receiver. My intent in stating this is not to scare anyone but to educate them in the risks of plaintext transmission via TCP/IP. Each site should take precautions to prevent packet trapping and analysis, but don't count on it, because not all ISP personnel know how to detect it, track it down and stop it.
The next highest vulnerablity I see are the "human factors" attack on a system. I have a small user base and can easily set up conditions where I determine if the person desiring a reset passwd is actually who they say they are. The larger and geographically diverse the userbase, the harder that one is to do. I think the common way of handling it is by use of a third user-selected keyword or phrase that associates a user with their account, that is different than their login or password. If the caller knows that keyword or phrase, (that they should have saved someplace safe for such a rainy day) then the request to divulge or reset the password is accepted. The burden on the admin is that they must maintain that data as well as the users regular login data with the same level of security as the login/password pair.
I understand the difficulty of implementing a secure login process, and have been recently researching various methods to address it. Use of a public/private key combinations in combinations with encrypted transmissions looks real promising, but would probably slow down the registration as well as the login process and subsequent transfers if used fulltime. If encryption could be limited to registration, login and password change operations, then the performance penalties would not be as severe.
Again, this statement is not meant to disparage, only to address the issue head-on.
--- Daniel O'Leary, Sysop KloneZone Mac - A TeleFinder 5.6 BBS * TFDEV Network Hub 532 Verna Trail North, Fort Forth TX USA 76108 Voice=> (817)367-2558 Dial-In=> (817)367-2712 Fido=> 1:130/1015 TFNet=> klonezone.tfnet.org Inet=> kz.eaze.net www=> http://kz.eaze.net
