it-swarm.dev

Cattiva pratica avere una password "divina"?

È una cattiva pratica della sicurezza avere una password che ti permetterà di accedere a qualsiasi account utente su un sito Web a fini di supporto? La password verrebbe archiviata in modo sicuro e sarebbe super complessa. Tremendo sbaglio?

66
Abe Miessler

Questo suona molto come un account "Amministratore", che in genere altrimenti ha accesso illimitato alle cose di cui è amministratore.

Le implicazioni di sicurezza di un account amministratore sono abbastanza ben comprese, così come le migliori pratiche. Non entrerò in tutti i dettagli, ma l'implementazione si interrompe con le migliori pratiche su una caratteristica chiave: la tracciabilità.

Vuoi essere in grado di dire chi ha fatto cosa, soprattutto quando si tratta di amministratori. Se un amministratore può accedere al mio account usando la sua password, allora non c'è modo per un revisore dei conti di determinare cosa è stato fatto da me rispetto a ciò che è stato fatto dall'amministratore.

Ma se invece l'amministratore accede al proprio account PROPRIO con la sua password super sicura, allora attraverso l'accesso che ha attraverso il proprio account esegue alcune azioni che avrei potuto fare anch'io - beh, allora ora possiamo avere un registro che dice chi ha fatto che cosa. Questa è una chiave importante quando il letame colpisce il ventilatore. E ancora di più quando uno degli account amministratore viene compromesso (cosa che , nonostante i tuoi migliori sforzi).

Inoltre, supponi che l'azienda cresca e che tu abbia bisogno di 2 amministratori. Condividono la password super fantastica? NO NO NO. Entrambi ottengono i propri account di amministrazione, con traccia e registrazione separate e tutto il resto. Ora puoi sapere quale amministratore ha fatto cosa. E, soprattutto, puoi chiudere uno dei conti quando licenzi uno degli amministratori per aver rubato le ciambelle.

117
tylerl

Ci sono molte grandi informazioni nelle risposte fornite finora che il poster originale dovrebbe leggere e prendere a cuore. Tuttavia, penso che la maggior parte delle risposte non catturi lo spirito della domanda in quanto riguarda l'attraversamento del sito Web della propria azienda "come se fossero l'utente" a fini di supporto. Il cuore della domanda sembra essere che questa attività si verifica sul front-end di un sito Web anziché sulla console di un server.

Conosco un'azienda che ha questa stessa necessità nella sua applicazione web e l'ha già risolta in un modo che credo sia il tipo di soluzione che stava cercando il poster originale.

Hanno creato un sistema "mascherato" nella loro webapp che consente a un dipendente di un gruppo speciale di inserire una serie di pagine che possono cercare qualsiasi utente nel sistema e selezionarlo come credenziali con cui navigare nel sistema. Tiene traccia dell'utente selezionato per mascherare come e l'utente dipendente effettivo come due entità separate e simultanee che sono entrambe registrate in ogni momento e per ogni azione.

Dal punto di vista dell'applicazione è un "trattami come questo utente, ma ricorda che in realtà sono l'altro utente". Sorta di una versione webapp di Sudo, ma integrata nel front-end.

Questo metodo:

  1. Elimina l'incubo della pista di controllo, poiché entrambi gli account utente vengono sempre monitorati.
  2. Fornisce ai dipendenti una "visualizzazione utente" esatta delle pagine.
  3. Mantiene le credenziali individuali per i dipendenti in modo che non vi siano password condivise o "master".
  4. Mantiene la sicurezza per gli utenti, le cui password non sono mai disponibili per i dipendenti.
  5. Mantiene la soluzione a livello di applicazione, sul sito Web, in modo che chiunque possa farlo senza accesso o conoscenza a livello di sistema.
  6. Il dipendente può anche "smascherare" in qualsiasi momento e controllare il contenuto della pagina rispetto al proprio account o ad altri account utente, il che è molto utile per determinare se i bug sono globali o specifici dell'utente.
51
Daniel Nalbach

Sì, è un errore. Cosa succede se un utente malintenzionato riesce a ottenere questa password, non importa quanto pensi che sia sicura? Sarà in grado di manomettere le informazioni sull'account utente in un modo che è molto difficile distinguere dalle normali attività.

Se controlli il sito Web, hai già molti metodi diversi disponibili per l'opzione di supporto. È possibile scrivere strumenti amministrativi adeguati per leggere e modificare le informazioni necessarie. Non ha molto senso avere una password "master".

11
user10211

Questa password "god" è l'equivalente dell'accesso root/amministratore: può fare tutto. La domanda è duplice:

  1. È una buona idea avere una sorta di accesso del tipo "può fare tutto"? In pratica, è più "inevitabile" che "buono", ma sì, è una cosa normale. Assicurati, tuttavia, di disporre delle procedure di utilizzo appropriate: non desideri che gli amministratori eseguano l'amministrazione da una macchina condivisa in un bar; e vuoi sapere "chi dunn'it". In tal senso, quando ci sono due o più individui dotati dei privilegi di amministratore, è meglio che agiscano "come se stessi" come membri di un gruppo di amministratori (nel mondo Unix, usa Sudo in modo che i comandi siano registrati).

  2. È una buona idea fare in modo che gli amministratori esercitino i loro privilegi attraverso la normale API utente ? Questo è discutibile. Consentire una "password divina" significa installare la "eccezione divina" in tutta l'applicazione, il che comporta il rischio che venga abusata. Aumenta la complessità del sistema di autenticazione + autorizzazione nel tuo sito e la complessità è l'unica cosa che vuoi evitare in sicurezza. I bug prosperano nella complessità. Una "password divina" può essere conveniente durante lo sviluppo, ma, in generale, tende ad aumentare la probabilità di un buco di sicurezza devastante, quindi usalo con estrema cautela.

