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:
- Archivia un hash salato unidirezionale anziché la password.
- 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