Join our RSA session

The Emperor’s New Password Manager: Security Analysis of Password Managers

Friday, April 24, 2015
9:00 AM – 9:50 AM
Room: 3009

Session abstract: We conducted a security analysis of popular web-based password managers. Unlike local password managers, web-based password managers run in browsers. We identify four key security concerns and representative vulnerabilities. Our attacks are severe: in four out of the five password managers we studied, attackers can learn credentials for arbitrary websites. This work is a wake-up call for developers.

Speaker: Zhiwei Li, Research Scientist @ Shape

More information

Meet Shape at RSA 2015

April 20-24 • Moscone Center, San Francisco, CA

RSA 2015 is around the corner. Will you be attending? Come meet with Shape Security and learn more about our technology. We have a booth, are hosting a private meeting suite at the St. Regis hotel, and offering free expo passes to everyone with our discount code. Read more details below.

Shape Booth

Private Meeting Suite

Our Co-Founders sponsored a Suite in the St. Regis. The suite has food, wifi, and a relaxing place to put up your feet. Reserve a time to come unwind and learn about Shape.

Free RSA Expo Passes

Interested in coming to RSA? Enjoy a free pass on Shape.

Coupon code X5ESHPSEC

Browser Compatibility Testing with BrowserStack and JSBin

There are some great services out there that go a long way to outline browser compatibility of JavaScript, HTML, and CSS features. Can I Use? is one of the most thorough, and kangax’s ES5 and ES6 compatibility table are extremely valuable and regularly updated. The Mozilla Developer Network also has a browser support matrix for almost every feature that is documented, but it is a public wiki and a lot of the information comes from the previously mentioned sources. Outside of those resources, the reliability starts dropping quickly.

What if the feature you’re looking for isn’t popular enough to be well documented? Maybe you’re looking for confirmation of some combination of esoteric behaviors that isn’t documented anywhere?

BrowserStack & JSBin

BrowserStack has a service that allows you to take screenshots across a massive number of browsers. Services like these are often used to quickly verify that sites look the same or similar across a wide array of browsers and devices.

While that may not sound wildly exciting for our use case, we can easily leverage a service like jsbin to whip up a test case that exposes the pass or failure in a visually verifiable way.

Using a background color on the body (red for unsupported, green for supported) we can default an html body to the ‘unsupported’ class and, upon a successful test for our feature, simply change the class of the body to ‘supported’. For example, we recently wanted to test the browser support for document.currentScript, a feature that MDN says is not well supported but according to actual, real world chrome and IE/spartan developers, is widely supported and has been for years!

Well we had to know, so we put together a jsbin to quickly test this feature.

  <meta charset="utf-8">
  <title>JS Bintitle>
<body class=unsupported>
  <script id=foo>script>
  <script id=target>
    if (document.currentScript && === 'target')
      document.body.className = 'supported';
  <script id=bar>script>

After the bin is saved and public, we select a wide range of browser we wanted to test in browserstack and pass it the output view of the JSBin snippet. In this case we wanted to test way back to IE6, a range of ios and android browsers, opera, safari, and a random sampling of chrome and firefox.


After a couple minutes, we get our results back from BrowserStack and we can immediately see what the support matrix looks like.


This binary pass/fail approach may not scale too well but you could get creative and produce large text, a number, or even an image that is easily parsable at varying resolutions, like a QR code, to convey test results. The technique is certainly valuable for anyone that doesn’t have an in-house cluster of devices, computers, and browsers at their disposal simply for browser testing. Credit goes to Michael Ficarra (@jspedant) for the original idea.

Oh, and by the way, document.currentScript is definitely not widely supported.

Use of Stolen Creds Is Most Dangerous Web Threat, Verizon Finds

Use of stolen credentials is the biggest web threat, says the most recent Verizon Data Breach Report.

Learn more about this threat below.

A working definition of the use of stolen credentials is available on an OWASP page. The occurance of stolen creds rose from #7 in 2009 to #1 in 2013. 2013 is the most recent data. Here at Shape Security, we hear about stolen credentials, credential stuffing and account checkers every day. We’ve also blogged about what Gartner told us. According to Gartner’s fraud expert Avivah Litan, “clients have reported a significant rise over the last two months in the use of stolen credentials to access accounts”.
Contact Shape if you would like our help protecting your site from the use of stolen credentials. Our technology blocks account checkers, credential stuffing and other automated attacks.

