Posted on

Password Hygiene 2018

A year ago, I wrote a short list of rules or suggestions for choosing and managing passwords. I reread it today. The advice is still good, but the urgency has increased, if that is possible. The unfortunate fact is that the criminals have not let up. Law enforcement is still often stymied by cybercriminal assaults. Some assaults are from places where cybercrime laws are lax. When a crime is committed from out-of-state or out-of-country, an extradition is usually required, expenses that local law enforcement agencies often cannot afford. On top of all this, the criminals, both domestic and foreign, are getting better at their “art,” if you can call it that.

There is a bright side. The computing industry is taking security much more seriously in 2018 than they did ten years ago, even three years ago. The current arguments over election hacking, as disheartening as they are, have helped focus the spotlight on computer security. The industry has invested heavily in multi-factor and biometric authentication. Although I have reservations about biometric authentication, I’ve been using Windows 10 facial recognition authentication on my go-to tablet and I have found it convenient, although I still doubt that my device is well protected if I let it slip out of my hands. If I were a high-profile target with precious contents on my device, I would not rely on facial or fingerprint recognition to keep my contents safe.

The big news is the rise of multi-factor authentication, which I wrote about recently. Multi-factor authentication uses more than one kind of verification to authenticate the identity of a user. I will not equivocate: multi-factor authentication is always more secure than relying on a password alone. However, some forms of multi-factor are more secure than others. But multi-factor is always more trouble than simply entering a password or having your face scanned. If you are going to submit to the hassle, and I recommend you do submit when anything important is at stake, then why not choose the most secure alternative?

Verification via a token sent by email or a text message is substantially stronger than a password alone, but both email accounts and text messages are subject to hacking that is not that difficult. Use of an authentication application or a physical authentication key like Yubikey or Google Titan is much more difficult for hackers to circumvent. If I were a high-profile target, I would have a physical key.

Nevertheless, does multi-factor make good password hygiene obsolete? Absolutely not. An easily hacked password is an open door that makes the hacking life easier. And, unfortunately, some sites do not offer multi-factor authentication in any form, so password hygiene is still a necessity.

2018 password hygiene rules

  • Never use a password for more than one site or account. Some of the biggest security breaches in recent years were caused by password reuse.
  • To resist the temptation to reuse or to use easily crackable passwords, consider getting a password manager like LastPass to generate and manage long random passwords. Password managers are a single point of vulnerability. If your password manager is hacked, you are a slice of toast in a shower bath. However, a well-designed and maintained manager is much more secure than a badly managed set of weak passwords.
  • Longer passwords are better. The longer a password is, the harder it is to crack. A password 15 characters long is still hard to crack today. As computing hardware improves, longer passwords may be needed.
  • Mixing lower case and uppercase letters, numbers, and symbols like !@#$ make cracking harder, but not as much as increasing the length.
  • A long phrase is often strong and easy to remember, but common phrases, even common phrases obfuscated with tricks like replacing “s” with “$” or “o” (letter) with “0” (number), are relatively crackable. Skilled hackers know the tricks as well as you do. Start with a plain phrase that gets no hits on Google and go from there.
  • A long random sequence of mixed lower and upper case, numbers, and symbols is very hard to crack, but also hard to remember. A password manager mitigates this issue.

A final word

Quantum computing threatens to blow encrypted passwords away completely. In theory, a quantum computer could crack any password in milliseconds. This danger is theoretical and a few years in the future, but real. An outlying possibility is quantum encryption that thwarts quantum decryption, but I am aware of nothing real yet. However, because I recognize the quantum threat, I continue to explore biometric solutions and emphasize multi-factor.

A final final word

Avoid sites that are sloppy or predatory in design and management. These places are like dark alleys in a bad neighborhood. If you must deal with these sites, be sure that the benefits are worth the risk and watch yourself. If you can’t recognize cyber danger, stay away. If you are subject to hubris over cyber threats, find a secret hole and crawl in it. You are in danger.

Posted on

Two Factor Authentication

Two factor or multi-factor authentication makes computing more secure. You’ve probably seen it already and you will see more of it. I highly recommend it, with some caveats. I remain skeptical of biometric authentication. Facial, fingerprint, and retina recognition are all convenient, but they also have issues that are not ironed out yet. No matter how optimistic the sensor makers’ marketing, faces, prints, and retinas can’t be replaced when they are compromised, and there are reports of gruesome compromisations. Multi-factor authentication adds extra steps to authentication, but there is no question that additional factors increase security.

