Come dovrebbero essere distribuite in modo sicuro più password generate dal sistema e gestite centralmente (se non del tutto)?

3

In un sistema in cui un singolo utente amministratore è responsabile della creazione di più account utente (fino a 500), incluse le password e questi account utente non hanno un indirizzo email associato, come ti avvicineresti alla distribuzione dei dettagli di accesso?

Attualmente l'amministratore deve scegliere una password per ciascun utente. Ciò si traduce in uno o più scenari:

  • l'amministratore che utilizza la stessa password per ciascun utente;
  • l'amministratore non crea account perché il processo è laborioso;
  • l'amministratore scrivendo le password (o altrimenti memorizzandole) per una successiva distribuzione.

Sto considerando una modifica al sistema in base alla quale generiamo un codice / passphrase univoco per ciascun utente in modo che l'amministratore non debba crearne uno. Dovremmo quindi consentire all'utente di scaricare questi dettagli (ad esempio un elenco di nomi utente e passphrase) per la successiva distribuzione. Ovviamente se lo facessimo non potremmo cancellare le password come facciamo ora. Quindi penso che questo sia un classico problema di usabilità vs sicurezza. La nostra proposta cambia pazzo? A cosa non abbiamo pensato? Sono eccessivamente paranoico / non abbastanza paranoico?

Ulteriore background : ogni utente aggiunto deve avere un nome utente univoco all'interno del sistema. Gli indirizzi di posta elettronica non sono specificatamente raccolti perché gli utenti hanno meno di 18 anni (alcuni hanno meno di 6 anni) ed è politica aziendale ridurre al minimo i dati personali associati a ciascun utente. Ciò ha il vantaggio di significare che l'accesso non autorizzato sarebbe molto a basso rischio . C'è molto poco da guadagnare accedendo al sistema a meno che tu non sia l'utente corretto e non è possibile ottenere dati personali oltre al nome dell'utente.

    
posta Willl 28.11.2017 - 15:12
fonte

2 risposte

1

Sfrutta la relazione Trust degli amministratori / insegnanti.

I tuoi insegnanti hanno già una relazione di fiducia con te. Utilizza tale relazione per gestire l'accesso per lo studente.

Se riesci a fornire un'interfaccia Insegnante, è possibile migliorare l'intero sistema e ridurre in modo massiccio l'overhead di amministrazione.

Gestisci i tuoi insegnanti in sicurezza.

  • Indirizzo email.
  • Reimposta la password tramite l'indirizzo email.
  • Sicurezza avanzata.

Fornisci un'interfaccia per i tuoi insegnanti.

  • Crea studenti.
  • Reimposta password.
  • Quando richiesto con lo studente a portata di mano.
    • L'amministratore preme il pulsante Imposta password.
    • Lo studente inserisce la password.
    • Colpire studente Salva.

Studenti:

  • Accede al sistema dal PC Studente.
  • Potrebbe essere in grado di cambiare la password da sé.
  • Chiede ad Admin / Insegnante quando è necessario reimpostare la password.

Suggerimenti alternativi

Opzione 1 Elimina completamente le informazioni identificative personali (PII) e dai a ogni studente un accesso basato sul corso e sullo studente #. (comp101-0001, comp101-0002, comp101-0003)

  • L'insegnante reimposta tutte le password contemporaneamente.
  • Quindi emettere un set standard di carte studente con password iniziali per studenti per iniziare.
  • Le password iniziali possono essere aggiornate ogni classe, l'insegnante può tagliare la pagina delle password iniziali e uno studente riceve un pezzo di carta.
  • La sicurezza non è un problema perché la password iniziale è cambiata dopo il primo utilizzo.
risposta data 29.11.2017 - 00:23
fonte
1

Ci provo:

distribuzione

