Re: static gchar security

On Tue, 2002-11-05 at 09:55, Jason A. Pfeil wrote:
> It would be *very* insecure.  Any root-level program could pick up that
> password very easily just by examining /dev/kmem.  Why would you want to
> store that password for the life of a program anyway?  It's standard
> procedure for programs that accept passwords to forget them immediately
> after receiving them and doing the authentication.
> --Jason

But isn't this the same issue as storing passwords in plain text for
programs like gaim? Sure a root level program can get at it but if your
root is not secure then nothing is.  If somone could get a root level
program to sniff passwords they could just as easly get one in to record
keystrokes.  On any multi user system you have to trust the admins.  The
only thing I would do would be to obfusicate the password so a casual
browser couldn't decifer it without some work.  Also, keeping a cache on
disk instead of in memory would eliminate the potential for someone
taking a snapshot of /dev/kmem and accidently give away your password to
an untrusted recipient.  Just remeber to set the permissions so that
only the user has read access.  Of course many secure things are stored
in memory (credit card numbers, contact info, pins, etc.) so I don't
realy see storing passwords as a problem.  It all comes down to the
security of the underlying system and its administrators.

> On Tue, 2002-11-05 at 00:41, Jacob Perkins wrote:
> > How (in)secure would it be to have a static gchar that would save a
> > plaintext password?  The gchar would start off null, but could later
> > contain a password, and is static for the life of the app.  Is there a
> > better way to do this?
> -- 
> Jason A. Pfeil                        pfeil 10East com
> Senior Open Systems Engineer
> 10East, Inc.                          (904)220-DOCS

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]