United’s poor “multi-factor authentication”

United Airlines (united.com) recently “upgraded” their Web site security. They sensibly discontinued 4-digit PIN logins and require a password of at least 8 characters – standard practice these days. It would’ve been a reasonable change, if they didn’t leave a loophole one can fly an airliner through.

As a compliment to stronger passwords, united.com also required account holders to set up “secret questions”. Leaving aside the question whether this is a good security measure in general, United’s implementation is recklessly poor. A user can’t enter their own answer – one must select from a small list of curated items. For the question “What color was the home you grew up in?”, there are 12 choices available. “What is your favorite cold weather activity?” gives you 23 options. Those are low numbers – but it gets worse! When trying to reset a password, a user will be presented with 2 questions – and only 10 choices to select from for each question!

United reset password fruit 1-10

So you only need to guess 1 out of 10 twice – and you are in.

This is not extra security, this is security theater. But of course in air travel, security theater is the norm (great job, TSA!)

Are True Names in Earthsea digital encryption keys?

I’ve recently reread Earthsea, a classic fantasy novel by Ursula LeGuin. The novel is set in a magic world and tracks the progress of Ged, a mage with unprecedented powers, from his childhood to adulthood. Keeping in mind an often cited quote by another classic writer, Arthur C Clarke: “Any sufficiently advanced technology is indistinguishable from magic”, I decided to peel back the curtain of magic and imagine what practical inventions may stand behind the magical concepts of the Earthsea world. I’m most interested in the concept of true names. I will show how true names could relate to modern day digital encryption – with a mage’s true name being his personal digital certificate.

Some of the technology behind the magic in the book is trivially easy to see. For example, when Ged applied a spell to a brackish spring on a tiny sea island, it means he’s installed a filtration system. Water desalination was a plausible alternative, but, since it is more complex and bulky (using modern technology), it would be less likely.

There are many cases when figuring out the exact technical solution is impractical because it is described in magical terms. Now, any technology would look like magic to people who don’t understand it. They would simply have no concepts to explain it and wouldn’t know where to look for clues. So naturally people in medievalist societies where magic fantasies are usually set can’t provide adequate descriptions of advanced technology they mistake for magic. Hence the readers lack cues to accurately translate the magic to the modern day technical concepts. This is certainly by design.

With this, let’s get to true names, the most creative and crucially important device in this book. Many entities in the Earthsea universe have secret true names, which have special magic meaning. Here’s what we know about true names:

  • Humans, other live beings and geographical objects (seas and islands) have true names.
  • Each human has a unique true name.
  • True name is permanent and can’t be changed.
  • Animals have one true name for the whole specie.
  • Ged’s true name was assigned to him by a mage when he was near puberty. He didn’t have a true name before that. Many other people aged from 14 and up also have true names. No human person other than child Ged is specifically described as having no true name.
  • True names can be used by beings with magical powers (human mages and dragons) to control behavior of the name bearer

What we don’t know:

  • Do human-made objects (such as houses and boats) have true names? We know that spells are routinely applied to them, but it’s not clear if such spells require knowing the true name of the object.
  • Do all humans get their true names assigned by mages in their teen years? There is not enough information is Earthsea to draw conclusions (and I didn’t read sequels to Earthsea).

Based on what we know, true names must mean different things for humans, animals and inanimate objects. This would explain the fact that human true names are individual, but animals of the same specie share the same true name. We also know that there are several kinds of magic, taught by different Master Mages. It stands to reason that if true names unlock different kinds of magic, then the true names themselves may be of different types. Let’s start with animals, which seem to be the easiest case. For animals, the logical true name would be a DNA signature. The magic it enables is, then, biotech-based.

For humans, we could also go with personally targeted bio. One example of this is found in Vernor Vinge’s book Rainbows End. The book is mostly about near term advanced digital technology and augmented reality. At one point Alice Gu is incapacitated by a virus targeted to her individually. The creation of the virus required collection of her DNA sample.

There are other ways to individually target humans. The simplest one is an identifier issued by a competent authority, something like a Social Security Number in US. And it doesn’t have to be a number – it could be just a name. After all, only a few years after Earthsea, Ursula LeGuin uses this idea in her book Dispossessed – individual names are unique and assigned on planet-wide basis.

