6 ways developers can build in better password security

6 ways developers can build in better password security

Passwords remain by far the most commonly used method to authenticate users to applications and systems, despite long-standing efforts by technology industry leaders to find more secure alternatives.

The growing number of attacks involving the theft or compromise of credentials over the past few years has focused more attention on ways to bolster the security of password-based authentication mechanisms, including multifactor authentication mechanisms, the proliferation of password management services such as Dashlane and LastPass, and the growing use of technologies such as strong encryption keys.

A June 2016 survey of 600 security professionals found that 69% didn’t believe usernames and password are strong enough. Though 75% of the companies surveyed employed usernames and passwords, only 7% relied on them solely. Multilayer authentication, such as knowledge-based authentication, and two-factor authentication, has become standard practice for many organizations, while behavioral analytics and biometrics are poised to grow dramatically.

Despite such trends, passwords are likely to stick around for many more years, because there is a password involved in nearly every aspect of enterprise IT, from the desktop logon to the most sensitive operations of IT in the data center and cloud, said Jonathan Sander, vice president of product strategy at Lieberman Software. 

“For every place there is a password, there is a way to use those passwords badly.” 

Here are six essential ways developers can go beyond the security of simple password-based authentication.

SANS 2016 State of Application Security Report

1. Add controls for minimum password length and complexity

Developers must implement controls for enforcing a minimum length and complexity requirements for all passwords that are used to authenticate user access to enterprise systems.

Longer passwords that employ a combination of alphanumeric and special characters are considerably harder for an attacker to guess than simple short ones. While few passwords are 100% secure against brute-force attacks, the goal should be to increase entropy to the fullest extent possible without making passwords inordinately long or overly complicated.

Recommendations on ideal password length and password complexity vary. Organizations such as the Open Web Application Security Project (OWASP) consider passwords with fewer than 10 characters to be weak. There is little agreement, though, on what constitutes a password that is just right or too long, with advice ranging as high as 160 characters. In its cheat sheet for secure password storage, OWASP, for instance, considers a 160-character password to be of reasonable length.

The goal of supporting a higher maximum length is to encourage users to use a passphrase to authenticate access to an account rather than a simple password. “Require complex passwords that incorporate letters, numbers, and special characters,” said Lamar Bailey, senior director of security R&D for security vendor Tripwire. But at the same time, “don’t go overboard on password length,” he cautions. “Requiring passwords that are too long causes people to write them down somewhere,” undermining the security of the password in the process, Bailey said.

Applications should also enforce the use of complex passwords. OWASP encourages supporting mechanisms that allow almost any character that the user can type, including the space bar, to be permitted for use in creating a password.

“Putting a policy in place that forces users to select longer, more complicated passwords will help increase the security of their accounts,” said Michael Patterson, CEO of malware incident response company Plixer.

2. Require multifactor authentication

Requiring users to submit one additional credential for verifying their identity beyond just a password is a relatively painless yet surprisingly effective mechanism for bolstering the effectiveness of password-based authentication.

Banks and several government organizations have for some time now required users to verify their identities using something they know, such as a password, and something they possess, such as a smartphone or tablet to which a verification code is sent as an SMS message. Biometric identifiers such as fingerprints and irises are also being increasingly used in multifactor authentication schemes, as the TeleSign survey showed.

Multifactor authentication makes it much harder for an attacker to break into an account with just a stolen username and password. It can also help discourage brute-force attacks that involve the use of high-speed automated tools to try to guess stored passwords for the same reason.

“One of the first layers of security [that] organizations should implement beyond usernames and passwords is two-factor authentication,” said Ryan Disraeli, co-founder and vice president of mobile identity management company TeleSign.

“Beyond two-factor authentication, I would recommend organizations use some sort of data-based risk assessment tool to help proactively block fraudsters.”

Examples include building device reputational controls, behavioral biometrics, IP tracking, and challenge-response protocols into applications to ensure secure password-based authentication.

But MFA is by no means perfect. The US National Institutes of Science and Technology (NIST) earlier this year concluded that SMS-based two-factor authentication is simply not strong enough because SMS messages containing authentication code can be intercepted and used to gain illegal access to systems.

The NIST has recommended that, where possible, government agencies should phase out the use of SMS-based authentication over the next couple of years and consider other alternatives, such as one-time password (OTP) tokens. Developers should take heed of the advice and consider alternatives to SMS.

3. Consider controls for adaptive authentication techniques

Dropbox announced in September that it had reset passwords to 68 million accounts as a precautionary measure after someone dumped them online along with the accompanying email IDs.  The passwords were stolen in an intrusion at the company in 2012 and were all salted and hashed, ensuring they couldn’t be easily cracked. Even so, the company’s decision to force a password reset showed just how long stolen credentials can lie dormant on the web, said Stephen Cox, chief security architect at SecureAuth.

Incidents such as this show the importance of not just protecting credentials, but also being cognizant of the context in which they are used, he says. “Adaptive authentication puts additional safeguards on the credential [by] performing risk analysis against the authentication transaction,” Cox said.

