Month: March 2018

More than 90 billion passwords are being used across the web today, and it’s expected to be nearer 300 billion by 2020. With that in mind, the topics of password best practices and the threats around stolen credentials, remain top challenges for many global organizations.

Security Boulevard recently hosted a webinar with Shape and cyber security expert Justin Richer, co-author of the new NIST (National Institute of Standards and Technology) Digital Identity Guidelines. The webinar looks at how password protection and password attack prevention have evolved.

Key Takeaways

Traditional P@$$wOrd Guidelines Don’t Solve the Problem

Justin Richer discusses how passwords were originally invented as a way to gain entry. But today they have evolved into a way to authenticate who you are. Companies rely on a username-password combination to give them confidence you are who you say you are. So once passwords are stolen, companies have less and less confidence you are the person you claim to be.

To make it difficult for criminals to steal your identity companies have implemented complex password requirements. Unfortunately, this conventional wisdom around password management, such as enforced rotation every six months, using at least six characters, upper and lowercase characters, numbers and symbols, have made passwords hard to remember.

Additionally, for non-English languages, not all these rules can be applied regarding uppercase and lowercase. They also don’t always adapt to the world of mobile devices where it’s hard to type using touch screens, and the emerging technology of voice recognition personal assistants.

In the end, users reuse passwords that are easy to remember and pick bad passwords due to password fatigue. As a result, traditional password guidelines don’t help companies gain confidence—they are actually compounding the problem.

The Real Culprit – Password Reuse

In reality the problem companies are fighting is password reuse. Once one account has been compromised, the attackers have access to multiple accounts that use the same username and password. Fraudsters may use these accounts themselves, but often they bundle up the stolen credentials and sell the passwords on the dark web.

New NIST guidelines serve to help companies reduce password fatigue and reuse, while also providing suggestions for testing new passwords against a database of stolen credentials—a breach corpus. When the two are implemented together, fraudsters will have a much harder time taking advantage of stolen credentials through account takeover and automated fraud.

New Passwords and Using Blacklists

Revision 3 of the NIST password guidelines overview – Digital identity guidelines – has dramatically updated recommendations on how to use passwords properly:

Don’t rely on passwords alone. Use multi-factor authentication steps to verify the user is who they claim to be.

Drop the complexity requirements, they make passwords hard to remember and aren’t as effective as once thought.

Allow all different types of characters.

End the upper limit on size. Length can be an important key to avoid theft.

Rotate when something seems suspect. Don’t rotate because of an arbitrary timeout, like every six months.

Disallow common passwords.

Check new passwords against a blacklist of stolen passwords

The most important step is to check new passwords against a blacklist. These cover a range of passwords, including those known to have been already compromised, and those used in any major presentation. Checking against a blacklist is new territory—a lot of organizations don’t even know where to start.

Creating a Blacklist

An ideal blacklist should have all stolen passwords—not just the ones discovered on the dark web. Unfortunately creating a list of all stolen passwords is difficult. Recently companies have been relying on lists of stolen credentials from the dark web, but these are often too little, too late as it’s not possible to know how long these stolen passwords have been in circulation. For example, Yahoo was breached in 2013, but didn’t realize until 2016. Due to the economics of attackers, there is almost always a big lag between when data is breached and when it’s exploited.

Blackfish and the Breach Corpus

At Shape we created Blackfish to proactively invalidate user and employee credentials as soon as they are compromised from a data breach. It notifies organizations in near real-time, even before the breach is reported or discovered. How does it do this?

Blackfish technology is built upon the Shape Security global customer network which includes many of the largest companies in the industries most targeted by cybercriminals including banking, retail, airlines, hotels and government agencies. By protecting the highest profile target companies, the Blackfish network sees attacks using stolen credentials first, and is able to invalidate the credentials early in the fraud kill chain. This provides a breakthrough solution in solving the zero-day vulnerability gap between the time a breach occurs and its discovery.

Using machine learning, as soon as a credential is identified as compromised on one site, Blackfish instantly and autonomously protects all other customers in its collective defense network. As a result, Blackfish is the most comprehensive blacklist in the industry today.