In this case, determining someone’s true name would be roughly equivalent to modern day identity theft. We know that identity theft enables the thief to take over the victim’s accounts, disrupting his ability to communicate and access to finances. It can be really demoralizing, which matches the effect of an adversary knowing your true name (rendering you unable to defend yourself). For this to work, the target has to be quite advanced and sophisticated: medieval subsistence farmers won’t suffer much from identity theft, because they don’t bank or use Skype. From the book, it’s not clear whether revealing of the true name is equally damaging to different people. We know that it has debilitating effect on mages, but they are a unique cast living by special rules. We have to assume that they are the super-sophisticated hi-tech elite of the Earthsea, so they could indeed suffer from identity theft.

Another possibility is a breach of anonymity. In one of the first Sci-Fi books of the digital era, True Names, Vernor Vinge shows how cyberspace character is in grave danger if his real world identity is exposed. Thus, true name is simply the real name in the physical world. In the True Names, the danger comes from the government, which is able to apply its heavy hand to coerce desired behavior in cyberspace. But “we know where you live” has also been an effective threat from non-government actors, such as mafia, KKK and jihadists. In the Internet era this threat has increased in poignancy and acquired a new name: doxing.

Finally, here’s the tantalizing possibility: true name could be a person’s private encryption key. Such a key is necessary to create digital signatures proving authenticity of communications. And it must be kept secret, otherwise an attacker could impersonate the victim. Again, this will only work against hi-tech targets dependent on electronic gadgets and communication services. If you are a mage deploying an array of electronic devices, sensors, weapons and so on, a lost private key means that your adversary can now impersonate you in all digital communications. He can issue commands that will appear to be coming from you. He can control all of your devices and turn your weapons against you, which must spell quick and immediate defeat. The threat is made more severe by the fact that in the Earthsea, the key (true name) can’t be changed. We can see the impact of this oversight in the book, where once someone’s true name is known, that person (or dragon) remains in danger forever. An ability to change keys is a fundamental tenet of modern crypto systems: if keys are stolen, changing the keys (think passwords) allows a quick closing of the security breach. Changing keys is so important that some security experts advise against biometric security (e.g. fingerprints or retina scans) because the secrets are unchangeable. Once your fingerprints make it into the wrong hands, you are as helpless as a wizard of Earthsea whose true name has been revealed.

If true names can be understood in terms of  digital encryption, then a book on the current FBI vs Apple encryption fight was written half a century ago.

Security for WESB services: WSRR as a good-governance alternative to LDAP groups

Quite frequently, access to Enterprise Services is secured based on individual user, but on requesting application (department, organization, org unit, etc). If one or another application in your company consumes an Enterprise Service, you may not be particularly interested in the identity of individual user behind a screen who clicked a button on an internal Web page, resulting in Web application making a call to mainframe behind the scenes. Knowing that the call came from a known internal application may be enough. In fact, often times there will be no individual user at all: the service call may be coming from a batch or unattended process.

If your Enterprise Service is hosted on WebSphere Enterprise Service Bus (WESB), how do you configure security (authentication/authorization) for this scenario? One obvious option is to leverage standard security mechanisms of WESB, which are effectively J2EE based. Create an ID for each requester application in your enterprise LDAP and use standard role-based access control to authorize access. Normally, you will create an LDAP group for each services access role and assign application IDs to those LDAP groups. This approach is simple and familiar to enterprises. But I can see one shortcoming: governance is often difficult to establish.

Defining access policies for enterprise services is responsibility of Enterprise Architects. But it is difficult to do this using LDAP. In a typical enterprise, processes for governing LDAP security changes are geared toward end user access. Roles, personnel involved, tools, ticket approval systems – everything is set up to deal with end user accounts. Enterprise architects are not involved in this process and would not be comfortable with security tools, because individual account maintenance is not their responsibility. Looking at the problem from the other side, security administrators may not even want to give Enterprise Architects access to account data that is required to effectively govern service account roles.

