Per tutte le seccature che comporta, perché la gestione delle password non è gestita dal database?

Question

Per tutte le seccature che comporta, perché la gestione delle password non è gestita dal database?

#1 da (6 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (1 voti)

1

Al momento, potremmo fare qualcosa come password varchar(72), quando definiamo una colonna password, con ad esempio BCrypt. Ma c'è un sacco di gente che non lo fa in modo molto efficace. Forse hanno appena messo il testo in chiaro, o un singolo hash MD5 non salato, o qualche altra terribile strategia.

Ma praticamente tutti questi criminali usano ancora i database. Quindi, perché questo tipo di funzionalità non è integrato nei database? Qualcosa come mypass password('BCrypt:10'), e accesso come INSERT INTO people(name, mypass, other_data) VALUES(?, ?, ?) che prenderebbe la password in chiaro dall'utente e la passerebbe alla tabella. Ma la tabella memorizzerebbe il valore di hash BCrypt appropriato. Quindi, potremmo fare qualcosa come SELECT other_data FROM people WHERE name = ? AND mypass = ? - questo di nuovo richiederebbe il testo in chiaro da parte dell'utente che accede, ma caricare il sale ed eseguire l'analisi per determinare se la password è stata un successo o meno.

Quando si tratta di archiviare i dati, utilizziamo i database anziché i file flat o ciò che hai perché sono affidabili, testati e semplici (rispetto al rolling nostro). Poiché è chiaro che in natura esistono innumerevoli casi in cui l'archiviazione delle password è inaffidabile e non testata, perché questo tipo di memorizzazione dei dati non è intrapreso dal database stesso?

password-management databases

posta corsiKa 26.06.2014 - 22:46

fonte

4 risposte

Leggi altre domande sui tag password-management databases

dirottatore sconosciuto / popup sul browser Con RSA, ci si può assicurare che due entità non abbiano la stessa chiave privata?

score 6 · Answer 1

Sarebbe possibile ma:

Non è SQL standard (dovrebbe diventare una funzionalità, parte del prodotto)
Tutta la potenza di elaborazione sarà centralizzata sul database
Non tutte le applicazioni web utilizzano database SQL

Stai solo spostando il problema, 10 anni fa sarebbe stato accettabile usare MD5 + salt. Quindi il tuo database implementerebbe MD5 + sale giusto? Va bene 10 anni dopo, tu come sviluppatore hai bisogno di usare la password di nuovo hashing a livello di database, ora il database supporta bcrypt, ma continuerai ad usare MD5 + salt perché è quello che sai bene?

Perché deve ancora supportare il sale MD5 + che potresti chiedere? Semplicemente perché probabilmente stai ancora utilizzando la stessa applicazione. La migrazione al nuovo schema richiederà comunque l'intevervention dello sviluppatore, non avverrà automaticamente.

L'utilizzo di un algoritmo di hashing automatico delle password non è possibile perché è stato implementato uno schema precedente per le applicazioni meno recenti. Ciò richiederebbe quindi al prodotto del database di implementare all'improvviso una funzione di migrazione automatica. Questo è complesso da implementare.

Quindi puoi vedere che il problema si sposta dal fatto che si tratta di un problema di sviluppatore a un problema di sviluppatore del database.

score 2 · Answer 2

Ci sono diversi motivi:

Dovresti modificare il pianificatore di query per capire i tipi di colonna, in quanto dovresti selezionare il nome utente, leggere il salt e quindi gestire l'hash della password.
Stai aggiungendo un carico aggiuntivo al database, che è spesso il punto caldo nelle applicazioni, per un lavoro che può essere fatto altrettanto facilmente nell'applicazione.
Avresti bisogno di un modo per aggiornare i tipi di hash - così è una modifica dello schema del database?

Se qualcuno non sa come scrivere un'applicazione, dare una colonna "magica" al database non risolverà il problema.

score 1 · Answer 3

Bella domanda! Onestamente, la mia opinione è "perché nessuno l'ha fatto". Probabilmente non c'è molto di un mercato per gli sviluppatori di database poiché gli sviluppatori di siti web che non sono stupidi hanno già il loro codice.

Detto questo, è una buona idea collocare il codice di sicurezza (sanificazione, memorizzazione segreta, declassificazione ...) in librerie già pronte piuttosto che sul lato client perché significa che ora c'è one posto dove deve essere fatto correttamente invece di decine di migliaia ; naturalmente, poiché la tua libreria di database è trasparente su come le password vengono salate e sottoposte a hash e offre agli sviluppatori ragionevoli predefinite e opzioni di personalizzazione.

Modifica dopo aver visto le risposte degli altri: farlo nello stesso server DB potrebbe causare più problemi di prestazioni rispetto al lato front-end perché i DB sono meno scalabili rispetto ai front-end; significa anche che mantieni la "patata bollente" più a lungo poiché la tua password in chiaro si sposta dal tuo server front-end al tuo database.

Tuttavia, non vedo ancora come una libreria client a un database non possa ricevere una password come tipo di dati e convertirla in qualcosa di hash e di salato stesso. Avrebbe comunque bisogno di una qualche forma di cache delle password in chiaro per gestire automaticamente gli aggiornamenti delle funzioni di hash (ma sarebbe stato comunque il caso nello stesso processo front-end che avrebbe eseguito il codice della libreria).

score 1 · Answer 4

Le persone fanno tutti i tipi di cose stupide. Ciò non significa che dovremmo prendere tutto ciò che potrebbe andare storto nell'applicazione e delegarlo al sistema di database.

Il lavoro di un sistema di database è la gestione dei dati. Naturalmente i sistemi moderni hanno tutti i tipi di funzionalità aggiuntive che sfocano la linea tra applicazione e database. Ma aspettarsi che gestiscano l'autenticazione dell'utente del tuo sito web sembra un po 'esagerato. Questo è il lavoro dell'applicazione.

Anche il passaggio della password in chiaro al sistema di database ha implicazioni per la sicurezza: ora è necessario assicurarsi che la password non venga visualizzata nel registro delle query o che venga intercettata dal server web al sistema di database (a meno che sono sulla stessa macchina).