Mike_Mitchell

Security for Separated Solutions

Discussion created by Mike_Mitchell Expert on Apr 24, 2018
Latest reply on Apr 25, 2018 by shblackwell

There's quite a good discussion going on in another thread (A Conversation About '2 Factor Authentication') regarding the dangers of attempting to use so-called "ersatz" security measures. Rather than derail that thread, I wanted to go off on a tangent and get the community's opinion on a particular situation I've run across a time or three.

 

Here's the scenario: You have a separated solution; say it's the simplest configuration, one interface file and one data file. The big benefit of using such a setup (or at least one of them) is the flexibility of simply changing out the interface file for minor changes to interface or scripting - thus avoiding a data migration. That's helpful, except it also means wiping out all the users' accounts in the interface file (assuming you don't have their passwords and can't reset them manually, which you shouldn't).

 

So this is a situation where a developer can be tempted to use a "low level" login to the interface file and then use scripting to actually authenticate the user. (If you want an enthusiastic discussion for why this is a bad idea, see the thread above.) You might do that because you somehow need to identify the user's appropriate privileges in the interface file for your scripting to work.

 

However, we also don't want to deal with having to change out all the users' accounts. And, just for the sake of being difficult, let's say this solution can't use external authentication (either offline mobile, or on an isolated network that doesn't have access to AD or OD).

 

Let's grant up front that external authentication is the best answer, just to avoid the inevitable "you should use external authentication" comments. Given the somewhat artificial environment, what would be the best practice for managing security in such a solution? Just suck it up and reset passwords after each upgrade?

Outcomes