{"id":182,"date":"2019-02-02T18:50:47","date_gmt":"2019-02-02T18:50:47","guid":{"rendered":"http:\/\/www.bennish.net\/blog\/?p=182"},"modified":"2020-10-30T23:49:58","modified_gmt":"2020-10-30T23:49:58","slug":"passwords-certificates-key-better-online-security","status":"publish","type":"post","link":"https:\/\/www.bennish.net\/blog\/2019\/02\/passwords-certificates-key-better-online-security\/","title":{"rendered":"Passwords are past it \u2013 are certificates the key to better online security?"},"content":{"rendered":"\n<p>When the impact of the OpenSSL <a href=\"http:\/\/heartbleed.com\/\">Heartbleed<\/a> vulnerability became clear (along with many other recent compromises), security experts advised us to change <strong>all<\/strong> of our online passwords as a precaution.<\/p>\n\n\n\n<p>Of course this is a Good Idea&#x2122;, but did <strong>you<\/strong> <em>actually do it<\/em>\n or was it just another of those pieces of advice about passwords that \nyou thought about and then chose to ignore because it seemed like a \nmassive hassle?&nbsp; Did you promise yourself that you would get around to \nit at some point and yet probably you never will, despite an \nuncomfortable nagging feeling of insecurity at the back of your head?<\/p>\n\n\n\n<!--more-->\n\n\n\n<p>If so, you are most certainly not alone.&nbsp; What about the other pieces of advice we are given about passwords?<\/p>\n\n\n\n<ul><li><strong>\u201cNever reuse your passwords<\/strong>\u201d<br>\nMany people use the same password for almost all sites, or at best a slight variation.<\/li><li><strong>\u201cPasswords should not contain dictionary words or derivatives\u201d<br>\n<\/strong>How many of you could hand on heart say that none of your \npasswords contain words found in a dictionary (or commonly used \nderivatives such as \u2018w0rd5\u2032) or somewhere on your social networking \nprofile?<\/li><li><strong>\u201cUse two-factor authentication\u201d<br>\n<\/strong>This is a great way to improve security \u2013 after you have \nentered your correct password, the system requires you to enter a \ntemporary code \u2013 this is either sent to you (e.g. by SMS, email, etc) or\n is visible on one of your devices (such as a smart phone) and changes \nevery minute or so.&nbsp; However, it does make the login process slower and \nmore inconvenient (e.g. you need access to your phone.)<\/li><\/ul>\n\n\n\n<h1>My Personal Password Policy (PPP)<\/h1>\n\n\n\n<p>I wrote a blog post back in December 2013 about <a href=\"https:\/\/www.bennish.net\/blog\/2013\/12\/my-personal-password-policy\/\">my Personal Password Policy<\/a> \u2013 explaining the way I handle my online passwords so that they are all:<\/p>\n\n\n\n<ul><li>unique (no reuse across different sites)<\/li><li>strong (very hard for crackers to guess)<\/li><li>synced between my devices<\/li><li>stored on disk protected by a single \u2018Master Password\u2019<\/li><\/ul>\n\n\n\n<h1>A better world<\/h1>\n\n\n\n<p>Let\u2019s stop for a moment and imagine a better world. One where we can \nlog in to any online system using a single \u2018secret\u2019 that we can safely \nreuse for <strong>all<\/strong> systems we use. The systems we log in to never learn the secret but they can<em> still <strong>prove<\/strong> that we have it<\/em>\n (this probably sounds weird to many of you but please bear with me!)&nbsp; \nObviously we need to keep it very safe because it allows access to all \nour accounts (in the same way we need to keep safe the list of saved \npasswords that most people allow their web browsers to save to disk and \nyet probably never think about securing!)&nbsp; But if we discover that \nsomeone else has learned the secret, we can actually <em>revoke<\/em> it, created a new one, and the systems we log in to will automatically switch to the new one instead.<\/p>\n\n\n\n<p>Now stop imagining because this system already exists and has  actually been around (in some form or another) since November 1996! (see  <a href=\"https:\/\/tools.ietf.org\/html\/rfc6101\">the last published version of the SSL 3.0 protocol.<\/a>)<\/p>\n\n\n\n<p>At its heart is a process called <a href=\"https:\/\/en.wikipedia.org\/wiki\/Public-key_cryptography\">public key cryptography<\/a>.&nbsp;  It involves a pair of tokens \u2013 the private (or secret) key known only  to the owner, and a corresponding public certificate that has one or  more identifiers (e.g. your email address) and is <em>signed<\/em> by a trusted person\/organisation once they verify that you are who you say you are.<\/p>\n\n\n\n<h1>Certificates<\/h1>\n\n\n\n<p>The main advantage of certificate-based authentication is that if \nsomeone hacks a web server that you use, your secret remains safe.&nbsp; As a\n result, you can use the same secret for every server!<\/p>\n\n\n\n<p>Private key is the possession (<em>\u201csomething you have\u201d<\/em>) <a href=\"https:\/\/en.wikipedia.org\/wiki\/Multi-factor_authentication\">authentication factor<\/a>*.&nbsp; If you only ever store the private key encrypted with a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Passphrase\">passphrase<\/a>,  and it is not possible for anyone to get hold of the decrypted private  key, the process effectively becomes two-factor authentication as someone needs both the encrypted private key (<em>possession<\/em>) and the corresponding passphrase to unlock it (<em>knowledge<\/em>).&nbsp; You\u2019d only have to remember this single passphrase and would never need to supply it to anyone else or any website.<\/p>\n\n\n\n<p><em>* = a private key can quite easily be duplicated and could, \ntheoretically, be reproduced from human memory so perhaps it\u2019s not \nstrictly speaking a possession factor but a knowledge factor.&nbsp; The grey \narea between possession and knowledge is, however, outside of the scope \nof this blog post.<\/em><\/p>\n\n\n\n<h1>Passwords vs Certificates<\/h1>\n\n\n\n<h2>Portability<\/h2>\n\n\n\n<p><em>How easy is it to log in from new devices?<\/em><br>\n<strong>Passwords<\/strong>: Easy provided you can remember the password (or write it down.) <strong>(+1)<\/strong><br>\n<strong>Certificates<\/strong>: Quite easy but you need to have your private key and certificate with you. <strong>(-1)<\/strong><\/p>\n\n\n\n<h2>Quantity required<\/h2>\n\n\n\n<p><em>How many of these secret tokens do we need?<\/em><br>\n<strong>Passwords<\/strong>: Experts recommend having a unique password for each account \u2013 so we might need hundreds. <strong>(-1)<\/strong><br>\n<strong>Certificates<\/strong>: You could use just one! (or maybe multiple certificates derived from the same private key) <strong>(+1)<\/strong><\/p>\n\n\n\n<h2>Simplicity<\/h2>\n\n\n\n<p><em>Is the system easy to understand?<\/em><br>\n<strong>Passwords<\/strong>: People are very comfortable with the idea of passwords and how to use them <strong>(+1)<\/strong><br>\n<strong>Certificates<\/strong>: Certificate and key pairs are more complicated and people are not familiar with them yet. <strong>(-1)<\/strong><\/p>\n\n\n\n<h2>Security<\/h2>\n\n\n\n<p><strong>Passwords<\/strong>: You have to share your secret with the \nserver so if someone hacks the server, they may get your password.&nbsp; \nThere is a lot of conflicting, confusing advice about how to create hard\n to guess passwords but a password\u2019s strength generally corresponds to \nhow \u2018odd\u2019 it is and humans are generally quite predictable and struggle \nto remember and use ones that are truly \u2018odd\u2019 (e.g. randomly generated \nones.) <strong>(-1)<\/strong><br>\n<strong>Certificates<\/strong>: The secret isn\u2019t shared with any server.&nbsp;\n The private key itself is randomly generated and thus there is no \nchance of guessing using \u2018popular\u2019 keys.&nbsp; If you think that someone else\n has access to the private key, the corresponding certificate can even \nbe revoked so that all (well configured) systems will refuse to accept \nit any longer. <strong>(+1)<\/strong><\/p>\n\n\n\n<h1>Why aren\u2019t we all using certificates already?<\/h1>\n\n\n\n<p>If certificate-based authentication is so great, why isn\u2019t it more popular?<\/p>\n\n\n\n<ul><li>Websites won\u2019t use it until people want it and until web browsers support it with a nice friendly interface for it<\/li><li>Web browsers won\u2019t make a nice friendly interface until lots of websites use it and\/or until lots of users want one<\/li><li>Users aren\u2019t requesting it, probably because most aren\u2019t aware that \nit is a possibility (something this blog post hopes to change!)<\/li><\/ul>\n\n\n\n<h1>Let\u2019s see it in action<\/h1>\n\n\n\n<p>I made a demo site called <a href=\"https:\/\/www.bennish.net\/certs\/\">Certs \u2018R\u2019 Us<\/a>  that allows you to log in with an SSL client certificate, either one  generated and signed by the site itself or one from a genuine Certificate Authority.&nbsp;  It\u2019s not the prettiest of sites but it demonstrates the process nicely on recent versions of Firefox and Chrome.&nbsp; Safari had a few problems in testing and Internet Explorer should work but only with certificates generated elsewhere.<\/p>\n\n\n\n<p>Please leave any feedback as a comment to this blog post.<\/p>\n\n\n\n<p>The source code of the site (written in PHP) is available on the <a href=\"https:\/\/github.com\/fubralimited\/catn-ssl-login-demo\">fubralimited\/catn-ssl-login-demo GitHub repo<\/a>.<\/p>\n\n\n\n<h1>Summary<\/h1>\n\n\n\n<p>I hope that you\u2019ve learned a thing or two.&nbsp; Hopefully some web developers reading will consider adding SSL client certificate support to their websites.&nbsp; Maybe some of you will try to persuade the makers of your favourite web browser to improve their GUI for certificate authentication.&nbsp; Thanks for reading.&nbsp; Stay secure.<\/p>\n\n\n\n<h2>History<\/h2>\n\n\n\n<p>This post was originally posted on the <a href=\"https:\/\/catn.com\">CatN<\/a> blog on 11th July 2014 and has been reproduced here with the kind permission of <a href=\"https:\/\/www.fubra.com\">Fubra Limited<\/a>.<br><\/p>\n","protected":false},"excerpt":{"rendered":"<p>When the impact of the OpenSSL Heartbleed vulnerability became clear (along with many other recent compromises), security experts advised us to change all of our online passwords as a precaution. Of course this is a Good Idea&#x2122;, but did you actually do it or was it just another of those pieces of advice about passwords [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"templates\/template-full-width.php","format":"standard","meta":[],"categories":[10,11],"tags":[43,42,48,45],"_links":{"self":[{"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/posts\/182"}],"collection":[{"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/comments?post=182"}],"version-history":[{"count":4,"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/posts\/182\/revisions"}],"predecessor-version":[{"id":195,"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/posts\/182\/revisions\/195"}],"wp:attachment":[{"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/media?parent=182"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/categories?post=182"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bennish.net\/blog\/wp-json\/wp\/v2\/tags?post=182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}