CTO TAlks

Privilege systems - Who is what?

Building privilege systems for shared files in identity-less environments

A common question for security software designers is how to identify a user. This is especially important for “privilege system” designers, as the user identity determines what a user can, or cannot do within the system. In other words, unless the system knows who the user is, privileges cannot be applied.

It’s all about authentication, most might say. The software would have to implement the mechanisms required to authenticate the user, binding the result to an identity. Systems that are meant to enforce privileges on files that are shared globally and kept at multiple locations meet lots of obstacles when striving to meet this type of security requirement. The file’s security attributes only hold the information on who can do what, but the file attributes have no clues on which user is accessing it. The application working with the file has to have the means to find out.

Some would say it’s impossible to authenticate a user at all times. At least not with high enough accuracy, taking into account the required level of security, existing infrastructure, or real-life human workflows (which always tend to break down the security mechanisms involved). Related issues have been hot topics for discussion amongst application security designers focused on coming up with solutions to authentication problems that range from a password policy not enforcing a strong enough password allowing for account intrusion, to situations where multiple applications working together use different credentials when authenticating to access a server. A classic example of the latter would be when a user has a SharePoint session open using a site-manager account, while having an add-in application authenticating to access the SharePoint server using Windows authentication, thus not necessarily sharing the same content privileges. The issue is that when a user action is triggered from Internet Explorer’s SharePoint session, the add-in might lack privileges to perform it. This identity mix-up can be seen when Microsoft Word edits a document residing on SharePoint.

For an application to authenticate a user while offline requires the software to have access to some sort of user credentials. Using PKI methodology this would require the software to have access to a user’s private key, and use it together with the public key to identify the user. This is a widely used technique with high precision, but requires access to all domain users’ certificates in order to define the privileges. For file privilege systems, working with files shared between hundreds or thousands of users, this will be problematic. Also, any user working with the file has to carry the certificate with him and possibly install the certificate on the machine where access is required. Furthermore, PKI has other drawbacks such as high cost and high maintenance, and is trust-based rather than being fact-based. Don’t get me wrong, PKI is a great contribution in many aspects to the world of IT security, but might not be ideal when designing privilege systems for shared files.

The type of identity most privilege-systems should strive to retrieve is a globally unique identifier for the user. This could be a certificate-based ID, or the SID retrieved from within a running thread. A SID however can only be reproduced within a domain where it belongs, and shared files might need to be accessible from anywhere. Processes attempting to access the file on a machine outside the domain will not be able to get the correct SID, even though the real-life user is the same, making identification impossible.

Another method of identification would be to validate the user’s credentials, either using Windows authentication through a remote server or through some sort of validation procedure locally. Resolving identities using a domain server will, however, require its availability unless the software has been built to imitate the domain controller to perform a local form of Windows authentication, challenge-response style. This means the application would prompt the user for the username and password, and be able to determine the user’s identity without the need for a domain controller. This method also has its limitations and will only be available after the user has been identified using Windows authentication once.

As login credentials are inaccessible in the OS at the application level, or rather meant to be, many systems stretch their imaginations in order to access them. A common practice for Windows applications is (soon to be was) to replace Windows ‘Gina’ to get the password of the user. The application would do this to achieve ‘Single Sign-On’ style user identification. This is a popular design in some hard drive encryption solutions out there. Some applications, interfering with Gina, even store the username and password for later use. I’ve seen major players within the security industry store the credentials as plain text in the registry as it had to be used later by a spawning process. Besides being insecure, this also causes problems the day the user changes his password, where the application would have to break new barriers to compensate for it. Sigh.

An alternative to applications using external identities would be for an application to provide its own, with its own login credentials. This is not the most appreciated tactic as a fast-paced work environment can be full of people with enough PINs, usernames, passwords, challenge phrases, ‘lost password’-answers, and keys in their pocket already. Buzzing out SSO was the security industry’s attempt to get rid of this problem. Yet success is limited.

One way or another, the previous examples of authentication methods require the identity of the user to be known somewhere. In real life, the identity of an intended user might only be envisioned. It might be that a document is intended to be opened only by consultants in read only mode. The consultants ‘group’ might, at the time of privilege creation, not even be defined anywhere. If this is the case, any authentication methodology that requires user identities to exist to be able to define their privileges will prove to fail. This includes Windows identities, certificate identities and so on.

The above example means that the credentials used at the time of access should be enough for the privilege system to identify the consultant and assign the reader role. This would mean that the document can be passed over to the consultant together with the login credentials for them to use. In other words, the password used will determine the user’s identity. This indirectly means these identities might be shared between several users. Privilege systems should limit shared accounts from accessing actions where individual identification would be recommended, but it might be good enough for reading documents.

Something to keep in mind is that identities belong to a specific namespace. This means that identities are often treated as being non-existent outside the world in which they were created. An example: Windows RMS with USB flash drive security definitions would break as soon as you move the memory stick outside the organization. The logic of this is that a foreign system can’t possibly be expected to authenticate any referenced user, or necessarily understand the file’s security attributes. One could argue that this is good if the USB flash drive wasn’t meant to leave an organization, or if privileges weren’t meant to be applicable.

This reasoning is legitimate from a technical standpoint in that there are cases where privilege-systems are merely seen as built up by a set of software locks. In a simplified view it would mean that if you can’t enforce the accessing logic, you can’t enforce the privileges! In other words, to have file privileges work on any foreign machine you need to install the drivers to enforce these rights. By completely changing a file’s format through encryption, existing foreign systems will require software to be installed, as they can’t access the file’s content otherwise. This will lead to embedded privileges being used as they come with the software.

Cryptzone’s eFile concepts can be setup to utilize embedded privileges in this manner and eFile Standalone Executables deliver privilege enforcing logic distributed and tied up with the file or folder itself. Any file format is supported. Our mantra is that if a file moves, privileges should move with it wherever it goes.