Don’t Rely on Dark Web Research

Dark web research provides too little information, too late. Today major online organizations can take a much more proactive approach to credential stuffing. By using Blackfish businesses can immediately defend themselves from attack while reducing the operational risk to the organization. Over time these stolen credentials become less valuable to attackers because they just don’t work, and in turn credential stuffing attacks and fraud are reduced.

Example

Installation and usage

Unminify is a node.js module and is available on npm. It can be installed globally with npm install -g unminifyand then executed as unminify file.js, or executed without installation as npmx unminify file.js. It is also suitable for use as a library. For more, see the readme.

Unminify supports several levels of transformation, depending on how carefully the original semantics of the program need to be tracked. Some transformations can alter some or all behavior of the program under some circumstances; these are disabled by default.

Background

JavaScript differs from most programming languages in that it has no portable compiled form: the language which humans write is the same as the language which browsers download and execute.

In modern JavaScript development, however, there is still usually at least one compilation step. Experienced JavaScript developers are probably familiar with tools like UglifyJS, which are designed to transform JavaScript source files to minimize the amount of space they take while retaining their functionality, allowing humans to write code they can read without sending extraneous information like comments and whitespace to browsers. In addition, UglifyJS transforms the underlying structure (the abstract syntax tree, or AST) of the source code: for example, it rewrites if (a) { b(); c(); } to the equivalent a&&(b(),c()) anywhere such a construct occurs in the source. Code which has been processed by such tools is generally signicantly less readable; however, this is not necessarily a goal of UglifyJS and similar minifiers.

In other cases, the explicit goal is to obfuscate code (i.e., to render it difficult for humans and/or machines to analyze). In practice, most tools for this are not significantly more advanced than UglifyJS. Such tools generally operate by transforming the source code in one or more passes, each time applying a specific technique intended to obscure the program’s behavior. A careful human can effectively undo these by hand, given time propotional to the size of the program.

State of the art

There are well established tools like Prettier for formatting JavaScript source by the addition of whitespace and other non-semantic syntax which improves readability. These undo half of what a tool like UglifyJS does, but because they are intended for use by developers on their own code rather than for analysis of code produced elsewhere, they do not transform the underyling structure. Running Prettier on the above example gives

Unminify

Unminify is our contribution to this space. It can undo most of the transformations applied by UglifyJS and by simple obfuscation tools. On our example above, given the right options it will fully restore the original program except for the name of the local variable input, which is not recoverable:

Unminify is built on top of our open source Shift family of tools for the analysis and transformation of JavaScript.

Operation

The basic operation of Unminify consists of parsing the code to an AST, applying a series of transformations to that AST iteratively until no further changes are possible, and then generating JavaScript source from the final AST. These transformations are merely functions which consume a Shift AST and produce a Shift AST.
This processes is handled well by the Shift family, which makes it simple to write and, crucially, reason about analysis and transformation passes on JavaScript source. There is very little magic under the hood.

Unminify has support for adding additional transformation passes to its pipeline. These can be passed with the --additional-transform transform.js flag, where transform.js is a file exporting a transformation function. If you develop a transformation which is generally useful, we encourage you to contribute it!

Like this:

It seems everyone today is talking about stolen passwords, but this is an older problem than people realize. Protecting your enterprise from credential stuffing attacks and account takeover as a result of stolen credentials is at the heart of the discussion—and as more business moves online it’s an increasingly expensive problem.

The Stolen Password

During the final phase of the Peloponnesian War, 1 a series of tactical errors led to the defeat of the superior Athenian forces. Among the many errors was an inadequate identification system, reliant on a shared watchword. At the final and crucial battle of Syracuse, the besieged Syracusan army discovered the Athenian watchword that was used for identifying allies. Quietly disseminating this password between them, the Syracusan forces created havoc during a nighttime battle, preventing the dazed Athenian forces from identifying ally from foe and ultimately leading to their devastation.2

Step forward a few thousand years to the 1960s, when limited computing resources at MIT resulted in the Compatible Time-Sharing System. Given the limited power of computers at the time, a short phrase was the simplest way to identify users on the platform. But, the first password breach soon followed when in 1962 Allan Sherr, looking for a way to increase his allotted time on the platform, managed to request a printout of the entire password file.3

