Author: Dariusz Glowinski

Password Authentication Methods

In 2017, Professor Hankin penned an excellent article on the Imperial Institute for Security Science & Technology (ISST) blog, where he discussed the subject of cyber-trust, cyber-metrics, and the gradual demise of passwords as a single authentication method.

How the Internet of Things poses fresh risks to public sector systems

An excellent article. I wholeheartedly concur with Professor Hankin that passwords, as a security authentication method, no longer address the security requirements for the modern era of distributed computing. Gone are the days of the standalone desktop PC in the corner of the office, where users just needed a few passwords.

The growth of social/professional media platforms, portals, and commercial sites has increased considerably in terms of numbers and complexity, alongside an exponential growth in the rate of IoT deployments. In 2017, predictions based upon some estimates indicated that Internet-connected devices were set to rise to more than 50bn by 2020.

The number of IoT devices is predicted to exponentially increase according to Statista: https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

PETRAS, the Internet of Things (IoT) Research Hub is a consortium of eleven leading UK universities which will work together over the next three years to explore critical issues in privacy, ethics, trust, reliability, acceptability, and security.

PETRAS

Under the ‘Publications’ tab, the PETRAS site has published a series of ‘Little Books’ which address various IoT ‘themes’, an excellent resource for all things IoT.

  • The Little Book of Philosophy for the Internet of Things
  • Little Book of Connected Environments and the Internet of Things
  • The Little Book of Creating Value through Design in the IoT
  • The Little Book of Critical Infrastructure and the Internet of Things
  • The Little Book of Sustainability for the Internet of Things
  • Little Book of Design Fiction for the Internet of Things
 The phrase ‘Internet of Things’ or IoT as it is now commonly known was originally coined by a British tech pioneer, Kevin Ashton in 1999. However, the first ‘IoT’ device ever produced was a drink vending machine, modified in 1982 by Carnegie Mellon University, Pennsylvania, USA, which was able to gather and report telemetry-data on inventory status and environmental updates.

Authentication methods are rapidly evolving and passwords, or rather encoded password hashes, will progressively play only a secondary role in the new ‘cyber-metrics’ paradigm discussed in Professor Hankins’s article.

The principal problem with passwords is that they are very personal. IT consumers have a love/hate relationship with passwords. Passwords give a nice warm fuzzy feeling of security. The puppy’s name, my child’s name, my football team, a favorite band…, the list is endless. My password is my home’. I choose my password, and I control where it should be applied, it is mine. All this with little realisation that those self-same passwords already exist within many brute force password lists and are not secure in the slightest.

Case in point, a 55-character password was cracked using HashCat with just such a brute force password list. The password in question was ‘Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn1’, a quote from an HP Lovecraft story. Please see the below link if you are interested.

https://www.infosecurity-magazine.com/news/password-cracker-cracks-55-character-passwords

What this demonstrates is that password length is no longer as important as it used to be; instead, it is what the user does with the password characters available. Password length, while still significant, should not be just a combination of easily remembered words or phrases, but instead, it should be an inter-mix of character, numbers and punctuation symbols.

For example, instead of ‘Arsenal123’ or ‘ArsenalRules123’we could have ‘Ars3nal_Rul3s_F0r3v3r’, which is still insecure as it exists on several password lists. Much less crackable, we could have ‘_ArsenalMug+Tea&Biscuits123’.

Better yet, for the polyglots, a mix of languages aids the complexity enormously, e.g. ‘SweetTea, in itself a very poor password might become ‘D0lce&T3a’ or ‘m3lysiHerbatka’ or D0lce_caj. The possibilities are endless.

The bitter truth is that password randomness/unpredictability now trumps both password length and password complexity. The problem is that we, as IT consumers, have always been told to rely on password length. As time progressed, password complexity was deemed sufficient, and now both length and complexity are required at the corporate level. Introducing and getting used to the new concept of ‘randomness’ which, as a property, is difficult to work with, challenging to remember, and will take time. Technology can help in the form of password management software packages like DashLane, PasswordBoss, LogMeOnce, and stickyPassword.

Professor Hankin makes two other excellent and highly relevant points, namely the frequent lack of separation between ‘consumer’ devices and ‘corporate’ operational systems, a common trait in the latest ‘bring your own device’ BYOD trend and the convergence of IT with the control systems built into our critical infrastructure and industrial processes. Such traversal attack-vectors are realisable by hackers in part due to programmers and developers having a poor understanding of security, and partly because implementing said security costs both time and money.

Building secure IT systems

IT Security needs to be built into IT systems. Building secure IT systems goes beyond a simplistic rhetoric of raising security awareness to everyone employed in IT operational roles, such as the data entry clerks, the systems engineers, webmasters, application developers, network architects, IT managers, etc.

