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.

--
J5

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          http://www.10East.com
10East, Inc.                          (904)220-DOCS





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