Protocollo di autenticazione SASL senza password Cleartext

3

Come sai, LDAP supporta tre meccanismi di autenticazione : anonimo, semplice e SASL.

Il primo è adatto solo a casi particolari, e quindi non ho intenzione di parlarne. Il secondo invia la password in chiaro e quindi non è adatto se uno non è disposto a implementarlo su qualcosa come SSL (a causa di problemi di compatibilità o motivi legali).

Questo ci lascia con la terza opzione: SASL. Come elencato su IANA , ci sono diversi meccanismi di autenticazione basati su SASL tra cui scegliere. Alcuni di essi sono obsoleti o in uso limitato, ma altri sono comuni.

Desidero selezionare un meccanismo di autenticazione basato su SASL, con le seguenti funzionalità:

  1. È basato su password (diversamente da, ad esempio, SecurID, che AFAIK è basato su token).
  2. La sua sicurezza non è basata su un protocollo sottostante (ad es. SSL).
  3. Il protocollo non richiede che le password degli utenti siano archiviate in chiaro (ad esempio, CRAM-MD5 potrebbe farlo ).
  4. È ampiamente implementato.

Potresti suggerire le mie opzioni?

    
posta M.S. Dousti 11.07.2012 - 22:14
fonte

2 risposte

3

Esistono due meccanismi utilizzati per autenticare una sessione LDAP:

  • semplice
  • SASL

Il semplice meccanismo BIND accetta una delle quattro forme:

  • anonymous - nome null, credenziali null. Questo è lo stato iniziale di una sessione.
  • unauthenticated - nome non nullo, credenziali null. I server di directory devono essere configurati per rifiutare questa richiesta perché non viene eseguita alcuna autenticazione.
  • name/password - nome, credenziali
  • undefined - nome null, credenziali non nulle. Il comportamento del server non è definito dagli standard LDAP. I server di directory devono essere configurati per rifiutare questa richiesta perché non viene eseguita alcuna autenticazione.

Quando un client LDAP si connette al server di directory, quella connessione ha uno stato di autenticazione anonimo. Il client può richiedere che lo stato venga modificato utilizzando la richiesta BIND. Il BIND può anche "resettare" lo stato di autenticazione in anonimo.

Il metodo di autenticazione consigliato è BIND semplice che utilizza una connessione protetta (SSL) o una connessione non protetta promossa a una connessione sicura utilizzando l'operazione estesa StartTLS. I moderni server di directory di qualità professionale supportano forti hash crittografici di password salate per rendere difficile la costruzione di dizionari.

Un altro metodo è il meccanismo SASL GSSAPI , che evita di trasmettere la password del tutto.

Un altro metodo è il meccanismo SASL EXTERNAL , che utilizza le informazioni non fornite da LDAP, ad esempio il certificato client presentato durante la creazione della sessione sicura.

Un altro metodo è il meccanismo SASL DIGEST-MD5 che evita di trasmettere la password ma ha lo svantaggio del requisito che il server deve avere accesso alla password di testo chiaro o essere in grado di decrittografare la password dell'utente, il che significa usare un reversibile schema di archiviazione delle password. DIGEST-MD5 dovrebbe essere evitato per questo motivo. Se è richiesto DIGEST-MD5 , AES potrebbe essere il miglior codice di blocco.

CRAM-MD5 è più debole di DIGEST-MD5 , e dovrebbe essere evitato.

vedi anche

risposta data 12.07.2012 - 13:19
fonte
0

Non hai un'opzione che temo.

SCRAM fa quello che vuoi, ma non è ampiamente implementato, e come hai visto CRAM-MD5 è abbastanza debole.

    
risposta data 14.02.2013 - 04:20
fonte

Leggi altre domande sui tag