ProjectsUser...safepwd -...

safepwd - Shadow Credentials for Your Program Binary

Thursday, August 19, 2004 by digitalpeer

This is a Linux application that validates a parent, invoking binary and returns associated passwords to it. This creates a application -> password validation and not a user -> application validation.

An Example for Needing This

This is a secure solution to applications that need to have credentials embedded in them to access something else. Of course, this will only be valid for a local network and doesn't really apply to Internet applications and the like.

Say you need to access a MySQL database with your application. You have it all setup to do that, but now you have to include the password in the binary or even worse, in the source code. Considering that your application is an open source application, it makes your compiled in credentials useless and your database wide open. What this will allow you to do is query credentials stored in a protected file, only accessible through the safepwd application. This is similar to how Linux shadowed passwords work. However, while this system relies on Linux file permissions, it does not use Linux accounts.

How it Works

safepwd and safe.txt are stored somewhere on your network. safe.txt is only readable by root or some other user. safepwd, when invoked by any user, runs as root so it can read the safe.txt file (chmod u+s safepwd).

safepwd is invoked as child process in your application. safepassword will then compute a MD5 hash of your application binary and based on that, supply it with the password it needs from a password file. This ensures that only a validated compilation of your binary has access to the credentials. The user never even sees any of this nor does he or she have access to the credentials themselves. Your credentials are stored safely in a remote file and not in the binary or world readable files. Any user can run your application and have access to your database soley through your application.

This can be extremely useful if you have an open source application and a bunch of users that should not have access directly to your database by any other means than your application.

Making it Work

See the INSTALL file in the root of the source code.

Advantages

• Seperate credentials and other information from your binary. This way you can change them without having to re-issue a new binary.
• Provide only verified binaries access to the credentials.
• Hide credentials from the user of your application.
• Provide verification that nobody has modified the application to access the credentials.

Drawbacks

• You have to add hashes of each of your binaries and associated passwords to the safe password file (big deal right).
• This will only work for applications on your local network.

Possible Security Breaches

I can't really think of any right now. Please let me kow if you think of a way around this. This was pretty much a quick solution for a problem I've always had.