Wow, this message generated a lot of comments... Glad to see the comments -- I hoped that this would do that and get people thinking. First, let me talk about what I WASN'T talking about! I wasn't saying the Unix *idea* (not necessarily implementation, as it is getting old) of encrypted passwords is bad! It is exactly how a server should store passwords. I wasn't addressing this. I was addressing CLIENT side issues. Example: xyz remote backup needs to log into a remote file server. So, xyz somehow stores an encrypted copy of the admin password. No matter how it does it, if it needs to find the original password, this is insecure. Yes, if you used an secure protocol such as SSH or Kerberos, it helps, but this wasn't what I'm talking about. I hear people complain that, for instance, (I know we aren't an NT list, but bear with me) NT SQL Enterprise manager stores the plain-text password for the SA account. People are happy if MS updates it so Enterprise Manager XORs the password with a hidden string, not realing this gives no real security. The fact Enterprise Manager needs to be able to know the password to be able to encrypt a salt and send it over the wire is the problem. Even if it can't be sniffed, we still have a problem. As you can see, I'm not talking about insecurities of "one-way" hashes or anything -- any algorithm I'm talking about is a two-way encryption algorithm. Now, I don't have all the solutions to this one. That's why I posted. Here's some things, though that I do know *HELP*: 1) Store the password (encryped or not) in a hidden file. 2) Limit the usefullness of the account the password belongs to 3) Change the password often, over a secure channel. Preferably everytime a server connects and proves it's identity (this is complicated, I know) 4) Never, ever, transmit the password in plain text 5) Don't allow accidental viewing of passwords. Here's a message I got, that I thought was a good idea. From: "David Vann" <netdocat_private> Subject: RE: Plain text passwords--necessary Date: Thu, 15 Apr 1999 16:54:34 -0400 Just for grins, they could use built in key management. This would be where the admins of the respective systems start out with a particular key that is common between them. Public / Private Key pairs could then be used to securely submit and decrypt a symmetric key. Asymmentric encryption (Public / Private Key pairs) would handle the key management while allowing the application to make use of the faster symmetric encryption. The key would change over a random period of time. That way if someone got the key, oh well... the key has changed 72 times since then... Idea.... Good or no? --- END FORWARD --- I hope this clearifies this issue a tad for everyone. Joel Maslak UPDATE -- Generate Web Traffic http://www.permission-marketing.com/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:42:41 PDT