Terribly convenient biometric security

An article written by Dustin Kirkland prompted me to think more about methods of biometric authentication and their place in society. While undoubtedly convenient, I believe that they are not (and can never be) a drop-in replacement for traditional hardware- or password-based authentication.

Aside from being potentially prohibitively expensive to implement, there are a surprisingly large number of major drawbacks that present themselves when you depend on a biometric authentication solution.

You can’t revoke biometric information

Let’s say someone nefarious gains access to your raw biometric data – for example, exploiting a poorly implemented biometrics system or someone scanning and reproducing your biometric features without your knowledge. If you found out they knew your password, you would change it. (And how often nowadays do you receive emails from online services advising you to do just that?) If you found out they had a copy of your code-generating token device, you’d replace or re-key it. But it’s game over as soon as they get their hands on your biometric data – short of some fairly invasive and expensive transplant surgery, there’s no way for you to ever decouple that biometric information from your identity.

You run the risk of very literal identity theft

When there’s a movie that includes a room locked with a biometric scanner, you can be pretty sure that someone’s going to lose a finger or an eye soon. While it’s (hopefully!) not going to affect most of us, those high-risk/high-reward systems that have historically been secured by biometric devices will always be at risk from the more surgically inclined criminals.

There’s the potential for permanent loss of access

If the worst happens and you lose a finger or an eye in an accident (or if it’s taken from you as above), you can no longer authenticate yourself to any system that is secured solely with your biometric information. Without a backup method of authentication (e.g. a password or email verification), you have no way of proving that you have any greater claim to your identity than any other person.

Even if you’re cautious and manage to keep all your limbs, even superficial markings can cause difficulties authenticating with biometric devices. Recent technologies – such as that employed by Apple’s Touch ID sensor – are able to scan the sub-epidermal layer of skin on a finger, allowing them to continue to function despite superficial injuries.

Some people just can’t use biometric scanners

A small proportion of people – whether due to age, ethnicity or other factors – are unable to register biometric information such as fingerprints with current scanner technology. For example, in a study conducted by the UK Passport Service, the successful authentication rate for able-bodied participants was:

  • 69% for facial recognition,
  • 96% for iris verification, and
  • 81% for fingerprint verification.

It was also the case that older participants were more likely to fail to authenticate their fingerprint than younger participants, suggesting a deterioration in the quality of the finger scan.

You leave your biometric data behind everywhere you go

If you touch something, you leave your fingerprints behind. Skin cells and hairs that fall off your body every day contain your DNA. High-resolution cameras can capture a detailed iris scan. And while scanner technology is always improving and becoming better at recognising duplicated biometric data, time and again the sensors are fooled.

It’s very difficult to maintain identity separation between services

Let’s say you want to authenticate yourself to multiple systems using your biometric data. If you use the same biometric data to authenticate yourself to both your bank and ScamCorp, it’s akin to using the same password on multiple websites – a data breach or malicious employee at one business will leave you vulnerable everywhere else. Your only option in this case is to give everyone different biometric data – but given that most people have one face, two eyes and ten fingers, your level of potential exposure will remain high.

Biometric technology is encumbered by hardware and software patents

Biometric technology is laden with patents, so much so that new players in the industry are often forced to buy up existing businesses for their intellectual property rather than for their talent or market position. For example, AuthenTec went on an acquisition spree – acquiring or merging with EzValidation, Atrua Technologies, SafeNet and UPEK, before being acquired by Apple in 2012. This has the effect of monopolising the market, effectively limiting competition and innovation – so much so that I doubt the biometric technology that we have today will see much improvement in the near future without external influence. (In general, I believe that software patents should go away – but that’s a bigger topic for another time.)

It’s impossible to remain anonymous

If biometric identification is required, you as an individual are permanently tying yourself to any identities you create. While creating a “throwaway” account and password will preserve your anonymity from all but the most highly-equipped adversary, there is no such protection afforded once biometrics are involved.

Collecting and verifying biometric data can be socially intrusive