Ovviamente contesto è tutto, e le risposte sopra semplicemente si applicano di solito . Tuttavia, diffidare di backdoor amministrative, in particolare backdoor che non tengono una buona traccia dell'origine delle richieste amministrative.

7
Tom Leek

Un amministratore può ancora agire solo come se stesso: qualcuno con una password divina può impersonare chiunque nel sistema. Si potrebbe sostenere che se l'amministratore ha abbastanza potere, questo non fa molto per limitare il danno effettivo che un attaccante con quell'account potrebbe fare. Ma un utente malintenzionato con la password divina avrebbe un tempo molto più semplice per coprire le sue tracce.

4
The Spooniest

Avere una password "divina" è una soluzione semplice, ma è semplicemente una "autorizzazione" per conoscere la password principale e non si presta a una buona gestione degli accessi (cioè a controllare chi può farlo), né alla responsabilità (chi realmente fatto cosa).

Invece, modifica la struttura dei dati delle tue credenziali per avere un campo utente effettivo:

{
  user: alice,
  effective_user: bob,
}

Il contenuto delle tue pagine web dovrebbe essere renderizzato per il effective_user, a meno che non si tratti di una pagina amministrativa interna che deve sapere chi sta navigando davvero. Nota che la maggior parte delle persone esterne che navigano nel tuo sito avranno sempre lo stesso ID per entrambi i campi:

{
  user: alice,
  effective_user: alice,
}

Questa disposizione ti consente di controllare meglio chi è autorizzato a diventare un altro utente e ti consente anche di registrare/controllare chi ha fatto cosa per conto di chi. (Puoi semplicemente registrare sia l'utente che il efficace_utente su cose che ti interessano guardare.) Unix fa questo efficace utente (e gruppo) cose internamente se guardi alle fonti per ciò che definisce un processo. Imitare questo sul Web sta sfruttando un paradigma noto e di successo.

Questa soluzione consente inoltre di scegliere quali pagine il personale può "guardare oltre le spalle" di un altro utente. Puoi scegliere di scrivere una pagina che non viene visualizzata in base a effective_user, nessuna parte di quella pagina può essere vista dal tuo staff anche se hanno il privilegio di cambiare il loro ID utente effettivo.

A proposito, ho implementato il concetto di utente efficace sul web e ho anche implementato la god-password. Quest'ultimo è facile da inserire quando tutta l'infrastruttura è già in atto. Ma in realtà non è la soluzione migliore in termini di sapere chi ha fatto cosa e gestire l'accesso. Dai un'occhiata a quanto è realmente necessario il refactoring per aggiungere il campo utente effettivo: potrebbe essere inferiore a quanto pensi.

4
broc.seib

Non impersonare mai l'utente. (Per vari motivi di tracciabilità/responsabilità come altri già menzionati.)
Al contrario, visualizzi una copia della schermata dello schermo degli utenti come se ti trovassi dietro di loro a guardarli alle spalle.
Ecco a cosa servono gli strumenti di condivisione dello schermo/desktop come VNC, TeamViewer, Assistenza remota, ecc.

3
Tonny

Se solo una persona ha accesso, non è necessariamente un problema, tuttavia può essere fatto altrettanto facilmente avendo un'impostazione per un account utente che consente questo accesso.

Con qualsiasi tipo di funzionalità di root/superutente/admin, la registrazione e il controllo del comportamento sono fondamentali e ciò significa che è necessario sapere chi stava facendo cosa. Se più utenti devono essere in grado di apportare modifiche come questa, allora dovrebbe essere una bandiera sul loro account per consentirlo.

Potresti comunque voler avere una password aggiuntiva, più complicata, che deve essere inserita anche quando hanno accesso, ma dovresti richiedere l'autenticazione sicura di una persona che sta apportando modifiche prima di fare qualcosa del genere.

1
AJ Henderson

Penso che tu debba avere una sicurezza basata sui ruoli piuttosto che un account con abilità in modalità "god". In questo modo puoi avere più persone che hanno gli stessi ruoli con capacità simili in modo che se il tuo dio/amministratore non è disponibile, qualcun altro può fare una correzione.

So che questo è preferito soprattutto se si desidera essere controllati.

0
James

Potresti non avere altra scelta che avere una password "divina". Indipendentemente da ciò che Tylerl ha detto sull'avere due diverse password dell'amministratore, come sarebbe anche possibile avere un registro e tracciare a meno che qualcuno non ne fosse responsabile? Dovresti letteralmente crittografare il registro e tutto contro te stesso in modo tale che sia letto solo al mondo esterno ma possa ancora scrivere da solo. Come determina se le informazioni che sta ricevendo sono legittime o no? Ovviamente se non hai accesso, nessuno lo fa e non funzionerebbe neanche.

0
Timothy Swan