Since then, the history of the password remains consistently problematic. Passwords are complicated, easily forgotten, and usually represent a single point of failure. Wake up to find your password compromised and the results, although not quite as devastating as for the Athenians, can often be financially or socially shattering. In efforts to make passwords themselves more secure, increasingly arbitrary rules on their construction have been enforced. Unfortunately, these rules often force users to adopt practices that directly contradict the intent, driving users to adopt the same password across websites,456 or preventing the use of tools like password managers.

Meanwhile, despite growing awareness of multi-factor authentication systems, statistics around adoption rates are difficult to find and are widely thought to be worryingly low.

Introducing NIST

NIST (or the National Institute of Standards and Technology) is a non-regulatory United States Government Agency with a mission to “promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.”7 Within this mandate, NIST has established the NIST Cybersecurity Framework. The original intent was to develop a voluntary framework to help organizations manage cybersecurity risk across critical infrastructure, but the framework has been adopted much more widely throughout the world. Of particular interest is the four-volume Special Publication 800-63 on Digital Identity Guidelines which is available on the NIST Website and NIST GitHub. It includes:

Offer the option to display the password, rather than dots or asterisks.

Out:

Don’t enforce composition rules (no more: your password should include upper and lower case characters, and at least one number). These encourage passwords with the illusion of complexity, like Passw0rd, which any dictionary attack will take into account.

Don’t use password hints, as users tend to populate these hints with enough information to make guessing the password trivial. Instead, focus on supporting easily memorized passwords and phrases.

Don’t use Knowledge Based Authentication (e.g. what was the name of your childhood pet?).

Don’t use SMS as a 2-Factor Authentication method.

Updated Password Storage Guidance

NIST also includes guidance on encryption and storage of user passwords. As we’ve seen from previous breaches, weak and reversible encryption lets attackers access vast sets of credentials that can easily be used against other sites8. To limit the effect of breaches on other sites, NIST recommends that:

Passwords should be salted and hashed using a suitable one-way key derivation function.

Use approved key derivation function PBKDF2 using SHA-1, SHA-2, or SHA-3 with at least 10,000 iterations.

Breach Corpuses

The appendix of 800-63b lays out some hard truths about the choices we make as users:

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.

Maintaining a list of compromised credentials from previous breaches is a noble effort, but there are a number of factors to balance. For example, Facebook attracted criticism when it announced in 2016 that it had been purchasing credentials from the dark web9 in order to secure its own users. Such purchases could effectively help power the market, funding and encouraging further breaches and supporting the black market credential ecosystem. Plus, the huge window of time that exists between a data breach and the eventual emergence of the stolen credentials means that traditional breach corpus lists are often ineffective – and that’s something Shape Security is addressing with Blackfish. Shape co-founder Sumit Agarwal explains it best:

Shape has grown into one of the largest processors of login traffic on the entire web. We have built machine learning and deep learning systems to autonomously identify credential stuffing attacks in real-time. These systems now generate an important byproduct: direct knowledge of stolen usernames and passwords when criminals are first starting to exploit them against major web and mobile apps. What this means is that we see the stolen assets months or years before they appear on the dark web.

Of course, once you’ve found a way to compile it, a vast list of the freshest credentials is itself a major target, so to minimize risk (as well as ensure absolute compliance with regulations such as GDPR), Shape does not store any direct username/password pairs but instead leverages a probabilistic data structure called a Bloom filter.

Conclusion

As Jim Fenton, one of the publication contributors, points out, “If it’s not user friendly, users cheat.”10 Frustrating password policies have been long overdue for an overhaul and the new NIST Digital Identity Guidelines rightly place the burden upon the verifier, not the user. While verifiers of users should ensure they’re following the guidelines to give users the best chance of securing their accounts, they should also take additional steps to ensure that security breaches originating from outside their own organization are stopped before they create more damage closer to home. In light of the recent FTC ruling on credential stuffing, it might be more than just best practices that encourage verifiers to comply.