Bugtraq mailing list archives
Re: stored credentials was: Netscape 4.5 vulnerability
From: jogata () NODC NOAA GOV (Jefferson Ogata)
Date: Fri, 23 Apr 1999 17:06:33 -0400
What if the OS itself maintains a database of randomized encryption keys, 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 general terms. Here's a specific example. Netscape asks the OS for an encryption key via 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 kernel 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 user's password for storage in prefs.js. The encryption key then can only be retrieved by a user that can arrange that its own program have the filesystem.inode under which a key was stored, i.e. the owner of the directory where the binary is located, or root. Root could also just pull the key directly out of the database. I guess the original topic of discussion was the feasibility of a system that not even root could subvert. This doesn't qualify, but it does allow 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 registry 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äykkä wrote:
Well actually you can use one key/passphrase to secure all the stored credentials. This has the advantage that you dont need to rember all 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 passwortNo, no, no. You missed the point. We were discussing programs (or bunches of programs or even OSes) which store user credentials for later 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 interaction 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 want to access the encrypted credential information without user interaction (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äykkä, 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@{$/=$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 Center You can't step into the same river twice. -- Herakleitos
Current thread:
- Re: stored credentials was: Netscape 4.5 vulnerability Juha Jäykkä (Apr 23)
- <Possible follow-ups>
- Re: stored credentials was: Netscape 4.5 vulnerability Jefferson Ogata (Apr 23)
- Re: stored credentials was: Netscape 4.5 vulnerability Valdis.Kletnieks () VT EDU (Apr 25)
- Re: stored credentials was: Netscape 4.5 vulnerability Jay R. Ashworth (Apr 24)