Application Security


I keep running into the comment that security is hard. I've often claimed that it's no harder than a breadth-first tree traversal. I'm starting to think that I've been stretching it a bit, because they're two entirely different types of problem.

A breadth-first tree traversal is an algorithm. It has many uses. In the example below I use it to find an item in a Windows Forms TreeView control called Item_TreeView (click the little + sign to view the code):

#Region "GetTreeNode"
    Protected Function GetTreeNode(ByVal itemGuid As Guid) As TreeNode

        Dim _TreeNode As TreeNode = Nothing
        Dim _Queue As Collection = New Collection

        For i As Integer = 0 To Item_TreeView.Nodes.Count - 1


            Do While _Queue.Count > 0

                ' Retrieve the node and remove it from the queue.
                Dim _InspectTreeNode As TreeNode = CType(_Queue(1), TreeNode)

                ' Inspect the node.
                If itemGuid.Equals(_TreeNode.Tag) Then
                    _TreeNode = _InspectTreeNode
                    Exit Do
                End If

                ' Add the node's children to the queue.
                For j As Integer = 0 To _InspectTreeNode.Nodes.Count - 1


            ' Exit loop if the tree node was found.
            If _TreeNode IsNot Nothing Then
                Exit For
            End If



        Return _TreeNode

    End Function

#End Region

Security (in the sense of application security) is not an algorithm. It's a whole bunch of stuff, ranging from input validation and parameterised SQL queries, to protocols. Protocols are a good place to start, because so little about them is readily available to developers.

I'm going to use a (relatively common) scenario in which two principals want to communicate, and want to use a trusted third party to effect an introduction. As per convention, we'll give the principals human names to avoid getting lost in too much algebraic notation. So we'll call the two communicating principals 'Alice' and 'Bob', and the trusted third party 'Sam'.

So, a simple authentication protocol could run as follows:

  1. Alice calls Sam and asks for a key for communicating with Bob.
  2. Sam responds by sending Alice a pair of certificates. Each contains a copy of a key. The first is encrypted so that only Alice can read it, and the second is encrypted so that only Bob can read it.
  3. Alice then calls Bob and presents the second certificate as her introduction. Each of them decrypts the appropriate certificate under the key they share with Sam and thereby gets access to the new key. Alice can now use the key to send encrypted messages to Bob, and to receive messages from him in return.

Replay attacks are a known problem with authentication protocols, so in order that both Alice and Bob can check that the certificates are fresh, Sam may include a timestamp in each of them. Using protocol notation, this could be described as:

    A → S: A, B
    S → A: {A,B,KAB,T}KAS,{A,B,KAB,T}KBS
    A → B: {A,B,KAB,T}KBS,{M}KAB

This is a theoretical representation of an authentication protocol. Cool. But it raises more questions than it answers. Why would we use it? Where would we use it? And how is it implemented? The protocol also makes some assumptions. It assumes that both Alice and Bob have an existing relatioship with Sam. How is that relationship with Sam established?

Coding that authentication protocol up isn't trivial, and answering those questions requires an understanding of both the environment the application will live in, the usage scenarios, and the constraints the application itself faces (budget, for instance).

In conclusion, I think security is easy enough to grasp. The problem is one of scope - security is an immensely broad and deep topic. I was probably unfair then, equating application security to a simple algorithm. I still believe that security is not fundamentally difficult. There is however, a lot to take in and know. Writing a secure app is lots and lots... and lots of hard work, which I think is another reason that it doesn't happen often.

Home | Blog | Photos | Contact | About and all content copyright 1995-2018 by Michael Wittenburg, unless otherwise stated.
All content on this site is licensed under the Creative Commons license, unless otherwise stated. uses a single session cookie because it's required by the tech underlying the site (Microsoft ASP.NET). The cookie stores no information and seves no functional purpose.