Quali sono alcune possibili alternative per fornire una "password amministratore" per un'applicazione desktop?

Attualmente sto gestendo e ri-factoring un software che è stato utilizzato nella mia azienda da oltre un decennio. Uno degli elementi di questa applicazione è una sorta di modalità admin o power-user che fornisce elementi quali input aggiuntivi / interni e la possibilità di disattivare i limiti di input.

Storicamente questa modalità è stata attivata inserendo un file con un nome specifico in una posizione specifica nella directory di sistema di Windows (entrambi i quali erano codificati nell'applicazione), il file si chiamava "qualcosa.DLL", anche se era vuoto File ASCII e non una dll.

Di recente ho quindi aggiunto del codice e un piccolo modulo modale che consente all'utente di inserire una password dell'amministratore per attivare questa funzionalità. È una password impostata, non specifica dell'utente. Quando viene immessa la password corretta, fa la stessa cosa creando un "file chiave" nella directory principale dell'applicazione in modo che il programma possa avviarsi in modalità admin se quel file è presente.

Ora al manager del dipartimento per cui questo software è principalmente destinata questa idea non piace così tanto. Pensa che se abbiamo solo una semplice password preimpostata che "uscirà facilmente", e non vuole che gli utenti inesperti accedano a queste funzionalità extra.

Quindi la mia domanda è: quali altri metodi ci sono per fornire questo tipo di accesso che sarebbe un po 'più sicuro? Praticamente sono solo io quando si tratta di mantenere e gestire questo software, quindi tutto ciò che non è quasi completamente integrato o automatizzato non sarebbe di aiuto (come l'invio di richieste di "chiavi di licenza" o qualcosa di simile).

Note: questa applicazione è scritta in VB.NET (.NET 4.0) e al momento sto pianificando di utilizzare la distribuzione click-once al termine della nuova versione.

Se si dispone di Active Directory, è possibile verificare l'appartenenza a un gruppo di 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;
    }

Il gestore ha ragione riguardo alla password che esce . Non è una questione di se, ma di quando.

Poiché Active Directory non è un'opzione per alcuni utenti, è possibile creare un file di testo firmato con un elenco di nomi di accesso di Windows a cui è consentito l'accesso come superutente. Ciò presuppone che le persone non condividano computer o accessi.

I nomi utente andrebbero semplicemente in un file di testo facilmente distribuibile che verrebbe inserito nella cartella dell'applicazione. La parte importante è firmare l'elenco dei nomi utente. Mantenerlo molto semplice. Un nome utente per riga e inserire l'hash nell'ultima riga. Incorporare una sorta di chiave segreta nel file binario del programma e l'hash con i nomi utente. La chiave segreta impedirà alle persone di modificare il file e quindi di calcolare l'hash (che è probabilmente inverosimile per cominciare).

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

Ciò, ovviamente, richiede che qualcuno da qualche parte funga da amministratore dell'elenco di utenti autorizzati. L'amministratore dovrebbe avere un programma (scritto da te!) Che genera il file e l'hash. Se non altro, potrebbe semplicemente prendere un file di testo di nomi utente e aggiungere l'hash.

Nell'interesse di essere accurato, qualcuno a cui è stato revocato l'accesso potrebbe prendere la copia del file che contiene ancora il suo nome di accesso. Ogni volta che volevano accedere, potevano semplicemente mettere in atto la loro copia. Probabilmente non è qualcosa di cui preoccuparsi, però.

Dal momento che Active Directory non è un'opzione, avrei la data corrente. Usa prima gli elementi con la più entropia (giorno del mese) e quelli con l'ultima entropia (anno). Se necessario, aggiungi un salt specifico per il dominio (un ID cliente, il nome dell'azienda, ecc. Poiché viene utilizzato al di fuori della tua azienda). Ciò dovrebbe produrre una password molto diversa ogni giorno che è praticamente impossibile da indovinare per gli utenti finali e può essere diversa per le diverse società che utilizzano il software.

Questo è essenzialmente un problema di pollo e uova poiché il software deve essere in grado di autenticare l'utente senza telefonare a casa. Quindi crea un uovo con un meccanismo di cracking davvero oscuro: mentre la sicurezza attraverso l'oscurità non è vera sicurezza, questo è il migliore che hai dato ai parametri del tuo problema.

Questo è anche meglio che posizionare un file di testo da qualche parte: non è meglio di una password statica perché una volta che il segreto è uscito, il gioco finisce.

Utilizzare gli elenchi di controllo di accesso .

Il modo rapido e sporco per farlo è rimuovere tutte le autorizzazioni dalla directory dell'applicazione (inclusa l'autorizzazione in lettura), quindi aggiungere queste autorizzazioni per tutti gli utenti autorizzati a eseguire l'applicazione. Naturalmente, un utente con autorizzazione potrebbe altrettanto facilmente copiare la directory dell'applicazione in una posizione pubblica, ma è improbabile che ciò accada accidentalmente, mentre la condivisione della password può facilmente avvenire accidentalmente.

Ciò presuppone, ovviamente, che i computer coinvolti siano protetti (si spera con active directory).

La mia preferenza è come suggerito da @Dan - usa active directory. Se ciò non è possibile, può essere utile un generatore di password basato sul tempo. In una situazione simile, (passato molto lontano) in cui lavoravo per la mia azienda 9999-MMDD. Questo è uscito dopo un paio d'anni. Se hai lanciato hhmm e lo hai mescolato un po ', potresti prenderne un anno o due prima che qualcuno faccia uscire il gatto dalla borsa.

Puoi sempre scrivere un programma che genera una password usando una strategia simile, ma più complessa. Inserisci nel nome usato anche un nome di macchina. Il tuo manager può eseguire quel programma per ottenere la password corrente solo per quella macchina. Memorizza alcune informazioni nel file in modo che non siano valide se copiate su un altro computer o se un altro utente ha effettuato l'accesso. Spetta quindi al tuo gestore proteggere il programma e se il gatto esce, è colpa sua.

Questo schema è considerato debole e inaffidabile dal punto di vista cyrpto, ma è adeguato al problema che hai.