Thanks a lot for the thoughtful responses. The following things are clear from your mail. - We may not be able to interrupt the install of openhpi as it may be installed as part of the system and distributions control the process. - We may not be able to provide the password or paraphrase during the start of the daemon as it is started automatically. The stdin/stdout are also blocked. - We may not be able to change the passwords for many many systems and encrypt each one of them independently as it is cumbersome. - We need to look at the existing solutions for managing the security instead of implementing everything in openhpi.
Looks like build generating its own key during the build could work and it could become part of the optimized code (not generated during debug build). Using the "current time" to the nanosecond accuracy could help. We need to make sure, the build does not print the key. Had a chance to discuss this problem with some people here. One of potential solution was to use the one way encryption, the same way password logins are executed. Here are the thoughts - Have a tool to create the openhpi.conf file. The tool takes the password and stores the one way encrypted password in a file. Generates a key based on the password and uses the key to encrypt the openhpi.conf file. - When the daemon starts, it puts a message in syslog indicating it is waiting for the password and it opens a socket and waits for the user to connect using an application to supply the password. - Any client that is trying to connect to the daemon gets a message that the user has not provided the password to decrypt the openhpi.conf file. - Once the daemon gets the password, it can encrypt it and match the encrypted password with the stored file and generate a key to decrypt the openhpi.conf file and proceed further. - If the user forgets the password, he needs to run the tool to create the openhpi.conf file and the encrypted password file again. He will not be able to retrieve the credentials in the old file. What are the pitfalls or usability problems you could see in this approach? One thing that Anton mentioned in a previous message that we need to make sure the directory permissions and file permissions are valid before proceeding needs to be implemented as it is fundamental to security. Mohan On Wed, 2012-09-05 at 19:37 -0600, Bryan Sutula wrote: > 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 ------------------------------------------------------------------------------ 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