Rising Attack Vector: Credential Stuffing

Credential stuffing is a growing threat to the web community. As more companies are offering their goods and services online, customers practicing bad password hygiene are in danger of having their account stolen whenever a website is breached.

Read more about the rise of credential stuffing below.

Credential stuffing is taking lists of breached credentials from one website and testing them against another. According to the most recent Verizon Data Breach report, it’s one the fastest rising attack vectors.

The list of major companies that have fallen to this attack is impressive: Sony ‘11, Yahoo ‘12, Dropbox ‘12, and JPMC ‘14.

Credential stuffing is a general concept, but the outcome of successfully taking over user accounts results in more specific attack in various industries: stealing hotel reward points, pilfering airline frequent flier miles, and committing gift card fraud, to name just a few.

The Definition of Credential Stuffing

Credential stuffing is the automated testing of breached username/password pairs in order to fraudulently gain access to user accounts. This attack involves checking large numbers of spilled credentials against various websites to uncover credentials that are valid on a target website. Attackers then hijack those accounts and commit various types of fraud.

The Anatomy of Credential Stuffing Attack

  1. The attacker acquires spilled usernames and passwords from a website breach or password dump site.
  2. The attacker uses an account checker to test the stolen credentials against many websites (for instance, social media sites or online marketplaces).
  3. Successful logins (usually 0.1-1% of the total login attempts) allow the attacker to take over the account matching the stolen credentials.
  4. The attacker drains stolen accounts of stored value, credit card numbers, and other personally identifiable information
  5. The attacker may also use account information going forward for other nefarious purposes (for example, to send spam or create further transactions)

How is Credential Stuffing Different from Existing Threats?

We’ve classified credential stuffing as a renewed form of attack because the primary vector for account takeover has changed from the breaching of databases to automated web injection.

According to our analysis, credential stuffing is now the most popular method used by attackers to achieve account takeover. This is particularly dangerous to both consumers and enterprises because of the ripple effects of these breaches.

Credential Stuffing was the Attack Vector Used in the Sony, Yahoo, Dropbox and JPMC Breaches

Below are excerpts taken from publications analyzing these large-scale breaches. There is evidence to support that these breaches were connected by credential stuffing.

  • Sony, 2011 breach: “I wish to highlight that two-thirds of users whose data were in both the Sony data set and the Gawker breach earlier this year used the same password for each system.” Source: Agile Bits
  • Yahoo, 2012 breach: “What do Sony and Yahoo! have in common? Passwords!”. Source: Troy Hunt
  • Dropbox, 2012 breach: “The usernames and passwords referenced in these articles were stolen from unrelated services, not Dropbox. Attackers then used these stolen credentials to try to log into sites across the internet, including Dropbox”. Source: Dropbox
  • JPMC, 2014 breach: “[The breached data] contained some of the combinations of passwords and email addresses used by race participants who had registered on the Corporate Challenge website, an online platform for a series of annual charitable races that JPMorgan sponsors in major cities and that is run by an outside vendor. The races are open to bank employees and employees of other corporations”. Source: NY Times

Anatomy of the 2011 credential stuffing attack on Sony. Credentials from smaller sites are leaked and injected into Sony’s login pages to test for credential reuse. The attacker gained access to any Sony accounts which used the same credentials as were leaked from the smaller sites.

Using botnets, Sony credentials were tested on Sony’s login page. According to Wired, this resulted in 93,000 breached accounts. In other words, the credential stuffing attack that led to the Sony breach was made possible by prior breaches of smaller sites.

This connected chain of events from Sony to Yahoo to Dropbox excludes JPMC. The JPMC breach came from a separate and unrelated source. We know that the JPMC breach was caused by attackers targeting an unrelated third-party athletic race/run site for credentials to use against JPMC.

What Can SysAdmins Do to Prevent Attackers from Hijacking User Accounts by Credential Stuffing?