Il mio suggerimento sarebbe di lasciare il sistema di distribuzione così com'è, soprattutto perché non sembra essere un metodo più sicuro per distribuire in sicurezza le password. Se si desidera veramente distribuire le password utilizzando un server Web, si consiglia di fornire a ciascun utente un collegamento univoco limitato nel tempo. L'utente inserisce il collegamento in un browser ed è connesso ma è necessario inserire una nuova password prima che l'accesso normale possa continuare. Questo simula uno scambio tipico reset password tramite e-mail, ad eccezione del fatto che il collegamento un tempo unico viene stampato su carta anziché inviato tramite e-mail.

Creazione password unica

Il mio suggerimento sarebbe di creare una semplice tabella nel database di scelta che ha due colonne: nome utente e password.

Uso postgresql, ma per quanto ne so, tutti i sistemi di database hanno un qualificatore univoco per un vincolo di colonna. È possibile avere una password di output del generatore di password casuale e confrontarle con quelle correnti nel database ... oppure è possibile emettere un UUID come password. Un UUID è garantito come univoco e, se combinato con l'idea di weblink nella sezione di distribuzione, dovrebbe essere inserito solo una volta. In ogni caso, il generatore di password casuali combinato con un elenco di password correnti è abbastanza facile da implementare e automatizzare. Inoltre, la tabella delle password iniziale può essere facilmente esportata o anche direttamente collegata alla tabella delle password del database dell'app Web.

Modifiche amministrative

Se si implementa una tabella di database con un generatore di password casuale automatizzato, l'amministratore dell'app Web deve semplicemente inserire un nuovo nome utente e il sistema creerà una password. Se si implementa un unico metodo weblink di distribuzione della password iniziale, la distribuzione della carta cambierà solo nel contenuto ... invece di una password, ci sarà un collegamento.

Problemi legali e rapporti con minori

In alcune località ci sono leggi specifiche che dettagliano informazioni / sistemi informatici e minori. Se non sei a conoscenza delle leggi nella tua zona, ti suggerisco caldamente di scoprire se l'esecuzione di un sistema che può includere informazioni personali identificative (PII) di minori ha implicazioni di sicurezza e / o segnalazione / conservazione particolari.

Domande

Tutto questo ha senso? Utile? o semplicemente confuso?

Addendum

Dopo un'ulteriore considerazione, mi rendo conto che ho omesso alcuni problemi di sicurezza specifici e alcuni suggerimenti per l'implementazione.

Archivio password database

È una cattiva pratica di sicurezza archiviare le password in chiaro. Ci sono almeno due scelte decenti quando si memorizzano le password in un database:

  1. Archivia un hash salato unidirezionale anziché la password.
  2. Salva la password in testo semplice in una colonna crittografata utilizzando la chiave pubblica del proprietario dei dati.

In questo particolare caso d'uso, di password generate centralmente e immutabili, suggerirei di archiviare le password in una colonna crittografata in un database separato e in un sistema separato dall'applicazione web. Ovviamente, la colonna della password dell'applicazione Web deve contenere l'hash salato della password, come di consueto considerazione di sicurezza. Inoltre, l'esportazione di una colonna di password in formato salato e hash come un vettore o una tabella csv è facilmente automatizzata con l'unico requisito amministrativo del proprietario dei dati che inserisce la passphrase della chiave privata.

Se l'idea di weblink viene utilizzata, non è necessario tracciare password di testo normale, in quanto l'amministratore non ne genererebbe mai una. Ma poi, l'amministratore non avrebbe una registrazione della password in chiaro. Tuttavia, nella maggior parte dei casi, l'accesso alla password in chiaro non è necessario.

Tasso di crescita dei dati

Per descrizione del tuo caso d'uso, si presume che l'archivio dati crescerà lentamente o non lo farà affatto. Sembra che si abbia una registrazione progressiva nell'applicazione con un numero totale di utenti statici nel tempo più o meno un buffer. Se true, le considerazioni sulla scalabilità oltre il numero corrente di utenti non sono applicabili.

Ulteriori letture

risposta data 28.11.2017 - 21:55
fonte

Leggi altre domande sui tag