What is multi-factor authentication?

As the name suggests, multi-factor authentication requires the authenticity to be established in multiple ways. The user name and password authentication that has been used for decades uses a single piece of evidence to prove you are who you claim to be: knowledge of the correct password. Two-factor authentication adds another piece of evidence. The second piece of evidence could be a second password, but all passwords are vulnerable in the same ways, so it is better to use more than one kind of evidence.

Security specialists often talk about three types of evidence of authenticity: what you know, what you have, and what you are. A password is something you know that no one else does. A physical key is an object that only you have. Your fingerprints, your facial appearance, your retinal pattern, and your DNA are examples of something you are.

An example

Physical safes commonly use single factor authentication, sometimes multi-factor authentication. Most single factor safes have combination locks. To enter a single factor safe, you simply enter the correct sequence of numbers. If you write the sequence down, someone could find the paper; or someone could look over your shoulder and watch you dial the combination. Whoever finds the paper or watches you has access to the safe. Sneaking in is a challenge, but by no means impossible.

Bank vaults frequently have two combinations each known to a single bank officer. To open the vault, both officers must dial in their combination. One officer may be incautious or a fraudster, but the double combination prevents a single officer from getting in without a witness.

We have a safe in our home that requires both a combination and a key. I know the combination, but without the key, I can’t get in. If thieves were to successfully snatch the combination, they would still have to find the key. Often, even I can’t find the key, so they’ll have a job to get into our safe. In this way, our two-factor, key and combination safe is an annoyance, but more secure than a single-factor combination-only safe.

Multi-factor user authentication

Typical two-factor authentication uses a password and something else. One common method uses a text message sent to your phone containing a four to eight-character token. After correctly entering your password you must enter the token that is automatically sent to your phone when you enter the correct password. In other words, you must both know your password and have your phone to get into the account. Another variation is to email a token. In that case, you must both know your password and have access to your email account. These methods are harder for criminals to deal with than a simple password.

Flaws in message-based authentication

These methods are good, as long as access to your email account or phone is secure. However, email is just another account to secure, which would be better done with multi-factor authentication. To do that, you would have to have another secure email account. At a certain point, the complexity becomes unbearable.

Cellphone issues

The cellphone method also has problems with phone numbers and SIM cards. Phone numbers are assigned to SIM cards. Usually, when you buy a new phone, the you move your SIM card and your phone number, contacts, and other information moves with you. However, the service providers can reassign phone numbers to a new SIM, say when your phone is lost or destroyed, or you get a new phone that is not compatible with your old SIM.

The ever considerate and conciliating providers can easily transfer your phone number to a new SIM. They hesitate to hassle a customer too much when numbers are reassigned and they do not press a requesting customer for too much identification and verification, which means that criminals with a handful of information can get your phone number transferred to their own phone. To make matters worse, cell carrier employees are not guaranteed to be honest: they might be bribed or they may be criminals themselves. As a result, criminals have found it fairly easy to get phone numbers reassigned without the owner’s consent.

Once your phone number has been transferred, the criminal can use it to gain access to your accounts, change passwords, run up bills, and drain your bank.

The cellular providers have not been forthcoming on how often this happens, but anecdotal evidence says the practice is on the rise. There are a few things to do to protect yourself. If your provider offers a PIN for changes to your account, take it. Most important, when your number changes, you will get a notification on your phone and it will no longer work. Call your provider as quick as you can when you get a notice. Criminals can wreak havoc in minutes with a stolen phone number.

A stronger method

A better alternative is to use another authentication factor that does not depend on sending a token to you. This can take several forms, but they all involve a small application that runs on a device in your possession that produces tokens. When the application is set up, your authenticator and the application exchange information that syncs the application with the authenticator. One method provides tokens that change with the date and time. If you can’t supply the unique time-based token from the app that corresponds to your account, access is denied. Another implementation relies on a private key held on the device. An elegant implementation places the token generator in a USB device similar to a thumb drive. Plug the “key” in, authenticate, and the USB device supplies the correct token. These methods do not rely on communication after the initial setup. Neither WiFi or a cellular connection to the key device is necessary.

I noted with approval in this article in the Washington Post, that the federal government will soon require two-factor authentication for administrators of all government web sites. The method chosen by the feds is better than relying upon calling or messaging the phone. They are using Google Authenticator, which runs on an Android or Apple phone.

These methods are more secure, but not all multi-factor sites accept tokens from all authenticator apps, so you may not be able to use your choice on all accounts.

