This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Pinning Cheat Sheat

Revision as of 03:37, 13 February 2013 by Jeffrey Walton (talk | contribs)

Jump to: navigation, search

Invariant trust of critical infrastructure such as DNS and PKI{X} with a public CA hierarchy has led to a number of high profile failures in the secure channel. This cheat sheet will help developers and organizations navigate the minefield of securing data in transit and by bringing integrity back to the channel when a pre-exisiting relationship exists between the user and an organization or service.

This cheat sheet is a technical guide to the Virginia chapter's presentation Securing Wireless Channels in the Mobile Space. Additional material includes supplement with code excerpts, Android sample program, iOS sample program, .Net sample program, and OpenSSL sample program. The cheat sheet is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability.


Secure channels are a cornerstone to users and employees on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.

The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on effectively untrusted input. Pinning leverages knowledge of the pre-exsiting relationship between the user and an organization or service to help make better security related decisions. Effectively, pinning removes the "conference of trust" and identifies the host or service by its public certificate or public key when holding a public/private key pair. An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making decisions relating to a peer's identity.

For those familiar with SSH, you should realize that public key pinning nearly identical to SSH's StrictHostKeyChecking option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.