¿Cuáles son algunas alternativas posibles para proporcionar una 'Contraseña de administrador' para una aplicación de escritorio?

Actualmente estoy administrando y refabricando una pieza de software que se ha utilizado en mi empresa durante más de una década. Uno de los elementos de esta aplicación es una especie de modo de administrador o usuario avanzado que proporciona elementos como entrada adicional / interna, así como la capacidad de desactivar los límites de entrada.

Históricamente, este modo se ha activado colocando un archivo con un nombre específico en un lugar específico en el directorio del sistema de Windows (ambos codificados en la aplicación), el archivo se llamaba 'something.DLL', a pesar de que estaba vacío Archivo ASCII y no un dll.

Así que recientemente agregué un código y una pequeña forma modal que permite al usuario ingresar una contraseña de administrador para activar esta funcionalidad. Es una contraseña establecida, no específica del usuario. Cuando se ingresa la contraseña correcta, hace lo mismo al crear un 'archivo de clave' en el directorio raíz de las aplicaciones para que el programa pueda iniciarse en modo administrador si ese archivo está presente.

Ahora, al gerente del departamento para el que es principalmente este software no le gusta mucho esa idea. Él piensa que si solo tenemos una contraseña simple y preestablecida, se 'saldrá' fácilmente, y no quiere que los usuarios inexpertos accedan a esas funciones adicionales.

Entonces, mi pregunta es, ¿qué otros métodos existen para proporcionar este tipo de acceso que sería algo más seguro? Soy solo yo cuando se trata de mantener y administrar este software, por lo que cualquier cosa que no esté casi completamente integrada o automatizada no ayudaría (como enviar solicitudes de 'claves de licencia' o algo similar).

Notas: Esta aplicación está escrita en VB.NET (.NET 4.0), y actualmente estoy planeando usar la implementación de hacer clic una vez cuando finalice la nueva versión.

Si tiene Active Directory, puede probar la membresía en un grupo de Active Directory:

public bool IsInADGroup(string ADGroupName)
    {
        bool result = false;
        List<string> myGroups = new List<string>();

        using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, SystemInformation.UserDomainName))
        {
            using (PrincipalSearchResult<Principal> src = UserPrincipal.FindByIdentity(pc, SystemInformation.UserName).GetGroups(pc))
            {
                src.ToList().ForEach(sr => myGroups.Add(sr.SamAccountName));
            }
        }
        result = myGroups.Contains(ADGroupName);
        return result;
    }

El gerente tiene razón acerca de la contraseña . No es cuestión de si, sino de cuándo.

Dado que Active Directory no es una opción para algunos usuarios, puede crear un archivo de texto firmado con una lista de nombres de inicio de sesión de Windows que tengan acceso de superusuario. Esto supone que las personas no comparten computadoras o inicios de sesión.

Los nombres de usuario simplemente irían en un archivo de texto fácilmente distribuido que se colocaría en la carpeta de la aplicación. La parte importante es firmar la lista de nombres de usuario. Mantenlo muy simple. Un nombre de usuario por fila y coloca el hash en la última línea. Incruste algún tipo de clave secreta en su programa binario y diviértalo con los nombres de usuario. La clave secreta evitará que las personas modifiquen el archivo y luego calculen el hash (lo que probablemente sea descabellado para empezar).

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

Esto, por supuesto, requiere que alguien en algún lugar actúe como administrador de la lista de usuarios autorizados. El administrador debe tener un programa (escrito por usted) que genera el archivo y el hash. Por lo menos, solo podría tomar un archivo de texto de nombres de usuario y agregar el hash.

En aras de ser exhaustivo, alguien a quien se le haya revocado el acceso podría tomar la copia del archivo que todavía tiene su nombre de usuario. Cada vez que querían acceder, simplemente podían poner su copia en su lugar. Sin embargo, probablemente no es algo de qué preocuparse.

Como Active Directory no es una opción, cambiaría la fecha actual. Use elementos con la mayor entropía primero (día del mes) y aquellos con menos entropía el último (año). Si es necesario, agregue una sal específica de dominio (un ID de cliente, nombre de la empresa, etc., ya que se usa fuera de su empresa). Esto debería producir una contraseña muy diferente cada día que es prácticamente imposible de adivinar para los usuarios finales, y puede ser diferente para diferentes compañías que usan el software.

Esto es esencialmente un problema de huevo y gallina, ya que el software debe ser capaz de autenticar al usuario sin llamar a casa. Así que haga un huevo con un mecanismo de craqueo realmente oscuro: si bien la seguridad a través de la oscuridad no es seguridad real, esto es lo mejor que le ha dado los parámetros de su problema.

Esto también es mejor que colocar un archivo de texto en algún lugar: eso no es mejor que una contraseña estática porque una vez que se revela el secreto, el juego termina.

Utilice las listas de control de acceso .

La manera rápida y sucia de hacer esto es eliminar todos los permisos del directorio de la aplicación (incluido el permiso de lectura), luego agregar estos permisos para cualquier usuario que tenga permiso para ejecutar la aplicación. Por supuesto, un usuario con permiso podría copiar fácilmente el directorio de la aplicación a una ubicación pública, pero es poco probable que esto suceda accidentalmente, mientras que el uso compartido de contraseñas puede suceder fácilmente.

Esto supone, por supuesto, que las computadoras involucradas están protegidas (con suerte con el directorio activo).

Mi preferencia es como sugirió @Dan: use el directorio activo. Si esto no es posible, un generador de contraseñas basado en el tiempo puede ser útil. En una situación similar, (en un pasado muy lejano), mi compañía para la que trabajaba usaba 9999-MMDD. Esto salió después de un par de años. Si tiraste hhmm y lo mezcló un poco, podrías obtener uno o dos años antes de que alguien deje que el gato saque la bolsa.

Siempre puede escribir un programa que genere una contraseña utilizando una estrategia similar pero más compleja. Agregue también el nombre usado al nombre de la máquina. Su administrador puede ejecutar ese programa para obtener la contraseña actual solo para esa máquina. Almacene cierta información en el archivo para que no sea válido si se copia a otra máquina o si un usuario diferente ha iniciado sesión. Depende de usted, el administrador, mantener el programa seguro y si el gato sale, es su culpa.

Este esquema se considera débil y poco confiable desde una perspectiva de cifrado, pero es adecuado para el problema que tiene.