Capisco che i database LDAP siano più sicuri, ma è sempre necessario utilizzare LDAP anziché MySQL per nomi utente e password?
Non sono sicuro di essere d'accordo sul fatto che "i database LDAP sono più sicuri". Dopotutto, un server LDAP è fondamentalmente un server di database, con esattamente gli stessi rischi per la sicurezza. LDAP è bello se si hanno i bisogni (software che può autenticare contro LDAP, eccetera) e strumenti, ma per quanto riguarda la sicurezza non vedo differenze tra l'uso di LDAP e MySQL (dato che non si fanno cose stupide come le password in chiaro o hash non salati).
Principio di separazione dei privilegi
Questo è un caso classico in cui l'isolamento del database del contenuto dal database utente fornisce un vantaggio in termini di sicurezza.
Il Server LDAP non è più sicuro, ma ha uno scopo limitato, e quindi l'area di superficie per l'attacco è molto più bassa, a differenza della tipica tabella utente memorizzata in un database del contenuto che può essere recuperato direttamente nel caso di un exploit di iniezione.
Il server LDAP e il database del contenuto sono nascosti (in alcune architetture) dal server applicazioni in modo che l'accesso diretto non sia richiesto e è possibile solo passare attraverso gli attacchi, riducendo ulteriormente la possibilità di compromessi.
Questi servizi multipli introducono una complessità che presenta costi e problemi, ma costituiscono uno schema che incoraggia / costringe il progettista / sviluppatore a tenere separate queste specifiche responsabilità / responsabilità piuttosto che a far collassare l'implementazione in un sistema non sicuro.
Un altro modo di pensarci è che gli errori vengono sempre fatti quando si progetta / sviluppa / distribuisce un sistema, e senza questa separazione delle responsabilità, gli errori fatti in un dominio possono penetrare e compromettere gli altri domini.
Nota: tramite una rapida lettura del protocollo LDAP , una password è un campo nel database LDAP, quindi se il campo è hash (best practice), il database LDAP non ha bisogno di conoscere la password in chiaro e, come nota del commentatore, ci sono API speciali per evitare problemi con la password l'autenticazione.
È discutibile che LDAP sia più sicuro di MySQL.
Non vedo davvero i vantaggi dell'aggiunta di un altro servizio complesso a un'infrastruttura. Se si desidera isolare l'autenticazione, perché non utilizzare solo un database SSL (Secure), isolato MySQL. Se vuoi un modo standard per accedere a un database di autenticazione, perché non creare uno schema standard MySQL?
LDAP è fantastico quando devi autenticare molti servizi diversi contro un singolo Backend (One Password per tutti o anche SingleSignOn) o quando hai diversi luoghi fisici sparsi in tutto il mondo devi autenticarti contro un singolo backend come LDAP è ottimo per le informazioni di sharding.
Ma quando non è un MustHave e stai solo pensando di usare LDAP come backend di autenticazione, voterei sempre per minimizzare i sistemi, il che significherebbe se hai bisogno di un database per la tua applicazione, quindi usa quel database anche per l'autenticazione.
In alternativa, prenderei in considerazione l'utilizzo di OAuth o OpenID in modo che gli utenti possano accedere utilizzando un servizio diverso e non devi prendere in considerazione le password di Hashing in quanto non memorizzi le password. In questo modo delegheresti l'autenticazione a un servizio esterno.
Il problema delle password crittografate è che la maggior parte delle volte l'utente invia la sua password non crittografata (solo crittografata da una connessione https) al server. Da lì il server può quindi utilizzare la crittografia o non connettersi a LDAP. Tuttavia, quando si utilizza il comando bind predefinito di LDAP, è necessario fornire la password non crittografata a LDAP in modo che non vi sia alcun vantaggio. Al contrario, quando si utilizza un database, è possibile memorizzare la password crittografata nel database e quindi interrogare la password crittografata in modo che tra la propria applicazione e il database la password venga inviata solo crittografata. Ciò tuttavia non codifica la password tra utente e applicazione!
O useranno una tecnologia proprietaria che è quindi irrilevante per il tuo o che utilizzano soluzioni sul mercato. Ciò che è importante forse nella tua domanda è la scalabilità di queste soluzioni. Per "Server LDAP" c'è OpenLDAP che può essere configurato per usare MySQL come memoria di back-end. Se avessi bisogno di scalabilità, cercherò questa combinazione. Il DAP è molto più veloce di SQL. LDAP non è un database relazionale. In realtà, non è affatto un "database" generico, è una directory strutturata ad albero.
Molti dei concetti che hai familiarità con i database relazionali non si applicano realmente a LDAP. Ad esempio, non ci sono "tabelle" e non esiste l'operazione "join".