Autenticazione senza un database

Question

Autenticazione senza un database

#1 da (55 voti)
#2 da (18 voti)
#3 da (9 voti)
#4 da (2 voti)
#5 da (-1 voti)

12

Sono stato ispirato da una domanda su Revisione del codice , che si riduce a: Qual è il modo corretto per autenticare un utente senza un database?

Sarebbe lo stesso processo se memorizzate le credenziali in un array, o un file XML, o anche solo un semplice file di testo?

Ad esempio , esaminiamo il seguente codice PHP:

$credentials = array(
    'UserA' => '$2y$10$PassForA',
    'UserB' => '$2y$10$PassForB'
);

$username = $_POST['username'];
$password = $_POST['password'];

if (isset($credentials[$username]) && password_verify($password, $credentials[$username])) {
    // Successfully authenticated
} else {
    // Permission denied
}

Questo è un modo perfettamente accettabile per memorizzare le credenziali? Se dovessimo prendere il nome utente e la password hash da un file esterno (XML / txt), le cose dovrebbero essere trattate in modo diverso?

authentication passwords web-application

posta Alex L 26.06.2014 - 03:11

fonte

5 risposte

18

authenticating without a database

Interpreterò questo significato

Is it possible to design a challenge-response system which lets a principal prove that they are who they say they are without using an amount of storage that scales with the number of principals? I.e. using storage that is O(1) w.r.t. the number of principals.

Un modo per autenticare un preside è di farli presentare qualcosa che solo loro o tu potresti conoscere. Se qualcuno lo sa, e che qualcuno non sei tu, allora sono loro:)

La firma crittografica ti consente di generare stringhe (token) che

puoi darlo a qualcuno
puoi dimenticarlo
possono restituirlo e puoi verificare che sia stato effettivamente dato da te

Se ritieni che il principio di autenticazione non perda i segreti che accedono al loro account, puoi dare loro un output firmato e utilizzare il controllo della firma per autenticarli.

Se non puoi fidarti di loro per non far trapelare segreti, allora non puoi fidarti di loro per non perdere una password che hai cancellato nel tuo database comunque, quindi la possibilità di utenti ingannevoli che perdono un segreto che può essere riprodotto non è un motivo per preferire le password alla firma.

Il semplice controllo delle firme non fornisce una revoca a grana fine, ma questo è un problema di autorizzazione, non rigorosamente un problema di autenticazione.

risposta data 26.06.2014 - 13:34

fonte

9

L'autenticazione in questo modo va bene, ma il vero trucco sta facendo la gestione delle credenziali e gli aggiornamenti. In che modo gli utenti cambiano le loro password? Stai riscrivendo la tua fonte per farlo?

Ho sicuramente visto le credenziali di autenticazione archiviate nei file XML, JSON e CSV. È necessario prendere provvedimenti come l'acquisizione di un blocco durante la modifica del file, la gestione degli arresti anomali e così via, che normalmente vengono gestiti con un database.

risposta data 26.06.2014 - 03:16

fonte

2

Per riferimento, il sistema di password unix per impostazione predefinita si autentica su un file flat che non è un "database" (/ etc / passwd e / etc / shadow). Avere un DB non riguarda la sicurezza ma le prestazioni. Quando devi esaminare milioni di righe per trovare l'utente JohnDoe, le prestazioni ne risentono. D'altra parte, un DB ben indicizzato può trovare lo stesso utente quasi istantaneamente.

Questo vale anche per l'archiviazione delle credenziali utente direttamente in un array - come farete a mantenere i dati e come aggiorneranno i record se sono tutti codificati?

Dato che stai chiedendo sulla pagina di sicurezza, presumo che tu stia chiedendo quali sono le migliori pratiche per l'archiviazione di una password su un file system flat. Bene, la risposta è la stessa come se fosse un DB. Si dovrebbe salare e cancellare le password in modo che se il file viene mai compromesso, nessuno può decodificare le password di tutti.

risposta data 26.06.2014 - 18:28

fonte

-1

L'incapsulamento delle password utilizzando il concetto OOP è migliore quando si implementa su scala ridotta dove il nome utente e la password salata vengono inviati alla funzione membro della classe che detiene l'array di credenziali dell'utente ai fini dell'autenticazione.

risposta data 03.10.2017 - 12:02

fonte

Leggi altre domande sui tag authentication passwords web-application

Bypassare un proxy inverso / NAT Fare in modo che un server Web IIS esegua Apache invece di migliorare la sicurezza?

score 55 · Accepted Answer

Un file XML che contiene le credenziali dell'utente è un database. La definizione di un database non è limitata a MySQL (o qualsiasi altra cosa tu abbia in mente).

Il modo in cui gli utenti sono autenticati e dove sono memorizzate esattamente le loro credenziali sono due preoccupazioni completamente separate. Un hash di bcrypt è un hash di bcrypt, indipendentemente dal fatto che sia memorizzato in un file di testo in chiaro, in una tabella MySQL o in un documento MongoDB.

Naturalmente diversi tipi di sistemi di database funzionano in modo diverso e richiedono diversi modi di aggiornamento e caricamento dei dati, ma questo non ha nulla a che fare con l'autenticazione dell'utente in particolare. Questi sono problemi generali di archiviazione dei dati.