I'm still not sure we can completely protect these passwords (or any credentials) if the attacker has root access. Nevertheless, comments below.
If the Red Hat or SuSE packagers are still watching this list, perhaps they have ideas or input on what follows. On Wed, 2012-09-05 at 10:30 -0600, [email protected] wrote: [...] > Clear text passwords are frowned upon nowadays. Encrypting the conf file > could help. A malicious hacker could get into the file as it is an open > source. We could make it harder. Here are some of the things that I > could think of. > - Get the key from the user during installation and store > in /var/lib/openhpi. Encrypt this file using a default key. > - Decrypt the file to get the key and use this key to decrypt conf file. > > We could provide a tool to create the conf file. This tool could do the > above things. This tool could be run during install with some default > options or the user could run it later. I guess the idea is as good as any. However, any solution that becomes part of the OpenHPI install is in the domain of the distribution packager, not the OpenHPI project itself. In other words, OpenHPI gets to define how the application works, but the distribution (Red Hat, SuSE, Debian) usually controls how OpenHPI is installed. That said, the default "make install" for OpenHPI can certainly do the above steps. It would then be up to the individual package creators (Red Hat, SuSE, Debian, etc.) to use the same or a similar technique during their installs. > Please do share other ideas. Building on the above idea, the weakness seems to be that the Daemon source code needs to contain the "default key" in order to read the password file, to get the user defined key. Here is a variation on the idea: - During OpenHPI build, a random key is generated. This random key becomes part of the daemon's binary code, but is never part of the source code. Someone with enough time and patience could derive the key from the binary, but this would at least be difficult. - The same key generated above becomes part of an encrypting application that is supplied with OpenHPI. Again, it is only part of the binary, not the source code. - During install, user-entered passwords can be encrypted (and stored to /var/lib/openhpi) using the encrypting application, much as Mohan has proposed. Now some criticisms: 1) For major distributions, the build code must be totally automated. No user interaction can be required. So only a "make install" that generates it's own key can be used. 2) For some distributions, such as Debian, the output of the automated build is generally publicly available. It will be difficult, in these distributions, for the generated key to avoid showing up in the build output. (The simplest implementation would involve setting a "make" variable with the generated key, then passing the key into the daemon compile using "-D". But this exposes the key in the build output.) Maybe there is a way to use a temporary file to hold the key instead. 2) Again, for major distributions, the install code must be able to be totally automated. People routinely do automated installs in order to replicate systems. So requiring a user to be at the keyboard during OpenHPI install may not be a viable option. 3) People must be able to make changes to the OpenHPI configuration file, then restart the daemon. If they change the file, how do they get new passwords into the system? Do they have to re-enter all the passwords? Only the new ones? How is this managed? Is there a new OpenHPI application that looks at the conf file, determines what passwords need to be stored, and asks the system administrator for these? This seems to be a fairly complex application. What if there are 50 different systems being managed? Does the admin have to enter 50 passwords? Won't the sysadmin just keep these passwords in a file for reference, defeating the purpose of the exercise? When the passwords change (since IT departments are fond of requiring such changes), how do the new passwords get entered? Having criticized the ideas, let me offer that I think there are solutions to all the above. They are mainly offered to avoid some pitfalls as the code is implemented. But I think there will need to be a fairly substantial application to manage these passwords for OpenHPI. Lastly, having said all that, I wonder whether this sort of application has already been developed. Are there existing "keyring managers" that could be used instead of developing one specifically for OpenHPI? Best of luck, Bryan Sutula ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