The answer requires an understanding of the technical mechanism by which credential stuffing works.

Like account checkers, credential stuffing works by using the static form elements of the login page as an implicit API. The attacker references various form element names (email and password) in order to interact with the target webpage. Since most websites accept such traffic as normal (having no means to distinguish between intended and malicious use), the attacker can automate the attack by using scripts and account checkers to easily run through millions of tests per unit time. Using a large-scale distributed botnet and a huge number of IP addresses allows the attacker avoid rate and volume limits which might otherwise prevent such a large number of login attempts. Thus, it is trivial even for unsophisticated attackers to launch attacks of this nature and scale against some of the largest websites in the world.

To defend websites against such activity, which we call “unwanted automation,” Shape Security uses an approach that is familiar to attackers: we dynamically change the underlying code of the site each time a page is viewed to defeat the types of scripts used in credential stuffing attacks. Just as malware authors have long used polymorphic code to evade antivirus products by constantly presenting different signatures, Shape’s solution creates a moving target which frustrates potential attackers attempting to automate easy credential testing on the website using scripts. The effort an attacker must invest to successfully automate login attempts on a given website without changing the front-end use experience.

Of course, savvy readers will point out numerous ways these measures can be circumvented. While, it is beyond the scope of this article (but perhaps the subject of future pieces) to consider such attacks (DOM, GUI, and others), Shape is keenly focused on comprehensively defeating them and has solutions at each of those levels.

Contact us to learn how Shape Security can protect your site.

Reducing with the Shift Reducer

What is a Reducer?

A reducer is an actor that takes something large and turns it into something smaller. In programming it is a construct that recursively applies a function over a data structure in order to produce a single value.

In JavaScript, you could reduce an array of integers to a single sum with the following code.

var integers = [1, 2, 3, 4, 5, 6];
var sum = integers.reduce(function(memo, next){ return memo + next; }, 0);
// sum === 21

Shift Reducer

Shape Security has provided a reducer to use in building tooling for the Shift format AST. The reducer folds a Shift format AST into a summary value, much like Array.prototype.reduce folds an array. Of course, reducing an array is much less complex than reducing an AST. Only one function is required to reduce an array, while reducing an AST requires one function for each different type of node.

Shape’s reducer library exposes a single function that runs the reduction, and two base structures that are meant to be extended with your own reducing behaviors: Reducer and MonoidalReducer.


Use Reducer when the reduction requires unique behavior for each different type of node. It is a clean slate. Extending Reducer requires every single reduction method (reduceXXX) to be overridden. Code generation or AST serialisation are examples of when it is appropriate to base your reducer on Reducer.


The majority of Shift implementations will benefit from basing their reducer off of MonoidalReducer. Extending MonoidalReducer requires that the summary value that each reduction method returns is a Monoid. Its default implementations of the reduction methods take advantage of the monoidal structure of your summary value so that only the reduction methods for the pertinent nodes need to be overridden by you. For all others, the Monoid’s identity will be used.

That may have been a lot to take in. Don’t worry if you’re not familiar with the terminology! As a programmer, you likely run into Monoids every single day, but the term can cause confusion. Let’s see if we can clear up the term a little bit.


A monoid is structure that relates the elements in a set with a closed, associative, binary operation that we will call append, coupled with one special element in that set that we will call the identity element.

Let’s break monoids down a little further.

What is a binary operation?

A binary operation is an operation that operates on two inputs.

0 + 1; // + is a binary operator
function append(a, b){} // append is a binary function

What is a closed operation?

An operation is closed if performing the operation on members of a set always produces a member of the same set.

What is associativity?

We learned the concept of associativity back in elementary school and it is core to our understanding of algebraic operations. Associativity, as the name implies, means that grouping of operations does not affect the result.

(a + b) + c === a + (b + c)

Remember, associativity is not commutativity. That would mean that the order of the values given to the operation does not affect the result.

a + b + c === c + b + a

What is an identity?

An identity is a value for a specific operation that when passed to an operator with any other value returns the other value. You may remember this via the additive identity, 0, or the multiplicative identity, 1.

x + 0 === x;
0 + x === x;

x * 1 === x;
1 * x === x;

