chicken and egg

Over the course of my programming lifetime, sometimes the hardest part of setting up a web application has to do with how the logic plays out.  As human beings, we have a way of reasoning things, we can interpret symbols and relationships and we can’t quite explain how we do that.  When working with programming, we have to be able to explain those unexplainable things, otherwise we can’t make the computer do what it needs to do.  Sometimes we run into a “which comes first the chicken or the egg” situation. As we all know, when we reference a chicken and egg argument, there are usually two sides to an argument, both believing that their side comes first.  (Of course in the chicken and egg situation, I will inevitably wind up finding a creationist that says “obviously the chicken comes first” but that is neither here nor there for this discussion.)   One of these situations has occurred recently, and another has been a struggle for several years, still finding no solution.

The other day we were sorting out the logic for how we are going to define the billing processes for our many services.  We have our search engine optimization, hosting, email, ftp etc and all are tied to a client, but each are only tied to a certain website… but websites may be one or many urls, and each url would then perhaps have different hosting.  The long story short, eventually we just decided how the logic was going to work, so that we could begin working on the programming.

Another constant struggle is the issue of data security.  For most sites that hold secure data, we have to implement some sort of data encryption to keep that data safe should some malcontent try to get to that data, and succeed.  It’s just part of the minimization of risk to us and our clients and our clients’ clients, we want people to be safe and secure.  Now in order to encrypt that data, we need to use some sort of reversible encryption, which means storing an encryption key that we can plug in to our various encryption methods to get back the data we need.  Now, how do we keep that key secure?  Well, we could encrypt the key.  How do we decrypt the encryption key?  We need another key.  And the bear went over the mountain, and what did you think he saw?  He saw another mountain.  Generally speaking, since we don’t recommend storing credit cards, there’s not REALLY a huge need for encryption of this sort.  We can indeed use a hash function for passwords which then compares the hash of the entered password with the hash that is in the database.  That’s simple.  But then we have to have a password retrieval system, which in itself is rather insecure (Governor Palin ring a bell?).  At least that would limit to one random person being ‘hacked’.    So what we have to do is decide on a key storage system that works for us, which seems to be the answer that everyone says.  I think like us, they make a decision and just don’t want to tell anyone about it, because it’d make it that less secure.  I can’t help but laugh at that statement.