The mass collection of biometric data can undermine the notion of “innocent until proven guilty” in society. While in the past police officers would need “probable cause” before arresting and fingerprinting suspects, the tradition shifts when the state implements biometric authentication schemes. People will expect to (and are expected to) submit to biometric identification at government offices, where it is likely integrated with criminal, social and other databases.


Biometric authentication should be a misnomer and you shouldn’t depend exclusively on it to establish your identity. But you’ll probably still use it because it’s so convenient!

An Ideal HTTPS setup for Apache and Nginx

Now more than ever, it’s imperative that we know when we’re using the Internet securely. With an ever-increasing amount of business being conducted online, even a small issue with the way a web server is configured could result in untold financial and reputational damage for a company, or a breach of someone’s most private information.

It’s no surprise, then, that usage of SSL/TLS (via HTTPS connections) has exploded in recent years. In fact, Google Chrome users have more than doubled their use of HTTPS  in the last 2 years, with 27% of all page loads being conducted over HTTPS in 2013 up to 58% in 2014.

Chrome HTTPS usage

However, HTTPS connections are only as good as the technology they’re based on. IT professionals are doing what they can to keep up with the ever-changing security landscape, but with vulnerabilities such as CRIME, BREACH, Lucky 13BEASTHeartbleed and POODLE coming to light with alarming regularity, administrators can just about finish patching their fleets of servers before the next issue is identified.

In fact, although many people running servers want to protect themselves, they don’t necessarily have the in-depth knowledge of the underlying security of their systems to make putting in the effort to investigate worthwhile. And since packages like Apache and Nginx let administrators do just about anything (and by default don’t expose the options which would make their users’ servers more secure), many websites out there are putting both their security and their visitors’ security at risk.

Here are two things that server administrators can do today to secure themselves.

  1. Add SSL/TLS HTTPS functionality.
  2. Secure the setup.

Add SSL/TPS HTTPS functionality

This part is easier than you might think. While SSL/TLS certificates tend to be in the region of $100 to $200 per year (and EV certificates can be up to $1,000), StartSSL offer a free certificate for basic use. It’s what this site uses, and I’ve never had any trouble with browser or server compatibility.

Secure the setup

It is extremely easy to misconfigure an SSL/TLS setup. Thankfully, most of the hard work has been done for you! Others have delved deep into the bowels of web server security configuration, and have shared templates for the world to benefit from. Sample Apache configurations can be found all over the internet. For example, this server used something similar to the following before switching to Nginx:

<VirtualHost *:443>
 SSLEngine on
 SSLCertificateFile signed-cert-bundle.crt
 SSLCertificateChainFile intermediate-cert.crt
 SSLCertificateKeyFile davidlyness.com.pem
 SSLCACertificateFile /path/to/all/ca-certs

 SSLProtocol all -SSLv2 -SSLv3
 SSLHonorCipherOrder on
 SSLCompression off

 SSLUseStapling on
 SSLStaplingResponderTimeout 5
 SSLStaplingReturnResponderErrors off
 SSLStaplingCache shmcb:/var/run/ocsp(128000)

 Header add Strict-Transport-Security "max-age=31536000; includeSubdomains"

Unfortunately, securing Nginx has been seen as more of an academic exercise – designed to get the highest score on online tests such as SSL Labs rather than to cater to the widest range of browsers and operating systems while still remaining secure. A template for Nginx is as follows:

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
ssl_certificate signed-cert-bundle.crt;
ssl_certificate_key davidlyness.com.pem;
ssl_dhparam dhparam.pem;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate unified-cert-bundle.crt;
if ($scheme = http) {
 return 301 https://$host$request_uri;

Check out the configuration on Github, where you can find an always-up-to-date version to make sure you stay current as the security landscape evolves. You can also find a thorough explanation for what is included in the configuration and why.

This website is run on an Nginx server using the above configuration, which manages to achieve an A+ rating on SSL Labs while still maintaining support for the widest possible range of browsers. The only ones that are incompatible with this configuration are Java 6 (which was EOL’ed in February 2003) and IE6/IE8 on Windows XP (which was EOL’ed in April 2014).