Sicurezza e convenzioni. DB o file?

Se le password sono salate e sottoposte a hash, non c'è alcun valore reale in esse per un utente malintenzionato. Vai con tutto ciò che è più semplice da gestire dal punto di vista dello sviluppo e della manutenzione.

Per quanto riguarda la sicurezza della domanda, elimino la risposta di James Baxter.

Per quanto riguarda le prestazioni, se alcuni decimi di microsecondo sono davvero un problema, allora probabilmente ti servirebbe molto, molto meglio, dando una lunga occhiata all'intero processo di autenticazione. L'effettivo back-end è probabilmente una goccia nell'oceano rispetto al routing di autenticazione e tutto ciò che comporta.

Probabilmentepreoccupazioniinutili

Sedavverohaibisognodiquellavelocità,alloraseiprobabilmentein Paese C10K e le tue esigenze specifiche probabilmente saranno troppo specifiche del dominio per me per dare suggerimenti senza una comprensione molto più profonda di quali potrebbero essere i problemi.

In tal caso, tuttavia, ti consiglierei di analizzare attentamente e misurare tutti i colli di bottiglia e i possibili colpi di rendimento. Esistono molte soluzioni al problema del "recupero veloce dei dati per scopi di autenticazione" e la maggior parte viene inevitabilmente con più problemi.

Passare "file" su "database" (o memcached, o Redis, o mongodb vs MySQL, o ...) per spremere un po 'di prestazioni potrebbe tornare a danneggiare le suddette esibizioni in qualche momento lungo la linea.

Nelle piccole configurazioni non ha molta importanza in un modo o nell'altro - ma quando fa importa, non vuoi fare affidamento solo su un parametro di velocità. Ancora una volta, come ha suggerito James Baxter, è necessario considerare anche la manutenibilità, e quindi ci sono espandibilità, scalabilità, affidabilità, problemi di blocco in caso di aggiornamenti e così via.

Are the speed benefits for using a file instead of a database warrant good grounds for using a file or keep it in the database? Does this pose any security risk on a production environment?

Nelle parti del regno dei microsecondi, assolutamente no. Ciò diventa molto più evidente quando si ottengono molte voci che devono essere indicizzate, ottenere valore dalla memorizzazione nella cache, essere modificate dagli utenti, ecc. Per motivi di scalabilità futura, utilizzare un database.

C'è un ulteriore vantaggio in termini di sicurezza nell'utilizzo di un database, che lo imposta correttamente per non rivelare mai l'hash della password. Se il server web invia una query all'utente, calcola l'hash e invia l'hash a un trigger del database che richiede il risultato di una funzione di confronto, quindi è possibile eliminare (tramite permisison di query tabella) la capacità del server Web di leggere l'hash no importa quanto diventa compromesso.

La tua analisi delle prestazioni è difettosa. Tralasciando il fatto che sembra confondere secondi e microsecondi, misurare solo il tempo trascorso per una singola istanza (o istanze consecutive) non è una misura realistica del throughput o della capacità. La capacità ha una certa rilevanza per la disponibilità, quindi forzare l'accesso sequenziale può avere solo un impatto negativo sulla sicurezza riducendo la disponibilità del servizio, anche se sospetto che tu abbia esaurito la larghezza di banda della rete prima che finisca l'elaborazione.

Un'ulteriore preoccupazione è che se si archiviano tutti gli account utente in un singolo file flat, si avranno problemi di scalabilità: le prestazioni probabilmente si ridurranno con il volume.

I DBMS sono solitamente complessi e forniscono accesso alla rete (questo è qualche volta vero anche dei filesystem) quindi è probabile che l'uso di un'istanza dbms dedicata per l'autenticazione possa aumentare la superficie di attacco del sistema. p>

Ma nel complesso, le differenze in Sicurezza sono insignificanti rispetto all'impatto su funzionalità e scalabilità.

Vale la pena sottolineare che non si dovrebbe favorire un meccanismo di hashing delle password basato sulla velocità con cui è possibile, a meno che non si possano garantire password entropiche molto elevate; non vuoi rendere troppo facile forzare la password offline.