Autorizzazione nell'applicazione offline

1

Sto lavorando su una macchina che deve memorizzare nomi utente e password per i vari operatori, tecnici e ingegneri che potrebbero utilizzarla e configurarla. È importante che alcune funzioni siano accessibili solo dagli ingegneri, alcune accessibili da tecnici e ingegneri e alcune siano accessibili a tutti. Ci deve essere anche un modo per aggiungere, rimuovere e cambiare account. Infine, i dati devono essere memorizzati sullo stesso computer fisico dell'applicazione.

È stato suggerito di archiviare semplicemente il nome utente, la password e il livello di privilegio in un file INI sul disco. Questo, ovviamente, è cattivo. Mi piacerebbe utilizzare un sistema più sicuro, con gli obiettivi di un utente con privilegi ridotti:

  1. Impossibile trovare una copia di testo normale della password di nessuno
  2. Impossibile eseguire azioni al di fuori del loro ambito di privilegio

Credo di aver raggiunto l'obiettivo numero 1 salendo e cancellando la password, salvando il sale e l'hash sul disco e autenticandomi contro questi valori. Utilizzo il framework .NET e il System.Security.Cryptography.Rfc2898DeriveBytes Schema di hashing PBKDF2 per questo scopo.

Tuttavia, 2 è più difficile, perché memorizzando gli account utente sul disco, è possibile il seguente attacco:

  1. L'attaccante esegue un backup dello stato corrente dell'applicazione
  2. L'attaccante reimposta la macchina allo stato pulito / iniziale eliminando i file di backup
  3. La macchina deve ora fornire un meccanismo per aggiungere account utente, che offre una password di amministratore che viene visualizzata solo alla prima esecuzione
  4. L'attaccante si offre i privilegi desiderati ed esegue l'azione precedentemente limitata
  5. L'utente ripristina lo stato precedente della macchina

Non riesco a vedere un modo per aggirare questo attacco. C'è qualcosa che posso fare? In che modo i sistemi di autenticazione completamente offline, come gli account utente di Windows o Linux, sono protetti da questo tipo di attacco?

Mi rendo conto che un utente malintenzionato con questo tipo di accesso potrebbe modificare o ispezionare l'applicazione stessa e potrebbe aggiungere un keylogger fisico o software, ma non è davvero una cosa su cui posso proteggermi, quindi voglio concentrarmi sul meccanismo di autenticazione il più sicuro possibile.

    
posta kvermeer 08.10.2013 - 19:51
fonte

2 risposte

1

Fondamentalmente, non lascia che l'attaccante modifichi lo stato dell'applicazione.

Ora, non sono sicuro di come i permessi dei file vengano applicati su Windows, quindi prendi questa risposta come consiglio di alto livello. Dovrai capire da solo le specifiche.

Fondamentalmente, i sistemi operativi come Linux prevengono questo genere di cose, richiedendo un account privilegiato per modificare, rimuovere e talvolta persino leggere un file importante. Il moderno Linux lo applica in vari modi, incluse le autorizzazioni POSIX, gli elenchi di controllo degli accessi e SELinux.

Applicando questo alla tua situazione (in Linux-speak), richiederei che l'applicazione venga eseguita come un account utente specifico del sistema operativo e possieda i file che forniscono lo stato dell'applicazione e altre informazioni pertinenti. Ciò elimina la capacità degli utenti normali che utilizzano il sistema di modificare lo stato dell'applicazione.

    
risposta data 09.10.2013 - 02:56
fonte
0

Non so se il tuo passo 3 ("La macchina deve ora fornire ...") provenga da un requisito specifico o meno. Da parte mia, ritengo sia giusto che, se si rimuovono i file di dati principali di un'applicazione, l'applicazione non viene più avviata.

In tal caso, è possibile utilizzare un database crittografato per memorizzare lo stato e le credenziali dell'applicazione. Sul supporto di installazione del software, il database esiste già con la password di amministrazione predefinita da sostituire (l'applicazione può persino applicare questa modifica al primo accesso). E se il file di database è mancante, l'avvio dell'applicazione non riesce su un errore "File dati mancante".

In questo modo, il database degli utenti dell'applicazione non viene mai lasciato non protetto e un utente malintenzionato non può facilmente recuperare il privilegio di amministrazione post-installazione.

    
risposta data 08.11.2013 - 09:27
fonte

Leggi altre domande sui tag