There’s a podcast on Lawfare explaining Google’s approach to advanced security that is informative.

Posted on

Blockchain Made Simple

Blockchain! Blockchain! Blockchain! That ought to get some attention. If anyone hasn’t noticed, blockchain is somewhere near the hysteria phase of the hype cycle. Everyone associates blockchain with digital currency. The apparent bubble around Bitcoin and other digital or crypto currencies adds to the intensity of the discussion. But very few people have a firm grasp of what blockchain is and it’s potential. In this blog, I will differentiate blockchain from digital currency and discuss block chain’s potential for profoundly disrupting commerce and society.

Not a single technology

First, blockchain is not a single technology. Like email, or a packet network, blockchain is a method of communication with certain qualities that many different technologies can be used to implement. The most popular implementations of blockchain (Bitcoin and its ilk) use specific technology that relies on cryptographic signatures for verifying a sequence of transactions. However, tying blockchain to a specific technology is unnecessarily limiting. The term “secure distributed ledger” is more descriptive, but secure distributed ledger is also pedantic and long-winded, so most people will continue to call it blockchain.

Essential blockchain

In essence, blockchain is a definitive statement of the result of a series of transactions that does not rely on a central authority for its validity. Putting it another way, contributions to a block chain may come from many different sources. Although the contributions are authenticated, they are not controlled by a central authority.

Think about real estate and deeds. Possession of real estate relies on courts and official records that validate ownership of physical lumps of earth. A central authority, in the form of a county records office has the official record of transactions that prove the ownership of parcels of physical land. Courts, lawyers, surveyors, title companies and individuals all contribute to the record. If you want to research the ownership of a parcel in another county, state, or country you either travel or hope that the local authority has put the records on-line and keeps them current. If you want to record a survey, deed or a sale, you must present the paperwork to the controlling local authority.

If you want to put together a real estate transaction that depends on interlocking simultaneous ownership by a complex structure of partners in parcels spread over several jurisdictions, the bureaucratic maneuvering and paperwork to complete the transaction is daunting.

Blockchain could be used to build a fully validated and universally accessible land records office that does not rely on a local authority. Instead of interacting with local jurisdictions, the blockchain would validate land information and contracts, simplifying and reducing the cost of land ownership deals.

This type of problem repeats itself in many different realms. Ownership of intellectual property, particularly digital intellectual property that travels from person to person and location to location at the speed of light presents similar problems.

Blockchains and distributed transactional databases

Although blockchain is implemented quite differently from a traditional distributed transactional database, it performs many of the same functions. Distributed transactional databases are nothing new. In preparing to write this blog, I pulled a thirty-year-old reference book from my shelf for a quick review. A distributed database is a database in which data is stored on a several computers. The data may be distinct (disjoint) or it may overlap, but the data on each computer is not a simple replica of the data on other computers in the distribution.

A transactional database is one in which each query or change to the database is a clearly defined transaction whose outcome is totally predictable based on itself and the sequence of prior transactions. For example, the amount of cash in your bank account depends on the sequence of prior deposits and withdrawals. By keeping close control of the order and amounts of transactions, your bank’s account database always accurately shows how much money you have in your account. If some transactions were not recorded, or recorded out of order, at some instance your account balance would be incorrect. You rely on the integrity of your bank for assurance that all transactions are correctly recorded.

The value added when a database is distributed is that individual databases can be smaller and maintained close to the physical origin of the data or by experts familiar with the data in the contributing database. Consequently, distributed data can be of higher quality and quicker to maintain than the enormous data lakes in central databases.

Both transactional and distributed databases are both common and easy to implement, or at least they have been implemented so many times, the techniques are well known. But when databases are supposed to be both distributed and keep transactional discipline, troubles pop up like a flush of weeds after a spring rain.

Distributed transactional databases in practice

The nasty secret is that although distributed transactional databases using something called “two-phase commit” are sound in theory and desirable to the point of sometimes being called a holy grail, in practice, they don’t work that well. If networks were reliable, distributed transactional database systems would work well and likely would have become common twenty years ago, but computer networks are not reliable. They are designed to work very well most of the time, but the inevitable trade-off is that two computers connected to the network cannot be guaranteed to be able to communicate successfully in any designated time interval. A mathematical theorem proves the inevitable trade off.

