HTTP Digest + MD5 è ancora un'alternativa per consumare la mia API personale?

Question

HTTP Digest + MD5 è ancora un'alternativa per consumare la mia API personale?

Naviga le tue risposte

#1 da (5 voti)
#2 da (0 voti)

4

Sto leggendo molto sull'implementazione dei vincoli di sicurezza su un'API REST.

Ci sono molti metodi, alcuni migliori di altri per le applicazioni di terze parti o per consumare la mia API.

HTTP Basic + TLS (con le chiavi)
HTTP Digest + TLS
OAuth 1.0a, 2.0
Solo autenticazione-applicazione (con le chiavi) link
Amazon Signature Version 4 Link

Per consumare la mia API ho 3 opzioni (da basso a alto grado di difficoltà da implementare, sempre usando TLS!):

HTTP Basic + TLS (con le chiavi)
HTTP Digest + TLS
Solo autorizzazione dell'applicazione (con le chiavi)
Amazon Signature Version 4

L'unico vantaggio di digerire su basic + tls è che la password non viene trasferita in testo normale ma in un hash MD5.

Ma secondo kbcert e wikipedia dicono che MD5 non deve essere usato (attacchi di collisione).

La mia domanda è, se la sicurezza MD5 è compromessa (oggi e nel prossimo futuro) 2. HTTP Digest + TLS non è un'opzione valida per consumare la mia API e ho solo le altre opzioni "più" sicure (1, 3, 4)?

So che HTTP Basic + TLS può avere attacchi di riproduzione.

rest authentication md5

posta Diego Alvarez 11.10.2013 - 17:30

fonte

2 risposte

Leggi altre domande sui tag rest authentication md5

Il modo più semplice per emulare gli attacchi di violazione / anomalia del protocollo TCP-IP È necessario crittografare il digest del messaggio?

score 5 · Answer 1

Gli attacchi di collisione non sono rilevanti per l'uso di una funzione di hash nell'autenticazione "Digest"; quello usa la resistenza preimage per cui MD5 è ancora abbastanza robusto.

Si noti che finché si utilizza SSL / TLS (cioè HTTPS), allora è possibile utilizzare l'autenticazione di base: il livello SSL garantisce che la password non viaggi "in chiaro" e che venga inviata solo al server legittimo . Si noti inoltre che senza SSL / TLS ci sono altri problemi oltre l'autenticazione, ad es. dirottamento ostile della connessione dopo la fase di autenticazione. Per sicurezza ragionevole, hai davvero bisogno di SSL, e una volta che hai SSL, l'autenticazione di base va bene.

In effetti, l'autenticazione del digest introduce problemi aggiuntivi, non a causa di MD5, ma perché obbliga il server ad avere una copia della password; quindi il server deve memorizzare le password "così come sono" e qualsiasi violazione locale di sola lettura sul server diventa critica. Con l'autenticazione di base, il server deve solo memorizzare le password di hash (con un buona funzione di hashing della password ), ed è molto meglio.

Quindi non usare Digest, usa Basic. Ma non è una questione di "debolezza MD5"; Digest con SHA-256 non sarebbe meglio.

Come per OAuth, il suo uso principale è l'autenticazione delegate , che può o non può essere una buona idea nel tuo caso, ma è un'altra questione.

score 0 · Answer 2

È il tuo modello di minaccia da determinare. L'autenticazione di base è un buon candidato se hai un sistema che esegue il controllo della password e l'endpoint esposto.

Nome utente e password nel modulo di base dovrebbero funzionare correttamente su TLS se ritieni che i certificati siano sicuri e il tuo endpoint non sia compromesso. Se è compromesso, l'intruso può sifonare le password in chiaro dalle richieste.

Il metodo di Amazon è il migliore. È possibile delegare il controllo della firma per proteggere i sistemi che conoscono la chiave. Se l'endpoint è compromesso, non si perdono le password perché non vengono mai inviate nella richiesta.

Non so digerire abbastanza bene. Non è usato molto.