Biometric "Security"?

22 May, 2016 (unlisted)
Biometric sensors are good at identity. They can tell you exactly who a fingerprint belongs to; who's face is in-front of the camera; even who's DNA was left at a crime-scene. But biometric sensors are not good authenticators.

Replay Attacks

Let's say Bob, thinks it's a good idea to add a voice activated lock to his house. Now when Bob says "open", the door will open up. Bob is pretty pleased with himself and decides to show his friends, Alice and Steve. Sure enough, when either Alice or Steve give the command "open", the door doesn't budge – of course – they don't have Bob's voice.
Now consider a third party, Eve. Eve decides she would like to break into Bob's house, and to do so she needs Bob's voice. So she places a tape recorder outside Bob's front door and she waits, listening for Bob to unlock the door. Eventually Bob says "open" once more, but this time Eve was listening, and recording the response. Eve now has Bob's voice. Eve need only wait for Bob to leave, before replaying Bob's voice giving the command "open", and she is granted entry.
It's important to realise here, that unlike passwords (which are also susceptible to replay attacks), your biometric identity can be obtained in ways other than listening in on a legitimate authentication. You leave your biometric identity everywhere. On door handles, in recordings, in pictures of you. You leave your fingerprint on the Touch ID sensor of your iPhone. The information required for a simple replay is in many circumstances, trivially obtained.

A Password you Can't Change

Fundamentally, biometric authentication, by whatever means relies on determining something you are. So at it's core, biometrics are bound to you. Your current state of being. Whether that be brain wave patterns, the way you type, a fingerprint, DNA, or even voice. But you can't change something you are.
So why does that matter? The problem arises when the information required for authentication is no longer secret. If an attacker knows what information to present, their task is only how to present the data. What should you do after someone else has your biometric information? You could revoke access in theory, but how do you proceed after that? You can't simply generate a new fingerprint, or new DNA – you're stuck with the same biometric data.

Uniqueness and Trust Issues

One reason not to use the same password everywhere is trust. Let's say you decide to use the same password with many services. You have to trust two things about the service you provide your non-unique password to. 1. You must trust that they will not use that secret against you (by attempting authentication with your other services), 2. You must trust that they will safeguard that data sufficiently: a security breach would leave the attacker in a position to cross authenticate with other services if your credentials are identical.
Having the same biometric data across multiple services, does you the exact same security disservice that using an identical password provides.
With biometric authentication you have to again: trust that everyone who stores your biometric data does so without malice, and with sufficient safeguards.
Good authentication shouldn't require you to trust the party that you are engaging with to do anything other than authenticate you correctly to their own service. Which is why it's a good idea to have a unique password everywhere – this is unachievable with biometric authentication.


Biometric authentication is bad because
  1. You leave your key everywhere: sensors can't tell a copy from the real thing.
  2. If somebody obtains your key, you can't get a new one.
  3. You use the same key for each service, with no guarantee their copy of your key is safe.


Questions, or I got something wrong? Contact me on Twitter @aidantwoods
17 Apr, 2017

Leveraging the new RPi0w to build a WiFi enabled keystroke injection tool (a.k.a. USB Rubber Ducky with WiFi)...[read more]

28 Mar, 2017

The other day I noticed something cool in Chrome. I can disable JavaScript and cookies + local storage on HTTP!...[read more]

1 Jan, 2017

Recently I've been working on a drop in class to manage certain "Secure Headers" in PHP.

By "Secure Headers", I'm of course talking about those mentioned in the OWASP Secure Headers Project.

The project, SecureHeaders is available on GitHub.


If you're familiar with PHP, you'll know that...[read more]

27 Aug, 2016

Disclosure and Google's Response

This one feels very strange writing, because the vulnerability detailed below is currently exploitable. Google has been notified of this vulnerability, yet they have chosen to do nothing.
GoogleThanks for your bug report and research to keep our users secure! We've investigated your submission and made the decision not to track it as a security bug.
In hope that public disclosure will encourage Google to do otherwise, here goes...[read more]
4 May, 2016


A little over a month ago I contacted my bank (Santander), asking them why they served me their homepage insecurely...[read more]
2 May, 2016
In this post I'll address one specific task: obtaining a manual certificate from Let's Encrypt.

Who is this for?

If you don't have direct command line access, or the necessary permissions to install Let's Encrypt on your webserver; then you won't be able to obtain a certificate using the automated process.
If you can install Let's Encrypt on your webserver, you should. It simplifies the process down to a single command. You'll also enjoy the benefits of being able to setup an auto renew process directly on the machine serving the certificate...[read more]