Delegated authentication

Over the next few days we are going to talk about delegated authentication. For modern standards this falls under “What you know”. See What is authentication for further discussion.

To illustrate what delegated authentication is we will start with an all too common story. We introduce you to Mary

Mary loves social media, uploading her pictures on facebook, instagram and then tweeting them. However she is a very busy lady and does not like the work of uploading the same file to multiple servers.

As a tech savvy developer eager to impress your skills on her, you figure you can help her automate this task. The most easiest way forward would be to ask her for passwords for her three accounts then, when she uploaded a picture to your service, your service would automatically post it on all three platforms.

You immediately hit a snag with this approach, as it turns out Mary is not particularly fond of giving her password out to strangers no matter how tech savvy!

On further inspection you find out this is because she is afraid you will not only post the photos she has instructed you to, you will also go through her other stuff.

But what if you could assure her that you need access to posting photos only and not to the rest of her stuff. Prior to 2006 this just wasn’t possible but today that is exactly what delegated authentication does.

In delegated authentication you are the owner but not the direct consumer of a certain resource. To continue we must first define some key terms used in this paradigm.

  • Resource: A digital activity or data in our case this would be posting the photo
  • Delegator: This is the owner of the resource in our case here, that would be Mary
  • Delegate: The delegate wants to access the resource
  • Service provider: Hosts the resource and validates legitimacy of the delegate

It is entirely possible to build out your own delegated authentication service, however you are likely to run into interoperability problems pretty quickly. Thankfully there exists standards for this kind of authentication we will be speaking about in a later entry.

Signup to make sure you don’t miss it.

Have you ever been in the same situation as out tech savvy developer? How did you handle it? Talk to us in the comments below.


Common XML DDoS attacks

SOAP and indeed XML based architectures are a common part of the web services middle ware architecture.

However due to the high resource cost of XML parsing, even simple mistakes in design of XML documents can have catastrophic effects on the stability of your architecture. This fact makes XML based architecture especially susceptible to DDoS attacks.

Listed below are some of the most common XML based attacks.

Parsing attacks

XML files sent via SOAP requests are usually automatically parsed. The following attacks are based on this “feature”

Coercive parsing attack

As discussed, parsing XML documents is an extremely taxing task. In this attack, the attacker sends an XML document that is deeply nested.

Creating such a document is extremely easy since not all of it needs to be loaded into memory however a DOM based parser is likely to run out of memory before it can open thereby, bringing your servers down.

SOAP Array Attack

This is another attack on memory. SOAP allows triggering of remote functions, in this case the XML payload triggers the creation of an extremely large array on the remote machine.

XML element count attack

Services that automatically parse incoming SOAP requests can be brought down by a request that has an unusually high element count.

XML attribute count attack

Quite similar to the above but now with a high attribute count. The perceptive reader may have noted that this kind of attack could be combined with the element count attack for a more potent outcome.

XML Overlong Names Attack

XML nodes are usually parsed to keys in key value pairs. This nodes are element names, attribute names or values and namespace definitions. Where the nodes are extremely long some parsers will fail.

Hash collision attack (HashDoS)

Hash Table is a data structure used to implement an associative array, a structure that can map keys to values

In XML documents Hash tables are used to store attributes and their corresponding value. The value of a certain key is mapped to a storage bucket through a hash function that takes the key as input. In cases where a weak hashing function is used, an attacker can intentionally create hash collisions leading to intense computations within the bucket.

DTD attacks

DTD is an acronym for Document Type Definition it defines the structure and legal elements and attributes of an XML document. You can read up more on it here

Below as some attacks targeted at it.

XML Entity Expansion Attack

Also called the Billion Laughs Attack there is nothing funny about this attack. In this attack the XML document is structured such that the DOM parser recursively resolves entities defined within its DTD.

The parser will run out of memory long before it can resolve the document.

XML External Entity DoS Attack

DTD’s can be defined externally and a rel provided. This attacks works by forcing your server to resolve a large entity defined externally, typically in a server which the attacker controls.

Most of this attacks can be prevented by immunizing your application against them. Some measures include:

  • Lazy loading of XML documents
  • Enforcing limit on attribute count
  • Memory threshold
  • CPU time threshold
  • Authentication of all requests

Have you ever experienced a DDoS attack? Talk to us on the comments below.


What is authentication

Authentication is the process of challenging the user to prove who they are so that they can access protected resources in your system.

It usually falls under three categories:

What do you know

This is the most common type of authentication. Typically it involves providing your username and password which is then checked against the data already stored in the application’s data stores.

Despite its popularity, this method is in fact the weakest form of authentication.

We will discuss in a later article what can be done to secure it, but as basic rules, Hash the passwords and ensure the authentication happens over a secure connection.

Something you have

Most employees now a days carry a security tag that can be swept at the doors in their organization. This is a form Something you have authentication.

Github usually a similar scheme but now using ssh keys Here Github allows gives you access to your repositories by checking your client certificates.

You can read more about this type of authentication here

This is a significantly more secure method compared to What you know method.

Something you are

This is the realm of biometrics. It includes fingerprint scanners, facial recognition and even typing patterns!

This is the strongest form of authentication and is gaining popularity in the modern world, in fact some modern smartphones come equipped with a facial scanner.

You are not restricted to using only one authentication method. Lately Google and other popular web services have been popularizing two factor authentication. This is where they ask you for your username and password combination (What you know) and then send you a sms or notification to your mobile device with a code which you then fill out (What you have).

Hope you are enjoying this series so far! Lets engage in comments below.

Also consider signing up Signup to our newsletter to ensure you don’t miss out on this kind of posts and much more.