Re: Profile Password Security

Gabriel Donnell wrote:

>Hello Guido,
>
>You provided some good alternatives to protecting the passwords for the
>profiles.  Below are my comments.
>
>Directory/File Access
>
...

>  Although I am big proponent of protecting file access with permissions, I
>  do not prefer that as a method to protect clear text passwords.
>
agreed

>Master Password
>  Protecting the passwords for the profiles with one master password that
>  decrypts the password file for a given DA process session is a good
>  alternative.  As long as the segmentation core dump will not expose the
>  decrypted file.
>
it will, that's why a master password won't work as a security measure.

>  The downside is that the master password would need to be entered for
>  each separate simultaneous DA process.  I run multiple simultaneous DA
>  sessions for different profiles.  If I have to enter the master password
>  for each DA session, then there is no need to store the password for the
>  profile.  I may as well enter the password for the profile connection.
>
>  For convenience, DA could be enhanced to support single sign on with the
>  master password.  That way a single DA process can open multiple
>  simultaneous connection windows for different LDAP accounts or profiles.
>
that's kind of hard to do,  there are a lot of assumptions in the code, 
and there's no provision for multithreaded access at all.

>Disable Password Storing
>  An option to not use stored passwords seems to be the best easiest
>  alternative to implement.  I do not mind entering the profile password
>  for each connection.
>
>  I tried leaving the profile password blank to see if DA would prompt me
>  for the password.  However, it does not.  It gives an "Access denied"
>  error message.
>
Yes, because there are cases when you might be allowed to log in without 
a password.  We need a way to store this preference in the configuration 
file (a plain text file called profiles in the .direc...ator folder 
inside $HOME).

>I am sure there are several good alternatives to implement.  I would not
>mind helping code the resolution.  However, I need to familiarize myself
>with the DA code as Manuel suggested.  I plan to do this soon.
>
I think we already have a patch for this (option number three, of 
course). I'll put it in.

>
>Regards,
>Gabriel Donnell
>
>__________________________________
>Do you Yahoo!?
>SBC Yahoo! DSL - Now only $29.95 per month!
>http://sbc.yahoo.com
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Directoryadmin-list] Directory Administrator Participation
> From:
> Guido Trotter <[email protected]>
> Date:
> Tue, 24 Jun 2003 10:20:21 +0200
> To:
> [email protected]
>
>
>On Mon, Jun 23, 2003 at 04:57:41PM -0500, Manuel Amador (Rudd-O) wrote:
>
>Hi,
>
>  
>
>>Well, I once got a patch to not store passwords in the disk, but i REALLY don't
>>remember where I put it so I lost it (that's why I encourage everyone to post
>>their patches to the patch manager, so I dont have to manage them myself hehe).
>>
>>Now, I think there is no point in storing the passwords encrypted on disk, since
>>anyone with the algorithm (OSS software process anyone?) will be able to get the
>>password anyway if they have physical access to the disk.  See above.
>>
>>    
>>
>
>This is perfectly right. Better to have the password stored in clear text
>than to encrypt them in a way that anyone can actually read. Anyway maybe
>there can be some palliative solution:
>
>The first one, already implemented, is to write the file in a way other
>users cannot read it (the ~/.directory_administrator directory gets created 
>with 0700 permission).
>
>Another one would be to have the option not to remember the password, and
>to ask it at connect time.
>
>The last can be to protect all the password in the file with a "master
>password", which is requested to use any connection. (but I think the
>second one is better)
>
>Bye,
>
>Guido
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: INetU
>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>_______________________________________________
>Directoryadmin-list mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/directoryadmin-list
>  
>