Look at a scaled up system, for example Amazon’s ordering system; if records were distributed between the distribution centers from which goods are shipped, the sources of the goods, and Amazon’s accounting system, a single order might require thousands of nearly simultaneous connections to start the goods on their way to the customer. These connections might reach over the entire globe. The probability that any one of those connections will be blocked long enough to stall the transaction is intolerably high.

Therefore, practical systems are designed to be as resilient as possible to network interruptions. In general, this means making sure that all the critical connections are within the same datacenter, which is designed with ample redundancy to guarantee that business will not halt when a daydreaming employee trips on a stray cable.

Reliable, performant transactional systems avoid widely distributed transactions. Accounts are kept in central databases and most transactions are between a local machine running a browser and a central system running in a cloud datacenter. The central database may be continuously backed up to one or more remote datacenters and the system may be prepared flip over to an alternative backup system whenever needed, but there is still a definitive central database at all times. When you buy a book on Amazon, you don’t have to wait for computers in different corners of the country and the world to chime in with assent before the transaction will complete.

That is all well and good for Amazon, where sales transactions in an enterprise resource planning database (accounting system to non-enterprise system wonks) makes sense, but not for problems that involve the coordination of many sources of truth, like the jurisdictions in our land records example above. In that case, each records office is the definitive source of truth for its share of the transaction, but there is no central authority that rules them all and we spend days and weeks wading through a snake pit of physical contacts and possibly erroneous paper when we cross jurisdictional boundaries.

Practical blockchain

This is where blockchain comes in. Imagine a land record system where rights, records, and surveys for a parcel of real estate were all recorded and anyone could record information and transfer rights by presenting a credential that proves they hold a given right, then transfer the right to a properly credentialed recipient all within a single computer interface. A chain of transactions stretching back to the beginning of the blockchain verify the participants’ data and rights. The identities of the rights holders could be required to be public or not depending on the needs of the system, but the participants can always present verifiable credentials to prove they are agents holding the rights they assert or are an authority for the data they contribute. And all this authenticated data spread over many different computer systems.

Digital currency

This is basically the way crypto currencies work. When a Bitcoin is acquired, its value is backed by a verifiable record tracing the transfers of the coin back to its moment of origin. Maintaining the record is the work of many computers distributed all over the world. Bitcoin solves the problem of the cost of maintaining the record by offering freelance maintainers, called miners, bitcoins in return for performing the maintenance. The integrity of the record is maintained through elaborate cryptographic protocols and controls. Bitcoin and similar currencies are designed to be untraceable: purchasing or selling Bitcoins require credentials, but not identities of the participants. Anonymity makes Bitcoins attractive for secret or illegal transactions.

A downside of the Bitcoin-type blockchain is the tremendous amount of expensive computing required to maintain the blockchain. In addition, some critics have charged that Bitcoin-type currencies are enormously complex schemes that promise profits based on future investments rather than true increases in value, which amounts to a Ponzi scheme. Whether Bitcoin is a Ponzi scheme is open to argument.

The red herring

Unfortunately, the crypto-currency craze is a red herring that distracts attention from blockchain’s profound disruptive potential. Stock, bond, and commodity exchanges, land record offices, supply chain accounting and ordering, tracking sales of digital assets like eBooks, and many other types of exchange rely on central clearing houses that charge for each transaction. These clearing houses facilitate exchange and collect fees without contributing substantial value. Blockchain has the potential to simplify and speed transactions and eliminate these middlemen, like Uber eliminates taxi fleets and online travel apps eliminate travel agents. Amazon eliminated publishers and literary agents for eBooks and blockchain could eliminate Amazon from eBook sales.

How can this work without a central authority holding the records of the transactions? The underlying concept is that as long as the blockchain is maintained according to rules known to a group of maintainers, no one maintainer need have central control as long as the other maintainers can detect when somebody fudges something. A proper blockchain algorithm is physically impossible to maintain in ways contrary to the rules. There is more than one way to do it. The Bitcoin model is not the only way to implement a blockchain. Paid miners and anonymity are not inherent in blockchains.

For example, an author could register an electronic document with an electronic book block chain registry. Readers could enter into a contract with the author for the right to access to the book. These contracts could be registered in the blockchain. Readers could relinquish their contracts with the author or transfer their contract to another reader and lose the right to access to the book.  The rules depend on the contracts represented in the blockchain, not the technology. Additional technology such as cryptographic keys might be used to enforce contracted book access. Unlike current DRM schemes, no authority like a publisher or an Amazon is involved, only the author, the reader, and the transaction record in the blockchain.

