Web Forum Migration

First off, I am a software developer with some hardware tinkering skills. I’ve been programming for 34 years and have seen a fair bit. One piece of technology I did not have to deal with was punch cards. Oh I used them during school for recording test answers but never actually programmed with them.

I started “online” using dial up bulletin boards. There were some local access points and I got onto CompuServe as well. At university they had their own discussion areas that were often tied into other educational facilities.
The one thing all these had in common was limited access and everything was text only. And every thing just worked.

Time passes and along comes the Internet, the dial up boards fade away with some making the switch to closed communities and others becoming Newsgroups that are replicated around the world. The newsgroups were either public, private, or limited access. Some companies used semi-private newsgroups for support. Other servers may have replicated the public newsgroups. Security was embedded within the newsgroup communication protocol.

More time passes, email and web browsing have increased significantly. Security issues have also increased significantly.

Now, as to the title of this particular post, I have seen an increase in developer resources moving away from newsgroups to a web browser based forum. The reason posted by the resource providers is to allow for increased flexibility in what they serve to me. This seems to follow the online mantra of “more bling less content”. The only useful part I have found so far is some visual formatting that can be applied.

So lets look at what this move means for me.

My current setup has one application that aggregates all my various feeds where I can pick out interesting bits quickly. I can have them stored offline for future reference easily. If the internet is not accessible I still have the information available (i.e. construction, accidents, intentional destruction). Security is built in and deployed were desired.

The web forums are often deployed as a standalone silo. Each site needs to be accessed separately thus decreasing my available time. Some sites offer RSS feeds but you still have to visit the site to respond or do anything. Some sites use over-the-wire encryption (SSL/TLS) but then use an application password. Some site want to use a “social media” password (i.e. Facebook) while granting them access to your “friends”.

The use of an application password means that the application controls security not the server. Logging, reporting, auditing, and other requirements are by the application.
Since the application controls security this leads to numerous opportunities for failure. Every “page” deployed can be a target, hence the number of exploits in the news.

My web apps use server based passwords (or certificates) rather than an application password. I feed the server password into the application’s security. Most of the web frameworks I have looked at do not do this. This means that an attacker has to have valid credentials before they can access any of my site’s content. What data the attacker can exploit is dependant upon the credentials used as these are also used to access the database. This is a good thing unlike the connection pool where all data is available.

My primary software revolves around the trucking industry: shipping, storage, logistics, packing.
With the increasing number of “regulations” and “compliance” requirements I built most of the security into the database directly. This way security is enforced regardless of client. Auditing and logging is done the same way. So all of the AAA functions are deployed at the lowest level of the system and are utilized by every client automatically.
Most web frameworks, that I have looked at, with an application level password access the database via a pool of connections using a single user account. This is to reduce the load on the database server but comes at the cost of security. If your system has multiple client apps then each client app has to have its own AAA setup and a mistake in any of the clients could be costly.

Bookmark the permalink.

Comments are closed.