It is important to appreciate that these IT roles must work together; conforming to defined operational ‘frameworks’ and established industry ‘standards’ to eventually create consumable IT products which can be certified as secure, rather than just being labelled as such. Such symbiosis is difficult to achieve.

Say you want to look up the latest football scores, or check the latest lottery results, or to simply go online to check your bank balance and purchase a gift for Mum’s birthday. These online actions and interactions are simple, everyday use-cases upon which Internet users have come to expect.

Building secure IT systems to facilitate such a plethora of Internet use-cases, many sub-systems and discrete disciplines must come together. A database application DBMS must run on a “PC operating system” of some description, the data-entry clerk must then be able to populate the database records, and finally a webmaster must configure a webserver to query the database objects safely and securely on a Web Hosting server somewhere on the big bad Internet and render them as a web-page to a browser.

Of course, the trick is to do all this securely….

IT systems deployment is not dissimilar to any other marketable goods. A good analogy is the milk production/distribution cycle.

‘Milk in a carton’, a common consumable foodstuff, is the product of many different disciplines coming together, working to a common framework and complying with a set of standards to ensure that milk delivered to us is fresh, convenient, and most importantly, it is safe to drink.

That is where the analogy ends…

Whereas in the milk production illustration, hygiene is the primary concern throughout each stage of the production process; within the IT services community, ‘security’ is, too often, the last consideration of the design process.

Oftentimes, a new IT system is designed and built using a proof of concept (POC) methodology. The POC methodology rarely implements any type of security and has just one aim, to test new system functionality at a user/system level. Once a POC is accepted, the IT system is built, and security is bolted on at the end of the build. This is known as the locking down process. The fact that ‘locking down’ is itself a defined process indicates a general malaise within IT systems engineering.

Whilst a post-build period of User Acceptance Testing (UAT) is carried out and vulnerability assessments (ITHC) are commissioned, these assessments are usually an “accreditation” issue. Often, these end up being a box ticking exercise to finalise a project prior to production rollout. As such, these vulnerability assessments do not always identify and address the underlying weaknesses inherent in the system design. Douglas Adams, in his book, ‘’So Long, and Thanks for All the Fish’, refers to the Sirius Cybernetics Corporation (a sort of intergalactic IOT technology vendor), and articulates this very point when he facetiously writes “…their fundamental design flaws are completely hidden by their superficial design flaws…” (Adams. D, 1984).

Case in point, when Cisco upgraded their IOS images to a supposedly more secure model, they forgot to ‘salt’ the ENABLE SECRET password hashing algorithm used by the IOS firmware to secure their devices. Hash salting is a method for strengthening an encryption process. The resultant password hashes were easy to reverse-engineer and as such they were much weaker than the earlier MD5 encrypted password hashes that they were meant to replace. This oversight was quickly remediated with a patched update, but it does serve as an example of how systemic IT security flaws can and do occur.

Another major OS security issue is Linux’s ‘Systemd’ component which has been found to contain multiple vulnerabilities. Then there is the ‘OpenSSL’ module, an open source security implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) cryptographic protocols which has had its share of troubles with ‘Heartbleed’, ‘RSA timing’ attacks, and other vulnerabilities.

Industrial IT systems aside, until “IT Systems Security’ matures from its current fragmented and siloed form, where each link of the chain implements security exclusively within its own domain, with the expectation that the next link addresses the overall system security, the onus will remain with the poor user who is usually unable to comprehend the complexities of IT security configuration on his or her PC. Such difficulty is further compounded when trying to configure complex software modules like a personal host firewall (HIDS/HIPS) or a tweaking of browser security settings.

Things are changing for the better; the IT security model is maturing. Only a few years ago, a major broadband provider was providing Internet routers with a three character default admin password for all of their Internet-connected devices, and PC operating systems (OS) had no protection whatsoever, the IT security landscape has changed significantly. Broadband routers now have enhanced security straight out of the box, PCs and laptops now include integrated firewalls as standard, and data storage manufactures have started producing encrypted hard drives.

But we need to go further. When building secure IT systems, we must recognise that the IT security threatscape is unclear, shifting, and constantly evolving. New viruses, malware, and ransomware variants proliferate daily and spread quickly across high bandwidth Internet links. IT consumers must not only be educated to recognise these cyber dangers; they also need to feel empowered to react to possible IT security threats.

Building secure IT systems transcends the old paradigm of traditional IT roles. A synergy needs to be established between the IT consumers and their supporting IT staff. IT consumers need assurances that by reporting potential breaches, downloaded viruses and malware, data leaks, password/pin demands, etc., they will not be patronised or vilified by IT departments and that their contribution to IT security enhancement within the organisation is valued and appreciated.

Dariusz Glowinski
Originally posted August 2016