Il modo migliore per gestire l'autenticazione e le password degli account utente

Question

Qual è il modo migliore per gestire la gestione degli account utente in un sistema, senza che i dipendenti che hanno accesso a un database abbiano accesso agli account.

Esempi:

1. Memorizzazione di nome utente/password nel database.Questa è una cattiva idea perché chiunque abbia accesso a un database può vedere il nome utente e la password.E quindi usarlo.

2. Memorizzazione dell'hash nome utente/password.Questo è un metodo migliore, ma è possibile accedere all'account sostituendo l'hash della password nel database con l'hash di un altro account di cui conosci le informazioni di autenticazione.Quindi, dopo aver concesso l'accesso, ripristinarlo nel database.

Come lo gestisce Windows/*nix?

Answer 1

Questo era un problema comune in UNIX molti anni fa ed è stato risolto separando i componenti dell'identità dell'utente (nome utente, UID, shell, nome completo, ecc.) dai componenti di autenticazione (hash della password, hash salt della password).I componenti dell'identità possono essere leggibili a livello globale (e in effetti devono esserlo, se gli UID devono essere mappati sui nomi utente), ma i componenti dell'autenticazione dovere essere mantenuti inaccessibili agli utenti.Per autenticare un utente, disporre di un sistema affidabile che accetti nome utente e password e restituisca un semplice risultato "autenticato" o "non autenticato".Questo sistema dovrebbe essere l'unica applicazione con accesso al database di autenticazione e dovrebbe attendere un periodo di tempo casuale (forse tra 0,1 e 3 secondi) prima di rispondere per evitare attacchi temporali.

Answer 2

Questo è un metodo migliore, ma è possibile accedere all'account sostituendo l'hash della password nel database con l'hash di un altro account di cui conosci le informazioni di autenticazione.

Non c'è davvero alcun modo per aggirare questo problema.Chiunque abbia accesso in scrittura al file delle password ha il controllo completo del computer.

Answer 3

Io ne sceglierei 2 ma userei un po' di sale.Alcuni pseudocodici:

SetPassword(user, password)
    salt = RandomString()
    hash = Hashfunction(salt+password)
    StoreInDatabase(user, salt, hash)

CheckPassword(user, password)
    (salt, hash) = GetFromDatabase(user)
    if Hashfunction(salt+password) == hash
        return "Success"
    else
        return "Login Failed"

È importante utilizzare una funzione hash ben nota (come MD5 o SHA-1), implementata in una libreria. Non crearne uno tuo o provare a implementarlo da un libro semplicemente non vale la pena rischiare di sbagliare.

@Brian R.Bondy:Il motivo per cui usi salt è per rendere più difficili gli attacchi al dizionario, l'attaccante non può eseguire l'hashing di un dizionario e provare contro tutte le password, deve invece prendere salt + il dizionario e eseguirne l'hashing, il che fa esplodere i requisiti di archiviazione.Se hai un dizionario delle 1000 password con più virgole e le esegui l'hashing, avrai bisogno di qualcosa come 16 kB ma se aggiungi due lettere casuali ottieni 62*62*16 kB ≈ 62 Mb.

Altrimenti potresti usare qualche tipo di Password monouso Ho sentito parlare bene di OTPW ma non l'ho usato.

Answer 4

Jeff Atwood ha alcuni buoni post sull'hashing, se decidi di seguire questa strada:

• Cracking dell'hashish arcobaleno
• Probabilmente stai memorizzando le password in modo errato

Answer 5

È possibile utilizzare openID e non salvare alcuna password utente riservata.Chi ha detto che è solo per i siti web?

Answer 6

1. Davvero una pessima idea.Se il database viene compromesso, tutti gli account vengono compromessi.
2. Buon modo di andare.Se il tuo algoritmo hash include il nome utente, sostituire l'hash della password con un altro non funzionerà.

Unix memorizza gli hash in un file di testo /etc/shadow, accessibile solo agli utenti privilegiati.Le password vengono crittografate con un salt.

Answer 7

Potresti conservare il sale per la password con hash in un'altra tabella, ovviamente ogni utente avrebbe il proprio sale.Potresti quindi limitare l'accesso a quella tabella.

Answer 8

L'approccio usuale consiste nell'utilizzare l'opzione due con la posta elettronica:

Memorizza il nome utente, l'hash della password e l'indirizzo e-mail nel database.

Gli utenti possono inserire la propria password o reimpostarla, in quest'ultimo caso viene generata una password casuale, viene creato un nuovo hash per l'utente e la password gli viene inviata via e-mail.

Modificare:Se il database è compromesso, puoi solo garantire che non sia possibile accedere a informazioni sensibili e non puoi più garantire la sicurezza della tua applicazione.

Answer 9

Hashing il nome utente e la password insieme.In questo modo, se due utenti hanno la stessa password, gli hash saranno comunque diversi.

Answer 10

Questo non è un problema per molte applicazioni perché ottenere l'accesso al database è probabilmente l'obiettivo più comune di qualsiasi utente malintenzionato.Quindi, se hanno già accesso al database, perché dovrebbero comunque voler accedere all'applicazione?:)

Answer 11

Se il "sistema" è un sito Web pubblico RPX può fornirti servizi di login/account utente per i provider più comuni, come OpenId, Facebook, Google, ecc.

Ora, dato il modo in cui formuli la tua domanda, immagino che il "sistema" di cui stai parlando sia più probabilmente un'app aziendale interna basata su Windows/Linux.Tuttavia;per coloro che cercano su Google fornitori di account di accesso/utente (come ho fatto prima di imbattermi in RPX), questo potrebbe essere una buona soluzione :)