Your approach has a number of usability and security issues. But that's not the fundamental issue. One-way encryptions has it's uses, but it offers no protection for someone with root access (as they can change the keys to whatever they want). And I'm not sure of the point of storing the key someplace. If someone enters the wrong key, you will know.
Putting keys in binaries is just a bad idea. They are all the same and they can't be easily changed. A recipe for a security disaster. That may sound harsh, but designing good security procedures is *very very very* hard. Anything that requires human interaction (like connecting to a local socket) is just not going to work in a large server farm or a remote telecom system. That's fundamental issue #1. Fundamental issue #2 is that the credentials in the configuration file are for connecting to other systems. You have to have the original credentials, and openhpi has to be able to read them. Put another way, the credentials have to be stored in a way that openhpi can read them and use them for connecting to remote systems. If openhpi can do this, then *anything* on the system with equivalent privileges (like root) is going to be able to do it. You can go through all kinds of machinations, but in the end, that is the bottom line. Something can always open the openhpi process memory image and pull the password out. That's not as hard as it sounds. You could use selinux to help here, and perhaps provide a tool for updating the configuration file and only give that tool and openhpi access to the file. Setting up selinux is a big job, but it's not nearly as bad as it used to be, and if you really are concerned, IMHO that's what you should do. Validating proper permissions is, of course, a good idea. -corey On 09/06/2012 12:52 PM, [email protected] wrote: > 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 ------------------------------------------------------------------------------ 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