I’ll get more into how it’s done in another blog.

Posted on

Spectre, Meltdown, and Virtual Systems

In June of 2017 I wrote a blog for InfoWorld on How to handle the risks of hypervisor hacking. In it, I described the theoretical points where Virtual Machines (VMs) and hypervisors could be hacked. My crystal ball must have been well polished. Spectre and Meltdown prey on one of the points I described there.

What I did not predict is where the vulnerability would come from. As a software engineer, I always think about software vulnerabilities, but I tend to assume that the hardware is seldom at fault. I took one class in computer hardware design thirty years ago. Since then, my working approach is to look first for software flaws and only consider hardware when I am forced, kicking and screaming, to examine for hardware failure. This is usually a good plan for a software engineer. As a rule, when hardware fails, the device bricks (is completely dead), seldom does it continue to function. There is usually not much beyond rewriting drivers that a coder can do to fix a hardware issue. Even rewriting a driver is usually beyond me because it takes more hardware expertise than I have to write a correct driver.

In my previous blog here, I wrote that Spectre and Meltdown probably will not affect individual users much. So far, that is still true, but the real impact of these vulnerabilities is being felt by service providers, businesses, and organizations that make extensive use of virtual systems. Although the performance degradation after temporary fixes have been applied is not as serious as previously estimated, some loads are seeing serious hits and even single digit degradation can be significant is scaled up systems. Already, we’ve seen some botched fixes, which never help anyone.

Hardware flaws are more serious than software flaws for several reasons. A software flaw is usually limited to a single piece of software, often an application. A vulnerability limited to a single application is relatively easy to defend against. Just disable or uninstall the application until it is fixed. Inconvenient, but less of a problem than an operating system vulnerability that may force you to shut down many applications and halt work until the operating system supplier offers a fix to the OS. A flaw in a basic software library can be worse: it may affect many applications and operating systems. The bright side is that software patches can be written and applied quickly and even automatically installed without computer user intervention— sometimes too quickly when the fix is rushed and inadequately tested before deployment— but the interval from discovery of a vulnerability to patch deployment is usually weeks or months, not years.

Hardware chip level flaws cut a wider and longer swathe. A hardware flaw typically affects every application, operating system, and embedded system running on the hardware. In some cases, new microcode can correct hardware flaws, but in the most serious cases, new chips must be installed, and sometimes new sets of chips and new circuit boards are required. If installing microcode will not fix the problem, at the very least, someone has to physically open a case and replace a component. Not a trivial task with more than one or two boxes to fix and a major project in a data center with hundreds or thousands of devices. Often, a fix requires replacing an entire unit, either because that is the only way to fix the problem, or because replacing the entire unit is easier and ultimately cheaper.

Both Intel and AMD have announced hardware fixes to the Spectre and Meltdown vulnerabilities. The replacement chips will probably roll out within the year. The fix may only entail a single chip replacement, but it is a solid prediction that many computers will be replaced. The Spectre and Meltdown vulnerabilities exist in processors deployed ten years ago. Many of the computers using these processors are obsolete, considering that a processor over eighteen months old is often no longer supported by the manufacturer. These machines are probably cheaper to replace than upgrade, even if an upgrade is available. More recent upgradable machines will frequently be replaced anyway because upgrading a machine near the end of its lifecycle is a poor investment. Some sites will put off costly replacements. In other words, the computing industry will struggle with the issues raised by Spectre and Meltdown for years to come.

There is yet another reason vulnerabilities in hardware are worse than software vulnerabilities. The software industry is still coping with the aftermath of a period when computer security was given inadequate attention. At the turn of the 21st century, most developers had no idea that losses due to insecure computing would soon be measured in billions of dollars per year. The industry has changed— software engineers no longer dismiss security as an optional afterthought, but a decade after the problems became unmistakable, we are still learning to build secure software. I discuss this at length in my book, Personal Cybersecurity.

Spectre and Meltdown suggest that the hardware side may not have taken security as seriously as the software side. Now that criminal and state-sponsored hackers are aware that hardware has vulnerabilities, they will begin to look hard to find new flaws in hardware for subverting systems. A whole new world of hacking possibilities awaits.

We know from the software experience that it takes time for engineers to develop and internalize methodologies for creating secure systems. We can hope that hardware engineers will take advantage of software security lessons, but secure processor design methodologies are unlikely to appear overnight, and a backlog of insecure hardware surprises may be waiting for us.

The next year or two promises to be interesting.