Client thrust

For a web client driven by a human user, authenticating that user is central to virtually every web transaction. Overwhelmingly the most common way to do this today is using passwords. Passwords are by no means a perfect protection, however, in that they can be guessed by an attacker or stolen by breaching the application server and cracking password hashes stored there, a far too common occurrence. Indeed, password database breaches have become an industry pandemic. Here we describe two approaches by which a cloud operator can aid tenants in authenticating clients more securely. The solutions we describe aim specifically at minimizing the risk of a password database breach going undetected or leading to impersonation of user credentials.

Pythia relies on a PRF server, potentially run by the cloud operator. The PRF server applies a pseudorandom function (PRF), a deterministic cryptographic operation involving a secret key, to a password p that the application server submits for registration (storage) or verification, yielding a corresponding output x. The PRF server thereby “hardens” passwords: Unlike a password hash, which is vulnerable to brute-force cracking if the underlying password is weak, the PRF-hardened value x is computationally infeasible for an adversary to crack.

A second threat that administrators of application servers must address is denial-of-service (DoS) attacks against their servers. The damage that DoS attacks cause to organizations in terms of lost revenue and customer trust is well documented. DoS defense of application servers today comes primarily in two forms, namely proprietary solutions that scale to massive load but that are expensive (e.g., Akamai) or hardware appliances that will have difficulty keeping up with the adversary’s ability to dynamically change the type, volume, and locations of their attacks.

Detecting exploit traffic against tenant services

To detect such exploit attempts, we are developing a technique by which a cloud-resident verifier that observes the messages between a cloud-resident application server and a client, can detect messaging behavior from the client that is inconsistent with the expected client software. For example, our verifier can detect a client’s deviation from an OpenSSL implementation of TLS within seconds from when the deviation occurs [5]. Since such deviations are typically characteristic of maliciously crafted packets to exploit server vulnerabilities, this type of verification capability could reduce the delay to detect exploit attempts on zero-day vulnerabilities and, if used as an inline defense, could prevent those exploits from succeeding. In particular, this technique could have detected Heartbleed packets within seconds of the first attempted exploit, with no Heartbleed-specific configuration.