Journey into Peril: Rolling Your Own Security and Access Control

Regularly, I come upon reports that customer accounts at a website have been compromised. Invariably, users are told to change the passwords to their accounts, and consider the password compromised if it was used on other sites.

Security reviews are part of my consulting practice. Reviewing the security of systems and packages is a routine activity. Not infrequently, I find that access to the data is controlled by a username and password, with the password stored as plaintext in an easily accessible database. When I encounter this practice, I tell my client that it is not secure and that no auditor should accept it. When I dig deeper, I generally find a dearth of accessibility and auditing controls.

Ironically, almost all of the shortcomings could be remedied through proper use of the host operating system facilities.

It may often appear easier to roll one's own security than to comprehend and use the operating system-supplied facilities. Unfortunately, rolling one's own authentication and security features is likely to generate compounding technical hazard and debt.

The old European folk tale Stone Soup about three travelers in search of food is apropos. In the fable, local townspeople are unwilling to provide the travelers with food. The travelers then claim to be able to make soup from a kettle of water and three stones. The travelers then say the soup is improved by the addition of a series of extra ingredients, which they request one at a time. Ultimately the ingredients previously denied are received.

Roll-your-own security is similar. It seems simple, but security functions are not simple. With each incremental change the edifice becomes larger and more intricate. Security is not just about passwords and usernames; it is also about questions of logging, auditing, management overrides, and other related features.

Even a routine feature like password-controlled access has subtleties and complexities.

Checking a username/password pair seems straightforward. It is not complex to maintain an SQL database or a simple keyed file, indexed by username, with the password for each user. Such simplicity is at the heart of numerous system and web site compromises. These systems are commonly compromised by gaining access to the database. In many websites, SQL injection attacks have allowed such compromises to occur, at great expense to the victims and great liability for the website owner. If the system stores personally identifiable information (PII), there are additional legal and regulatory hazards.

Safe password storage is quite complex. Passwords should never be retrievable. Instead, they should be hashed with a non-reversible cryptographic digest function (e.g., SHA-256¹). Merely hashing passwords with a cryptographic digest however, is not sufficient. In today’s computing environment, an attacker could with little difficulty produce a dictionary of possible passwords and compare it to the contents of the downloaded authorization database. One must include a salt value, preferably of high entropy (e.g., time of last password reset), to make dictionary attacks infeasible. This knowledge is the accumulation of decades of painful and expensive experience.

Access control generally requires more than password validation. What about access windows? Auditing? Reporting? The list is unlikely to remain short.

It is often objected: But our application is only used by small organizations. Experience cautions skepticism. Small organizations grow. Unexpected opportunities arise. Regulations change over time and across jurisdictions. The boundary between what is too small and what is large enough to be regulated moves all the time. Re-engineering access control without creating incompatibilities with the original homebrew implementation is notoriously hard.

Modern enterprise-level operating systems, such as Microsoft Windows, Red Hat Enterprise Linux, and OpenVMS, have robust and extensive authorization, access control, and security facilities. These widely-used operating systems have full security and access control implementations. These implementations are designed to support all sizes of enterprises, from small businesses to the Fortune 10 and governments. Support is available for both standalone operation and as part of a wider network. Access control limitations are available. Reporting is available. Auditing is well-understood, and is supported out of the box.

Audits are a fact of life. Auditors and their requirements affect developers whether they are developing code and functionality for in-house use or for use by customers. It is important to remember that one's room to negotiate with auditors is usually quite limited. Audits are done to ensure integrity and compliance with external requirements and regulations.

Auditors work from standard sets of guidelines and principles. If one configures one’s environment with these guidelines and principles, audits can be relatively smooth. Deviate from these standards, and the ensuing audit can be complicated, time-consuming, and risky. Negative letters from auditors can affect insurance premiums and, for publicly-traded companies, stock prices.

Locally-developed security and access control schemes invite detailed scrutiny. By contrast, vendor-supplied operating systems generally have written best practices. There are typically cookbook procedures available to verify compliance with requirements; for example:

• List privileged accounts
• Verify login time restrictions
• Compliance with password policies
• List all valid accounts
• Verify that an access is revoked when an employee is terminated

Implementing all of the required infrastructure and documentation is onerous. When one uses an approach that is based upon and extends that the one supplied with the underlying operating system, the inevitable audit is far simpler than if the approach is developed locally.

Furthermore, locally-developed approaches often have shortcomings in conception and implementation due to idiosyncrasies of the present context. When the context inevitably changes, the security implementation must be modified.

In summary, the most efficient use of effort in both the short and long terms is to work within the security structures provided by the underlying host operating system, not to develop a separate security and access-control implementation within one’s application.

Notes

[1]SHA-256 standard

References

URLs for referencing this entry

• Home
• Services
  • OpenVMS
  • Windows
  • Printers
  • PostScript
  • Architectures
  • Networks
  • Embedded Systems
• Speaking
• Upcoming Events
• TechnicalCounsel^SM News Archive
• Ruminations – An IT Blog 
• The OpenVMS Consultant 
• Presentations
• Publications
• Technology Demonstrations
• Bookstore
• Contact Us