L'autenticazione di base HTTP non è molto usata nelle connessioni browser-server perché implica, dal lato del browser, un popup di accesso controllato dal browser che è invariabilmente brutto. Questo ovviamente non si applica alle connessioni server-server, dove non c'è utente umano che osservi bruttezze, ma contribuisce ad un clima generale di sfiducia e disuso per l'autenticazione di base.
Inoltre, negli anni '90, prima dei giorni di SSL, l'invio di password in chiaro sul filo era considerato un reato e, nella loro follia, la gente considerava i protocolli di risposta alle sfide come HTTP Digest sono stati sufficienti per garantire la sicurezza. Ora sappiamo che non è così; indipendentemente dal metodo di autenticazione, il traffico completo deve essere almeno crittograficamente collegato all'autenticazione per evitare l'hijack da parte di aggressori attivi. Quindi SSL è richiesto . Ma quando SSL è in vigore, l'invio della password "così com'è" nel tunnel SSL va bene. Quindi, per riassumere, l'autenticazione di base in SSL è abbastanza strong per scopi seri, inclusi codici di lancio nucleari e persino questioni relative ai soldi.
Si dovrebbe ancora sottolineare che la sicurezza si basa sull'impossibilità di attacchi Man-in-the-Middle che, nel caso di SSL (come è comunemente usato) si basa sul certificato del server. Il client SSL (un altro server nel tuo caso) DEVE convalidare il certificato del server SSL con grande cura, incluso il controllo dello stato di revoca scaricando il CRL appropriato. Altrimenti, se il client viene reindirizzato su un server falso, il proprietario falso del server imparerà la password ... In questo senso, l'utilizzo di qualcosa come HTTP Digest aggiunge un ulteriore livello di attenuazione nel caso in cui la situazione sia già abbastanza marcata, perché anche con HTTP Digest, un server falso che fa un MitM può comunque dirottare la connessione in qualsiasi momento.
Se andiamo un po 'oltre, possiamo notare che quando si utilizza l'autenticazione basata su password, in realtà vogliamo un'autenticazione reciproca basata su password. Idealmente, il client SSL e il server SSL dovrebbero autenticarsi a vicenda in base alla loro conoscenza della password condivisa. I certificati ci sono una complicazione non necessaria; in teoria, client e server SSL dovrebbero usare TLS-PSK o TLS-SRP in quella situazione, ed evita del tutto il business dei certificati X.509.
In particolare, in SRP, ciò che il server memorizza non è la password stessa ma un suo derivato (un hash con qualche struttura matematica extra). Si noti un punto importante: nel caso di un'API Web, sia il client che il server sono macchine senza alcun coinvolgimento umano. Pertanto, la "password" non deve essere sufficientemente debole per essere ricordata dai sacchetti di carne. Quella password potrebbe essere, per esempio, una sequenza di 25 caratteri casuali, con un'entropia attraversata dal tetto. Questo rende inutili i soliti metodi di hashing della password (hashing lento, sali). Vogliamo ancora evitare di memorizzare nel database del server (quindi come preda di potenziali iniezioni SQL) le password "così come sono", ma, in questo caso , un semplice hash sarebbe abbastanza.
Ciò indica quanto segue: idealmente, affinché un'API RESTful sia utilizzata da un server per parlare con un altro, con l'autenticazione basata su un segreto condiviso (grasso), la comunicazione deve utilizzare TLS con SRP. Nessun certificato, solo hash memorizzati sul server. Nessuna necessità di autenticazione di base HTTP o di qualsiasi altra autenticazione basata su HTTP, poiché tutto il lavoro sarebbe già avvenuto a livello di SSL / TLS.
Sfortunatamente, lo stato attuale di implementazione di implementazioni SSL / TLS abilitate per SRP di solito significa che non è ancora possibile utilizzare SRP. Invece, dovrai usare un SSL / TLS più banale con un certificato X.509 sul lato server, che il cliente convalida diligentemente. Finché la convalida viene eseguita correttamente, non vi è alcun problema nell'invio della password "così com'è", ad es. come parte dell'autenticazione di base HTTP.