Ordine di autenticazione e autorizzazione

1

Questa è la mia prima domanda qui in Information Security SE. C'è una raccomandazione per aiutare a raccontare gli scenari in cui l'autenticazione dovrebbe precedere l'autorizzazione da quelli in cui l'autorizzazione viene prima?

Ho sperimentato entrambe le situazioni in diversi luoghi di lavoro (la situazione era molto simile, passando a un utente di sistema con un certo insieme di privilegi nella riga di comando di Unix). Quando deve venire prima l'autorizzazione per risparmiare l'autenticazione? Quando dovrebbe prima autenticare per non dire a un potenziale intruso che l'utente impersonato non avrebbe diritto all'operazione corrente?

Esistono specifiche linee guida o regole generiche per questo?

-

OK, lascia che ti presenti una situazione specifica. Registrato con ID utente del proprio dipendente, SUing ad un altro utente. Ho digitato in modo errato l'utente del sistema a cui stavo per passare, ma l'altro è anche un utente esistente nel nostro ambiente. Prima di chiedere la password, mi sono rifiutato dicendo che non ero autorizzato a eseguire questa operazione.

Dato che ho appena terminato un corso di ingegneria anti-sociale oggi, mi sono chiesto se fosse una buona idea dirmi che non ero autorizzato (anche questo potrebbe essere un utile pezzo di informazione per qualcuno che cerca di impersonarmi nel rete aziendale).

    
posta András Hummer 14.07.2014 - 17:17
fonte

3 risposte

3

L'autenticazione riguarda l'identificazione di chi sta emettendo il comando e l'accertamento che il chiamante sia realmente quella persona / sistema. L'autorizzazione si verifica necessariamente dopo, dal momento che si tratta di decidere se il richiedente debitamente autenticato dovrebbe essere autorizzato a procedere o meno.

Nel tuo caso con un comando su , ci sono due autenticazione / autorizzazione. Supponiamo che tu sia un utente "bob" e che tu voglia fare un su joe . Va così:

  1. Il comando su autentica il chiamante. Il chiamante è bob. Quell'autenticazione è trasparente; come utente umano, non lo vedi: il comando su chiede al sistema operativo chi è il chiamante.

  2. Ora che il comando su sa che il chiamante è bob, vuole decidere se a bob dovrebbe essere permesso di fare un su in identità joe . Questa è autorizzazione e si verifica dopo l'autenticazione, come dovrebbe. Prendi nota che l'identità che deve essere autorizzata è bob, non joe. A quel punto, non c'è stata autenticazione per joe, e la domanda non riguarda ciò che può fare joe, ma cosa può fare bob.

  3. Se il comando su è felice con bob che chiede di diventare joe, procede quindi. Nel tuo caso non raggiungi questo passaggio: l'autorizzazione precedente ha deciso che bob non può eseguire un su joe . Tuttavia, se lo avesse consentito, avrebbe attivato la seconda procedura di autenticazione, in cui deve essere inserita la password di joe.

  4. Se la seconda autenticazione funziona, ottieni una shell in esecuzione sotto l'UID di joe. Quando si immettono i comandi, l'autorizzazione verrà applicata in base a tale identità autenticata: se, all'interno della shell ottenuta, si desidera leggere un file, verranno utilizzati i diritti di accesso in lettura per joe .

Per pensare con attenzione all'autenticazione e all'autorizzazione, ricorda sempre che autorizzazione è per un'identità specifica. Nel caso di su , la fase di autorizzazione riguarda se Bob può emettere il comando, non joe; quindi, poiché usa "bob" come input, si nutre di una precedente fase di autenticazione per bob con la password di bob, non sull'autenticazione prevista che utilizzerà la password di joe.

    
risposta data 14.07.2014 - 17:57
fonte
5

Come puoi sapere chi autorizzi se non ti sei autenticato? L'autenticazione viene sempre prima, tranne quando tutti sono autorizzati o nessuno è autorizzato.

Modifica: sembra che tu ora abbia due domande:)

1) Ti è stato rifiutato molto probabilmente perché esiste un criterio di controllo degli accessi che impedisce al tuo UID originale di eseguire un'operazione sull'UID dell'utente errato. È il tuo UID che ti ha autenticato (chiamato un'autorità dell'ambiente) perché il sistema che esegue i controlli di autenticazione ritiene che il tuo sistema fornisca un UID accurato. Il tuo UID non è stato autorizzato, pertanto ti è stato negato l'accesso.

Come nota a margine, alcuni protocolli di autenticazione come NIS non sono riusciti a rendere conto del fatto che un utente può scalare i privilegi a livello locale e il loro UID locale non può essere utilizzato come token di autenticazione. Onestamente non ricordo come un server NIS +, LDAP o Kerberos controllerebbe la tua identità prima di verificare se ti è permesso utilizzare una delle loro risorse (come la connessione a un altro account).

2) Alcune persone ritengono che sia una buona idea offuscare se un tentativo di autenticazione ha funzionato servendo una sessione di honeypot per l'utente povero che ha sbagliato l'ID o la password. Queste persone hanno torto. Se il sistema non ti avesse detto che non eri autorizzato, non avresti notato che non hai effettuato l'accesso all'account che ti aspettavi e non avresti potuto spiegare perché i dati che ti aspettavi di trovare non sono qui o perché i dati aggiunti durante quella sessione non sono stati effettivamente salvati nella home directory dell'utente. Queste interruzioni di interazione sono tutt'altro che semplici da recuperare e il vantaggio in termini di sicurezza dell'offuscamento è molto discutibile.

    
risposta data 14.07.2014 - 17:26
fonte
4

Sono d'accordo con entrambe le risposte fornite finora da Thomas Pornin e Steve DL .

L'autorizzazione viene sempre dopo l'autenticazione poiché l'autorizzazione è l'atto di esaminare le affermazioni di un determinato utente e determinare se l'utente può eseguire ciò che sta tentando di fare in base a tali affermazioni e in base alle politiche di autorizzazione in atto.

Vorrei ampliare la definizione e affermare che l'autenticazione non riguarda necessariamente la tua identità direttamente (chi sei), ma piuttosto la dimostrazione dell'autenticità di un reclamo da te presentato. Un buon esempio di questo è quando vado a comprare alcolici. L'impiegato non potrebbe importare di meno chi sono io, ma a loro interessa la mia età (> 21 negli Stati Uniti, > 20 in Svezia, > 18 nella maggior parte dei posti). Quindi, quando mostro la mia patente di guida / carta d'identità / passaporto, sto provando la mia data di nascita. I francobolli, gli ologrammi e altri meccanismi sulla carta provano l'autenticità del reclamo (la mia data di nascita). Ma l'impiegato non è interessato alla mia identità in sé.

    
risposta data 14.07.2014 - 18:39
fonte

Leggi altre domande sui tag