Protecting Log In Info

[Sivakatirswami]

Interesting solution and since we have our own server, very doable.

(musing ) Though since the user would needs an ID and log in to  
access the server (which one must send to them some how, by email,  
fax, telephone)  not sure how much more that gets you than just  
giving the them the FTP log ins directly (which you would need  to  
give them the same way... if it was not in the stack)... i.e. why not  
just give them the FTP log in ID and PASS in the first place? I  
suppose because it is less like that single user log in is less  
likely to get distributed. and if it did, you would know right away  
which user's log in was being abused...(assuming your CGI keeps a log  
of the first tier authentications)  where as if you distribute the  
FTP log ins, then from a given log.. you will never be able to tell,  
who is abusing it.

In this case I would open up the FTP access to a CHROOT virtual  
domain on the server that was not even on the global DNS matrix, to  
be accessed strictly by IP, with all PERL, PHP, and SQL processes  
turned off... pretty hard to abuse, other than a service attack  
(start uploading gigabytes of stuff...)

tks

Sivakatirswami


On Jun 03, 2005, at 2:54 AM, Dave Cragg wrote:

> Where I've had to do this before, I had the the client app load the  
> FTP credentials from a stack held on a web server. The stack was  
> obtained through a CGI which authenticated the request. In this  
> case, the client app itself also had a login system with ID and  
> password, and these login credentials were used as part of the  
> authentication process in the CGI.
>
> It wasn't completely secure, but by keeping the credentials on the  
> server instead of embedded in a local stack, it enabled changing  
> the FTP user name and password at any time.
>
> Dave