One possible solution to the governance dilemma is to use a true service governance tool, such as WebSphere Service Registry and Repository (WSRR). WSRR comes with a prebuilt governance templates in “Governance Enablement Profile”, including definition of SLA. If you establish an SLA between each service consumer application (department, etc) and consumed service. Then, in WESB (or WPS), you can insert “SLA Check” mediation primitive before actual invocation of a service. SLA Check primitive is new to WID/WESB/WPS version 7.0. It is very simple: it consults configured WSRR instance to determine whether there an SLA for particular service exists (for a particular user and in a particular context) and returns a simple yes or no. Now your service access is under control of WSRR, which Enterprise Architects understand and (hopefully) use daily. Service access is governed by the same tool as all other aspects of the service.

Problem solved? Unfortunately, WSRR solution has several shortcomings of its own:

  • LDAP-driven security is declarative, but WSRR-driven requires SLA Check primitive to be inserted (is programmatic)
  • Out of the box SLA lifecycle is quite evolved and requires several document types to complete. It is likely too complex for a simple task of service authorization
  • Establishing an SLA for every consumer-service pair is a lot of work.

All in all, I would recommend using SLA Check for service authorization if you highly value service governance, are unsatisfied with LDAP governance tools and process and prepared for the task of creating a massive number of SLAs. Otherwise, LDAP role-based security is still a more reasonable choice.

Identify service requestor application for MQ and Web services

Suppose you are establishing SOA in an organization that is quite new to the concept. They have a developed MQ infrastructure and are quickly building up enterprise Web Services catalog. A lot of existing functionality and legacy applications will be exposed as Web Services and MQ. You must continue to support MQ services because there is still a large number of MQ clients there that can not be reasonably changed. But enterprise architects want to gain better control of the enterprise services, including both Web Services and MQ. They want to establish service governance. All service consumers will be required to subscribe to the services they need and establish an SLA. To enforce this policy, Enterprise Service Bus in the middle of SOA landscape will need to authenticate requester and verify SLA. Authentication needs to be done on application level, not individual user level, because SLA is established for departments/LOBs and not for users.

What is the easiest way to find out which application sent an MQ request message? Consider this constraint: source applications can not be modified to insert their identity into the message. First, I will assume that I can differentiate applications by Queue Manager: each QM from which request messages may be sent will represent only one application. This is already the case, but even it was not, we could create additional QMs as required and reconfigure some applications to use new QMs. With this assumption, my problem has been reduced to identifying Queue Manager that sent each message. After that I can use a table to map QM name to application name. This can be done in several ways. It can be done quite elegantly by WebSphere Message Broker. It can be done by MQ means alone, in a way that is both cute and ugly at the same time:

  • create a user account for each source QM
  • on a “central” QM, create a queue for each source Queue Manager
  • limit PUT on each of these queues to a single user corresponding to its QM
  • configure MCAUSER on channels

With some trimming around the edges, I can guarantee that messages on each of these queues have arrived from a single QM.

This is quite a bit of work. I can achieve a rough first cut of a solution much easier. I will add an assumption that only request-response pattern is used (no datagrams, all request messages require a response). Now I can identify service requester by finding where the reply message goes. That’s right: ReplyToQMgr property of MQMD structure carries the name of Queue Manager that expects a response. Under normal circumstances, by looking at this property we can identify which QM sent the message because it is the same QM that the response will be sent to. All that’s left is control for spoofed messages, which is an open item as of now.

Java2 security and IBM WebSphere adapters

Don’t you love Java2 security? When enabled, it limits what your Java programs can do – by program, not by user ID. You would have to give code specific permissions to read/write files, access sockets, etc. Sounds great, doesn’t it? Well, it does not, at least in the world of enterprise and Web software where I live. In all my years in consulting going from one company to another I’ve seen only one place that used Java2 security. All others decided that it is more hassle then benefit.

And here’s another strike against it: when Java2 security is enabled in WebSphere Enterprise Service Bus (ESB) in a clustered environment, WebSphere adapter for CICS ECI does not work properly. You could see ClassNotFound exceptions when accessing the adapter. IBM support resolved the issue right away: just turn off Java2 security.