Riguarda il modo in cui interpreti ciò che stanno scrivendo. Non stanno dicendo che non dovresti hash e dovresti memorizzare le password in testo normale. Quello che sta dicendo è che il valore che scrivi in LDAP non è hash o crittografato. Questo è come la situazione che hai con un normale database. Puoi definire una colonna chiamata password e puoi dire al database di crittografare quella colonna o meno. È quindi possibile attaccare i dati in quella colonna, che può essere crittografata / hash o testo normale. Se si definisce la colonna come crittografata, i dati vengono crittografati mentre vengono scritti nella colonna e decrittografati quando vengono letti da essa. Se si memorizzano gli hash di una password, tale hash verrà crittografato e richiederà la decodifica prima che possa essere utilizzato. In generale, la crittografia del database riguarda la protezione dei dati esportati nei dump di dati, ecc. È un po 'come la crittografia del disco in quanto una volta che si ha accesso alle tabelle del database, la crittografia / decrittografia viene eseguita dietro le quinte e non viene visualizzata. Tuttavia, se qualcuno riesce ad accedere a un dump dei dati o ottiene l'accesso al file di dati della tabella su disco, non sarà in grado di leggere le informazioni.
Notare la definizione degli attributi della password come memorizzati in una sintassi della stringa dell'ottetto. Questo formato è definito per supportare l'intera gamma di caratteri che incontrerai nelle password con hash. Quello che la pratica migliore sta dicendo è che LDAP memorizza il valore che gli dai 'così com'è' senza ulteriore crittografia o hashing. È compito del software che gestisce questi dati per eseguire qualsiasi operazione di hashing desiderata
La 'L' è LDAP sta per leggero. Un server LDAP in genere vede molte letture con molte meno scritture. È progettato per gestire molte richieste e cerca di garantire buone prestazioni mantenendolo semplice. L'aggiunta della crittografia crea un ulteriore sovraccarico non necessario. Se l'attributo della password è stato crittografato, tutte le query dovrebbero decodificare tali informazioni, riducendo le prestazioni.
LDAP mantiene anche le cose semplici non fornendo un'interfaccia di gestione. È essenzialmente un albero definito di attributi e valori il cui ruolo principale è quello di rispondere alle domande. Per rafforzare ulteriormente questo aspetto, spesso lo si trova in ambienti ad alta richiesta, si avrà un server LDAP principale in cui vengono inviate tutte le scritture / aggiornamenti e server slave / replicaiton in cui vengono inviate tutte le query. Quando scrivi al master, se inoltrerà le modifiche agli schiavi.
La gestione dei dati viene solitamente eseguita da qualche altro programma. Ad esempio, sul nostro sito, abbiamo un programma perl che riceve i dati dal nostro sistema IAM. Quindi prende questi dati, applica alcune regole aziendali e scrive i risultati sul master LDAP. Il programma perl esegue gli hash delle password (in pratica dovremo supportare più tipi di hash per ogni password perché non tutte le applicazioni comprendono lo stesso algoritmo di hashing.) Questo hashing aggiunge anche un salt.
Quando un client interroga il server LDAP, otterrà solo ciò che è memorizzato nell'attributo. Con le password, i dati memorizzati includono dettagli su quale tipo di hash è stato utilizzato. Naturalmente, affinché i binding funzionino, il server LDAP deve comprendere almeno uno degli hash utilizzati per eseguire il bind.
Nel nostro caso, l'hash principale che usiamo è SHA-512. I riferimenti a MD5, SHA1, Crypt ecc sono obsoleti e non dovrebbero essere usati. Questo è un altro esempio del vantaggio di questo approccio. Una volta usavamo SHA-1 e persino Crypt. Potremmo aggiornare facilmente un algoritmo di hashi più recente senza doverci preoccupare troppo di LDAP e versioni ecc.