Examples include controls for determining whether an authentication attempt is originating from a known bad location or an anonymous proxy, he said. “In addition, the organization could implement adaptive authentication in a way that, in addition to the credential, requires something the user has, or better, something the user is,” such as is accomplished with biometrics.

Other adaptive controls that developers should consider implementing for protecting password-based authentication include behavioral biometrics and behavioral analytics, Cox said. “Does the user's keystrokes and mouse movements appear to deviate from their normal pattern?” he said. “Does the users logical behavior patterns [such as the] systems that are being accessed, appear to deviate from their normal pattern?”

4. Enable single sign-on

One of the most effective ways to address poor password security practices is to implement a single sign-on (SSO) capability with multifactor authentication support, said Sander.

A software- or hardware-based SSO system eliminates the need for workers to remember multiple long and complex passwords to access different enterprise apps and to change all of those passwords on a regular basis.  With SSO, a user has to log into the network with a username and password just once to be automatically signed into all other applications and network services to which the user is entitled.

Some enterprise SSO systems work by replacing multiple passwords and usernames with a single authentication credential such as a password. A token is created when the user first logs into the system, and that token is then used to automatically authenticate the user to other applications.

In other models, a central credential server stores all the different credentials that an employee might use to access enterprise applications and then brokers access to the different apps on the user’s behalf.

Numerous options are currently available in the market for building portals where users can enter one password and use a highly secure, multifactor login to get access to multiple applications, Sander said. “There is little excuse not to make this a priority,” Sander says.

“This also allows you to make the passwords for all the applications inside that portal extremely secure since users will never have to deal with them directly and the portal isn’t going to complain if the password is massively complex and changing often.”

There will always be some systems in your organization that are resistant to SSO, Sander conceded. “But if the user needs only manage their portal password and a few others, they are in much better shape than they had been with every single application password on its own,” he said.

5. Make sure passwords are stored securely

Hashing user passwords makes them harder to crack than passwords stored in clear text, but only barely. Numerous attacks in recent years have shown how attackers can strip away hashing protections from passwords relatively easily using automated tools containing already-computed hashes for virtually a limitless number of passwords.

That is why a process known as "salting’"has long been considered essential to secure password storage. Salting is a process whereby a random string of cryptographically strong characters is appended to a password before the hashing process takes place. Salting creates a password hash that is almost impossible to reverse engineer in a manner as to expose the original password.

Developers should implement salted hashing if they haven’t done so already, says Bryan Schmidt, security consultant at MWR InfoSecurity. The failure by developers to salt passwords before hashing them has resulted in a staggering number of user account passwords being hacked, he says, pointing to huge password leaks at LinkedIn, MySpace, Tumblr, and other companies earlier this year.

“Salting doesn't ensure that a password will not be cracked, especially if the password is weak to begin with,” he said. “[But] salting significantly increases the difficulty of a successful crack and is regarded as an industry accepted best practice,” Schmidt said.

6. Lock down privileged passwords

Passwords to accounts with privileged access to sensitive data and critical systems are extremely powerful. Systems and network administrators use such accounts to maintain, administer, and update systems.

“If attackers are able to get their hands on privileged account credentials, the levels of access they provide can allow the attacker to establish a beachhead on the network and move about freely without detection,” said John Worrall, chief marketing officer at Cyberark, a vendor of software for managing privileged accounts. “They are then able to easily infiltrate systems and exfiltrate data.”

Large organizations can have literally thousands of such accounts, a vast majority of which are unsupervised or undersupervised.

For developers, the goal should be to implement processes and controls for enforcing secure use of privileged credentials in their applications.

“Best practice for privileged passwords means inserting a process that will ensure that each use of administrative authority is authorized and tracked,” Sander of Lieberman Software said.  “That starts by making sure that these highly sensitive passwords aren’t in the hands of humans.”

The OWASP’s access control cheat sheet recommends several approaches that developers can take to control what users with different roles can or cannot do with their application access.

For example, developers can consider implementing a role-based access control framework that gives administrators a way to determine what actions a user can take, when, and under what circumstances. Another approach that OWASP suggests is a discretionary framework that gives administrators a little more leeway in determining what users can do with their access. Other models that it suggests are a mandatory access control approach and a permission-based access control framework.

To reduce the privileged access threat, consider also the idea of eliminating embedded credentials in application scripts and configuration files. SSH keys and hard-coded, embedded passwords provide an easy target for cyberattackers when they are left unprotected, Worrall said.

But few organizations dedicate the time and resources needed to secure, manage, and rotate these passwords on a frequent basis to mitigate this risk, he said. As result, organizations are often vulnerable to attack from embedded application credentials. The best option, therefore, is to eliminate them altogether.

Building it in is building it up

The studies and experts who point out how bad password control is in the enterprise and what a huge risk they present often leave out the simple fact that no human can reasonably be expected to manage so many passwords that are so completely different, Sander noted.

So it is up to the developers to enable controls in their applications and services that ensure that passwords are used with security and management best practices in mind.

SANS 2016 State of Application Security Report

Image credit: Flickr

Topics: Security