Report from course assignment assessing security of OpenMRS

Students in my Computer Security course assessed the security of OpenMRS as a class project. I have compiled the results into a report. I have attached it to this post. What is the best way to contribute this report to OpenMRS?

For your convenience, I have included the executive summary of the report below. The full report is nearly 200 pages long, currently available in Word format or PDF, or I can convert it to a WIKI format.

I am also happy to discuss any of the results.

– Dr. Steven P. Crain Assistant Professor Plattsburgh State University of New York Computer Science

Executive Summary

Students at Plattsburgh State University of New York conducted security assessments of OpenMRS during May 2015 and May 2016. Based on the assessments, we recommend specific improvements related to authentication, auditing and documentation.

Our assessment was based on HIPAA regulations, which provide important guidance with respect to the security of health information. HIPAA regulations would be directly applicable if OpenMRS were used in the United States. The students assessed the OpenMRS Core API, database and reference application with attention to access control, accountability and privacy. This assessment followed a well-documented procedure, and can be used as a baseline for regular repeated assessments.

One way that security professionals assess security is using the “CIA triad.” We found that OpenMRS is weak at protecting confidentiality, because, once users log in, they can access any protected health information without restriction and without leaving an audit trail. On the other hand, OpenMRS ensures that only authorized users make changes in the data and generally keeps track of significant changes (integrity). The students did not assess availability, as that is not a major concern in the HIPAA regulations.

Another way that security professionals organize assessment is using the “AAA triad.” OpenMRS has solid authentication and authorization support, but has inadequate support for accountability.

We also measured OpenMRS against commonly used design principles. We found that the overall architecture of OpenMRS was very conducive to security and that OpenMRS has done well at balancing security and usability. However, OpenMRS has some major security concerns. The default admin password violates the principle of fail-safe defaults. Also, there is no support for separating administrative privileges to different users.

From our findings, we determined the most important security changes for OpenMRS. Most importantly, the default admin password should be corrected by implementing a password expiration or password quality policy. Additionally, OpenMRS should implement session timeouts and account locking with repeated login failures. Although more difficult to implement, we provided some feature recommendations for a much-needed auditing system. Further, we recommended a section providing security guidance in the implementers’ documentation. Finally, changes should be made so that administrative responsibilities can be divided across multiple administrators. We believe that these recommendations will make a meaningful difference in the security of OpenMRS implementations.

OpenMRS HIPAA Assessment.pdf (1.7 MB)


Dr. Crain, thanks for doing this evaluation for us! it will help us know the risks and help us mitigate them. We also appreciate your prioritization of them for our community. @terry

Thanks for sharing this, and for the work the students did!

I haven’t had a chance to read through the whole thing, but looking at the Recommendations section:

  1. Force Change of Default Admin Password
  • This makes sense to me. We have a “require password change at next login” function, and we should enable it for the admin user on first login.
  • (In practice, a real world deployment of OpenMRS is a long process. Nobody just downloads and immediately goes live, so I think the actual risk is low.)
  1. Password Expiration
  • Generally we trust that implementation know how to make locally correct choices around things like required password strength, because they know their environment, the personas of their users, etc. So, I think this would be a nice feature to add, but I’d make it optional.
  1. Password Quality
  • We already have settings for this, but perhaps they need better documentation of them…
  1. Password Blacklist
  • Also a good suggestion
  1. Inactivity Timeouts
  • We already have this (it’s controlled via tomcat sessions, rather than via OpenMRS). If this feature is not working on some reference application pages (e.g. because there’s some periodic REST call that keeps the session alive) we should fix that.
  1. Excessive Failed Login Locking
  • This also already exists.
  1. Auditing
  • I agree that this also needs work.
  1. Document Security Design Decisions and Implications
  • Good point, that a section should be added to the implementers guide.
  1. Separate Privileges
  • This functionality already exists. (The demo setup doesn’t show it, but a prod implementation can set this up.)
1 Like

Thanks for the review. What a wonderful gift to the community! I would add to the list email support for self-service password resets. I’m not a fan of our single, home-made secret question challenge for password resets.

I found at least one mention of looking for existing issues (i.e., JIRA tickets at Any chance the students searched for or created JIRA tickets for any of these security suggestions? I wouldn’t be surprised to find existing tickets for some of them, but it would be great to ensure that we have tickets – especially for the items Darius has agreed with – and that they share a security label in JIRA.