March 28, 2011, 4:01 PM — This week I found out that my company is developing software in-house. Until now I hadn't known that we were a software development shop, but I guess I shouldn't be surprised. Most companies that I've been with have developed their own software for one purpose or another. I only learned about this software development project when one of the programmers approached me to ask about the best way to store usernames and passwords in the application's database. Yes, that's right -- they built the authentication right inside the application, instead of calling out to an external authentication source.
If you're like me, you're thinking this is crazy. Why build an authentication capability into an application when we already have Active Directory? Seems to me that using Microsoft APIs to perform user authentication would be a lot easier. But I'm not a programmer. I have no idea why people build their own authentication into applications. At my company, we use a lot of off-the-shelf applications, and it seems like only about half of them work with Active Directory. The rest have their own built-in usernames and passwords. So it's not uncommon.
In this case, my company is setting up a new Web-based service for our customers. We use a lot of software-as-a-service (SaaS) applications over the Internet, and I've put each of them through a thorough vendor security review. I want to do the same thing for our new service, now that we are getting into the SaaS business. I'm sure some of our customers will want the same level of security assurance (although I'm consistently amazed when I'm the "first" to review the security of a particular service -- even big-name companies neglect this process). I've written about "The need for real security in a virtual world" (link) and Matthias Thurman wrote about "Stopping stupid human tricks" (link), and this situation is a different but similar take on the subject.
