Protezione delle credenziali passate al servizio web

Di cosa hai bisogno esattamente? Per essere sicuro che la password non verrà letta da un uomo nel mezzo? Per essere sicuro che l'uomo nel mezzo non sarebbe in grado di accedere?

Se tutto ciò che vuoi è impedire all'uomo nel mezzo di leggere le password, basta cancellare quelle password. È così semplice.

Potresti anche voler evitare che l'uomo nel mezzo ottenga il nome utente. Qui, non si è in grado di trasmettere solo l'hash, ma invece è possibile crittografare la coppia nome utente / password con una chiave pubblica inviata al client, dato che il server avrà la chiave privata per la decrittografia.

Se si desidera impedire all'uomo nel mezzo di accedere, l'attività è leggermente più complicata. Puoi ancora utilizzare le chiavi pubbliche / private, ma:

• la chiave pubblica deve essere comunicata in anticipo al consumatore del servizio web (che ha l'inconveniente di usare la stessa coppia di chiavi ancora e ancora, così come la difficoltà di trasmettere la chiave privata da qualche altro canale in cui l'uomo nel mezzo non riesce a prenderlo),

• o il consumatore del servizio web può inviare una seconda chiave pubblica che servirà per il server a crittografare la propria chiave pubblica nella risposta.

• I certificati SSL (chiave pubblica) sul lato client sono l'unico schema che protegge i client dagli attacchi man-in-the-middle, rendendoli così i più sicuri. Modifica l'ultima volta che ho controllato, Verisign ha registrato $ 100-200 per certificato client Modifica finale . Se i clienti sono umani, puoi installare il certificato nel browser e spostarlo in un altro browser in qualsiasi momento. È un po 'come un cookie più sicuro e universalmente accettato. Se leggi il manuale di OpenSSL, puoi usare OpenSSL per diventa la tua Autorità di certificazione e genera e accetta i tuoi certificati , ma devi stare molto attento a fare tutto correttamente (qualsiasi errore può minare la sicurezza del sistema come si vede ripetutamente nelle notizie). Quando ho controllato l'ultima volta, Chrome ha richiesto all'utente di utilizzare la riga di comando per impostare un certificato client, ma tutti gli altri browser moderni più popolari potrebbero impostare i certificati tramite JavaScript.
• Cookie lato client. I client effettuano ancora il login nel modo in cui lo fanno ora, ma il server invia loro un cookie crittografato (il server esegue tutti hashing e salting e sceglie quali dati hash e salt). La maggior parte delle persone percorre questa strada, probabilmente perché è facile da implementare. Quando viene visualizzata la casella di controllo "Mantieni accesso" nella pagina di accesso di un sito Web, solitamente ciò che sta accadendo.
• OpenID ha la documentazione completa e le implementazioni disponibili. Ti permette di sfruttare un account (che è abilitato OpenID) per accedere in molti posti. Ha il vantaggio che l'utente deve solo "ricordare" una password (odio la parola "ricordare" con le password - le persone dovrebbero usare un gestore di password per memorizzare le password che non possono ricordare). Il grosso svantaggio di questo è che se qualcuno compromette l'account principale, tutti gli account connessi cadrà con esso.
• ActiveDirectory / LDAP Questa è la forma più popolare e tradizionale di single-sign-on per le applicazioni interne all'interno delle aziende. Penso che sia stato creato da Novel in un momento in cui la gestione di una rubrica di nomi e numeri di telefono (la "Directory" in LDAP) era considerata un grosso problema. Questo è stato un momento prima che la sicurezza del computer fosse anche solo una considerazione. L'implementazione di Active Directory di Microsoft è stata distribuita con tutti i principali sistemi operativi per oltre un decennio. Le persone possono essere registrate automaticamente ai siti intranet abilitati per AD / LDAP solo dopo aver effettuato l'accesso al proprio desktop. Richiede che tutti i client si trovino sulla stessa rete locale, o almeno che il server AD / LDAP sia accessibile al server Web controllando le credenziali. Non fornisce alcuna sicurezza, o davvero cattiva sicurezza in sé e per sé. È assolutamente necessario verificare che i pacchetti di autenticazione siano crittografati dal livello di trasporto (ssl su https) e testare il server per essere sicuri che non accetterà MAI alcuna connessione non crittografata. L'idea di inviare le informazioni di accesso desktop della gente liberamente in chiaro sulla rete mi rende davvero scomodo. Quasi fa perdere la parola "exploit" per dire che questa debolezza è stata sfruttata molte volte nel corso degli anni. Se segui questa strada, credo che i client LDAP siano disponibili per Linux, Mac e Windows.

Esamina OAuth che è progettato per questo ruolo di permesso-da-fare-qualcosa. Non chiedi l'identità dell'utente, ma chiedi all'utente di fornirti un token (di cui ti fidi) che puoi utilizzare per determinare le autorizzazioni che sei disposto a fornire a quell'utente.

Tutti i gubbins di crittografia di sicurezza gestiscono il framework in modo da non doversi preoccupare troppo di come crittografare la comunicazione usando un framework di questo tipo.