append(x, identity) === x;
append(identity, x) === x;

Putting it all together

Using the above examples we could write out the Sum Monoid in arithmetic expressions.

sumIdentity = 0
sumAppend(x, y) = x + y

Or we could write the Sum Monoid JavaScript implementation. For this, we will use the conventional Fantasy Land names, empty and concat.

class Sum {
  constructor(number) {
    this.value = number;
  // always return the identity element
  static empty() {
    return new Sum(0);
  // the binary operation acts on its `this` value and its parameter
  concat(other) {
    return new Sum(this.value + other.value);

new Sum(5).concat(new Sum(2)).value; // 7

Walkthrough: Making something with the MonoidalReducer

Now that we understand monoids, let’s walk through making a small program with the Shift MonoidalReducer that counts how many identifiers are in a program.


Install dependencies.

$ npm install --save shift-reducer shift-parser 6to5

Making an Identifier counter

First we need to flesh out our basic program.

import parse from "shift-parser";
import reduce, {MonoidalReducer} from "shift-reducer";

// a monoid over integers and addition
class Sum() {
  constructor(number) {
    this.value = number;
  // by default reduce any node to the identity, zero
  static empty() {
    return new Sum(0);
  // combine Sum instances by summing their values
  concat(other) {
    return new Sum(this.value + other.value);

class IdentifierCounter extends MonoidalReducer {
  constructor() {
    // let MonoidalReducer know that we're going to use Sum as our monoid

  // a convenience function for performing the reduction and extracting a result
  static count(program) {
    return reduce(new this, program).value;

  // add 1 to the count for each IdentifierExpression node
  reduceIdentifierExpression(node) {
    return new Sum(1);

    In this case, the only node we care about overriding is the
    IdentifierExpression node; the rest can be reduced using the default
    methods from MonoidalReducer.

// test program code
var program = "function f() { hello(world); }";

Run it!

$ node_modules/.bin/6to5-node count-identifiers.js

Wrapping Up

Let’s walk through what’s been done. We’ve created a new Reducer by extending the MonoidalReducer, overridden the necessary reduction methods (in this case only reduceIdentifierExpression), and parsed and run our new reducer over a program.

We wrote this example in ES6 because we believe it’s clearer. An ES5 version of the identifier counter is available in this gist.

Taking it Further

At this point, we’ve used a fairly trivial example in order to expose the fundamentals of using the MonoidalReducer. Next, we will look at the design of a more significant project that makes use of theMonoidalReducer: the Shift Validator.

Shift Validator

The Shift Validator validates a Shift format AST from the bottom up. But how does it do this when many of the restrictions it is enforcing are context sensitive? The ValidationContext object that the Validator uses allows possible errors to be registered on it and, if we determine (with new information about the possible error’s context) that the error actually does not apply, it can clear possible errors as well. Only when we are certain an error will not be cleared do we move it from its temporary error list to the official errors list in the ValidationContext object. Let’s look at a concrete example:

When the Validator reduces a ReturnStatement, we call the addFreeReturnStatement helper method of our ValidationContext state object, giving it an error that this ReturnStatement must be contained within a function (top-level return is illegal in JavaScript). We don’t know whether this ReturnStatement is actually in an illegal position, but we assume it is until we better understand its context. In the reduction methods for FunctionDeclaration, FunctionExpression, Getter, and Setter nodes, we then call the clearFreeReturnStatements helper method of our ValidationContext state object clearing out all of the ReturnStatement errors we collected while reducing ReturnStatement nodes below us in the AST. Finally, when we reduce a Script node (the head of the AST), we move the ReturnStatement errors from their temporary holding list to the confirmed errors list using theenforceFreeReturnStatementErrors helper method. We do this at this point because we know we won’t be reducing any more functions that will cancel out a ReturnStatement error.

Final Round Up

To pull it all together, we’ve gone over the Shift Reducer and MonoidalReducer. Both can be used to build tooling based on the Shift AST. We’ve gone over the fundamentals behind the MonoidalReducer and explored both a simple MonoidalReducer example, as well as a more complex example, the Shift Validator. Hopefully, now you feel comfortable building your own tools based on Shift’s AST.