[10341] in bugtraq
Re: stored credentials was: Netscape 4.5 vulnerability
daemon@ATHENA.MIT.EDU (Jefferson Ogata)
Sat Apr 24 13:22:58 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Message-Id: <3720E0D9.DA3A5AB3@nodc.noaa.gov>
Date: Fri, 23 Apr 1999 17:06:33 -0400
Reply-To: jogata@NODC.NOAA.GOV
From: Jefferson Ogata <jogata@NODC.NOAA.GOV>
To: BUGTRAQ@NETSPACE.ORG
What if the OS itself maintains a database of randomized encryption key=
s,
and allows access to a key only to a binary whose inode and filesystem
matches the one under which the key was stored. I'm being needlessly
specific here, but I lack the vocabulary to describe this in more gener=
al
terms.
Here's a specific example. Netscape asks the OS for an encryption key v=
ia
a system call. The kernel looks at the Netscape binary that made the
system call and makes a database key from its filesystem and inode. It =
then
checks in a private database for a record under that key. If the record=
is
found, its value is returned to Netscape. If no record is found, the ke=
rnel
generates a new random value, stores it in the database, and returns it=
to
Netscape. Netscape then uses the random value to encrypt/decrypt the us=
er's
password for storage in prefs.js.
The encryption key then can only be retrieved by a user that can arrang=
e
that its own program have the filesystem.inode under which a key was st=
ored,
i.e. the owner of the directory where the binary is located, or root. R=
oot
could also just pull the key directly out of the database.
I guess the original topic of discussion was the feasibility of a syste=
m
that not even root could subvert. This doesn't qualify, but it does all=
ow
programs to save encrypted passwords that can be decrypted only by the
program that stored them (or root) in a publically readable file. And I=
'm
sure there's something fundamentally flawed about it, because I'm not a
cryptography expert. I suppose it's not unlike using the Windows regist=
ry
to store a key generated by the program....? I suppose also that there =
are
ways to do this without adding a system call.
Another alternative would be to use a cryptographic signature of the
binary as the database key. This would make the system more tolerant of
a binary being relocated or restored from backup tape.
Any thoughts? Flames?
Juha J=E4ykk=E4 wrote:
>
> > Well actually you can use one key/passphrase to secure all the stor=
ed
> > credentials. This has the advantage that you dont need to rember al=
l
> > credential (which is impossible for secret keys anyway). But it has=
the
> > disadvantage, that the security is
> > a) breakable by trojans/backdooring
> > b) as secure as the (weakest) manual entered passwort
>
> No, no, no. You missed the point. We were discussing programs (or
> bunches of programs or even OSes) which store user credentials for la=
ter
> access WITHOUT the need for a user to supply any password, key or
> credential. Such as is implemented in netscape communicator when it
> stores pop/imap passwords in prefs.js. In this case the credentials
> stored by the program are indeed "encrypted" (XORed) but in order to
> enable the program to retrieve this information without user interact=
ion
> even after a system restart, the password used to "encrypt" the
> credentials is stored somewhere within the binary itself, the windows
> registry or even derived from the user name or something. Which ever =
the
> method, the password is easily reproduced and used to decrypt the
> credentials protected with it. There is no way around this when we wa=
nt
> to access the encrypted credential information without user interacti=
on
> (to be precise I should add: after a system restart). There can never=
be
> true security in such a system. End of story.
> What you propose is basically a Single-SignOn technique which still
> needs ONE passphrase. They are a totally different story and not the
> subject here.
>
> --
> Juha J=E4ykk=E4, juhaj@iki.fi
> PS See http://www.dcs.ex.ac.uk/~aba/rsa/ for latest version of RSA in
> perl.
> Here goes the RSA code in two lines:
> print pack"C*",split/\D+/,`echo
> "16iII*o\U@{$/=3D$z;[(pop,pop,unpack"H*",<>
> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"=
|dc`
--
Jefferson Ogata <jogata@nodc.noaa.gov> National Oceanographic Data Cent=
er
You can't step into the same river twice. -- Herakleitos
