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

Question

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

Esempi:

1. Memorizzazione username/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 nome utente/password hash. 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 si conoscono le informazioni di autorizzazione. Quindi, dopo l'accesso è concesso ripristinarlo nel database.

Come gestisce Windows/* nix?

Answer 1

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

Answer 2

È possibile memorizzare il sale per la password con hash in un'altra tabella, ovviamente ogni utente avrà il proprio sale. Potresti quindi limitare l'accesso a quella tabella.

Answer 3

1. Davvero una pessima idea. Se il database è compromesso, tutti gli account sono 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 con privilegi. Le password sono criptate con un sale.

Answer 4

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 si conoscono le informazioni di autorizzazione.

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

Answer 5

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

Answer 6

Vorrei andare con 2 ma usare un po 'di sale. Alcuni pseudocodice:

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" 

E 'importante utilizzare una funzione di hash ben noto (come MD5 o SHA-1), implementato in una biblioteca. Non eseguire il rollover o provare a implementarlo da un libro non vale il rischio di sbagliare.

@Brian R. Bondy: Il motivo per cui usi salt è rendere più difficili i dizionari, l'utente malintenzionato non ha un dizionario hash e prova contro tutte le password, invece deve prendere il sale + il dizionario e cancellarlo , che espone i requisiti di archiviazione. Se hai un dizionario delle 1000 password più virgola e li hai cancellati hai bisogno di qualcosa come 16 kB ma se aggiungi due lettere casuali ottieni 62 * 62 * 16 kB ≈ 62 Mb.

Altrimenti si potrebbe usare una specie di One-time passwords Ho sentito parlare bene di OTPW ma non l'ho usato.

Answer 7

L'approccio comune è quello di utilizzare l'opzione due con la posta elettronica:

Conservare nome utente, password hash e indirizzo di posta elettronica 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 viene inviata a lui tramite e-mail.

Modifica: se il database è compromesso, si può solo garantire che non sia possibile accedere a informazioni sensibili, non è più possibile garantire la sicurezza della propria applicazione.

Answer 8

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

Answer 9

Jeff Atwood ha alcuni buoni posti in materia di hashing, se si decide di seguire questa strada:

• Rainbow Hash Cracking
• You're Probably Storing Passwords Incorrectly

Answer 10

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

Answer 11

Se il 'sistema' è un sito web pubblico RPX in grado di fornire un servizio di account di accesso/utente per i provider più comuni, come OpenID, Facebook, Google, ecc

Ora, dato il modo in tu formuli la tua domanda Immagino che il "sistema" di cui parli sia più probabile un'applicazione interna basata su Windows/Linux. Tuttavia; per coloro che cercano google per i provider di account di accesso/utente (come ho fatto prima di un RPX), questo potrebbe essere una buona soluzione :)