Early Unix operating systems, born long before the rise of the Internet, used a single flat text file to store user information including credentials. To prevent users from seeing each other’s passwords, a one-way hash algorithm was applied to passwords prior to storing them in /etc/password. Passwords entered by users were transformed using the same algorithm, and the results compared. Since many people used (and continue to use) short passwords, one attack against such as system is to calculate hashes in advance.
To defeat this, random data called a salt is used as an additional input to the one-way hash function. Unless the attacker has the nearly infinite resources required to precalculate hashes using every possible salt value, this effectively precludes the attack. In the mid-1980s, SunOS moved the hashed password information to a separate file, called the shadow password file, that was only accessible by privileged users. This was implemented in Linux in 1992. Sadly, while salting and hashing passwords remains a best practice, the protection afforded stored passwords has evolved very little in three decades.
According to W3Techs, WordPress is by far the most popular content management system (CMS), powering approximately 25 per cent of the world’s web sites. WordPress uses a single set of credentials to access a MySQL database. In practice, those credentials give WordPress all privileges on the database. The credentials are stored in a .php file within the web server document root directory, making them accessible to the HTTP server, WordPress itself, and every add-on theme and module that executes. User credentials are stored in a database table.
WordPress is one slip away from a credential table compromise. A single bug, malicious plug-in, or web server misconfiguration could put the list of users and hashed passwords on an underground hacking site. Or passwords could easily be changed. Alarmingly, the vast majority of web applications make the same architecture mistakes.
The root cause is obvious. Almost every web application developer ends up developing or re-using a poorly architected authentication system. A carefully designed, easy to integrate, free open source solution is desperately needed.
Password salting and hashing, while mandatory, should be considered a last line of defense. The overall system architecture should be designed to isolate the authentication system, including credential store. That includes placing it on a separate physical or virtual server in a high security zone, using a firewall to isolate it, and restricting administrative access. To reduce the potential for lateral attack, only indirect access (via a jump server) and two-factor authentication should be required. Logical controls should prevent administrators from connecting via RDP or SSH directly from their PCs.
All authentication requests should be forced through a single API over an encrypted, mutually authenticated communication channel such as HTTPS or TLS with client certificates. When an authentication failure occurs, the authentication subsystem should create a few second delay, preferably with a random element, and then respond with an authentication failed message. No additional information, such as the reason for the failure, should be provided. For successful authentications, the subsystem could respond with additional information (such as user or role information), but the primary focus of the subsystem should remain on user authentication.
For most applications, two-factor authentication should be considered mandatory, but to avoid aggravating users it need not be invoked on every authentication. It is entirely acceptable to issue 30-day cookies and only require the second factor when the cookie expires or another unusual event occurs.
Rather than punishing users with unnecessarily complex passwords and forced expirations, emphasis should be placed on detecting account abuse. For example, invalid password attempts should be automatically correlated both by attempted user and source IP. Depending on circumstances, the system could respond by blocking the IP or user for a predetermined period of time, invoking additional anti-automation measures such as a CAPTCHA, and requiring successful two-factor authentication prior to allowing access to the account or from the IP addresses involved.
Notifying users of security-relevant events can help in some cases, but it can also be used against the organization. For example, during a brute force attempt, generating messages to users does nothing to improve their security or that of the system. On the other hand, notifying users of successful authentications from new devices or geographical locations may lead to rapid impersonation detection.
Finally, logging is critical. Authentication systems must log all relevant information, and preferably provide a single log message summarizing each authentication request and result in an easy-to-parse format.
Have a security question you’d like answered in a future column? Eric would love to hear from you.
SAMSUNG GALAXY S8 PLUS
The Samsung Galaxy S8 Plus is a beautifully crafted smartphone with nearly no bezel, curvaceous in design and reflects a…
How to: Connect to Exchange Online Using Multi-Factor Authentication
Using PowerShell to manage your Microsoft cloud services like Exchange Online and using multi-factor authentication (MFA) separately is awesome. Using…