Plain Text Passwords in eDOCS PEOPLE Data Table

This is one among other security issues with OpenText eDOCS DM that requires attention. The explanation below is given to DM administrators along with my suggestion on how the issue can be addressed to prevent the exposure of your enterprise's documents.

If you look at the DOCSADM.PEOPLE table, you can notice the USER_PASSWORD column. Depending on for how long eDOCS DM was used in your company, you can find more or less records with passwords:

[SQL]
select  USER_ID, USER_PASSWORD, LAST_LOGIN_DATE from DOCSADM.PEOPLE where USER_PASSWORD is not null and ALLOW_LOGIN='Y'

These passwords are specific to DM, means that they have nothing to do with users' Windows account passwords, that is a good thing - Windows accounts are not compromised. However, the credentials still can be used to log into eDOCS server via eDOCS Extensions for Windows Explorer and Webtop (Cyberdocs). You can try.

At this point one may tell: 'Well, non-encrypted passwords in DB, who cares? Many old applications were written like this. Not so many people at our enterprise have direct access to eDOCS DB. Low risk. We shall be all right. '

The issue is actually worse than it may seem at the first glance. Here is why:

1. Potentially any person with read access to your DM database can find another user's password and then use it to act on that user's behalf, or may be just look at others documents. This intrusion is very difficult to detect if ever possible.

2. Anyone with write access to the database can set a password for another user, use it, wipe it out and no one would ever notice this was happening.

3. In fact, DM API has a 100% documented (read 'legal') method for reading these passwords in plain text as they are. Technically speaking, this grants read-only access to passwords to anyone with an existing login in DM. The method is a generic DM search service that is called with the following parameters:

SearchObject = "v_peoples",
Criteria = new Dictionary<string, object> { { "ALLOW_LOGIN", "Y" } },
ReturnProperties = new List<string> { "USER_ID", "USER_PASSWORD", "GROUP_ID", "NETWORK_ID", "LAST_LOGIN_DATE", "%FILTER_DISABLED_ROWS" }

It returns all people's accounts. The resultset can be easily filtered on the client side to find accounts with stored passwords.

4. DM API provides methods to anonymously write into the database! I have a separate post regarding this "feature" named SQL Pass-through. What it means for this breach is that DM API can be used to mock up passwords and then re-login with then on another user's behalf, same as item #2 above.

Items ##3 and 4 are very important to keep in mind. You should not forget them when thinking who has read-write access to your DM database. Potentially every DM user has.

Okay, what you, as administrator, can do to patch this breach.

• First, find the user account records with passwords and erase the passwords. 
• Second, ensure all your DM accounts are linked to user Windows accounts; never create or use DM-only accounts. 
• Next, create an INSERT and UPDATE triggers on the PEOPLE table to prevent passwords saving into the USER_PASSWORD column. 
• Last but not least, create alerts to notify yourself when there is an attempt to save a password into the PEOPLE table. It's up to you how you can accomplish it. This can be a tricky task.

Good luck.

Disclaimer:
The information here is provided as-is and without any responsibility of any kind. It is intended for eDOCS DM Administrators to help them understand the security issue and find ways of addressing it. The facts given are deemed true for eDOCS DM 5.3.1 P5 / DM 10 and earlier versions.