The users directory is off limits if you follow my installation instructions. It's true that you can still eavesdrop but I hardly think it is a problem. Compare this with handing over a credit card at the restaurant. Do you really know if your credit card wasn't swiped twice, or how about that checking account number which is on your check.
I think we seem to forget that it is easier for a crook to get information from a shady clerk than it is to drive around the neighbourhood listening in on airwaves or wiretap a phone line. Dieter Simader http://www.sql-ledger.org (780) 472-8161 DWS Systems Inc. Accounting Software Fax: 478-5281 =========== On a clear disk you can seek forever =========== On Mon, 11 Nov 2002, Mark Hedges wrote: > > > If the encrypted password can be read by the web server from > users/members, and the encrypted password is the string used to > authenticate in the get/post requests, it seems like there is no > real security provided by the encryption, because the encrypted > string is used as the secret, rather than the unencrypted > password... and it isn't very secret. > > To be useful, it seems like the unencrypted password should be > used to login, and then a one-time session-id hash should be > generated to maintain authenticity for a single session in the > get/post requests. Access via command line should require an > initial login with the actual secret password to obtain the > session-id hash which is good for a limited time and corresponds > to an IP address. This way an eavesdropper cannot simply pull > the encrypted password string from the members file to use for > access. They would have to know the actual password, which is > the point of the encryption. > > Apache::Session and CGI::Session are mature CPAN packages that > can handle this in a secure way. > > --mark-- > >
