Un codice di autenticazione messaggio adeguato per REST

7

Il mio servizio REST attualmente utilizza l'autenticazione SCRAM per rilasciare token per chiamanti e utenti.

I token rilasciati dallo scambio SCRAM hanno una scadenza oltre la quale è richiesto un accesso ripetuto. Emetteremo anche "infiniti" token che non hanno scadenza per semplificare l'integrazione per gli individui (che useranno il nostro servizio per uso personale) e in preparazione per un endpoint JSONP.

Abbiamo la possibilità di revocare i privilegi del chiamante (l'account a cui è collegato il token) e vietare gli IP, nonché di imporre quote a qualsiasi tipo di richiesta in qualsiasi periodo di tempo.

Una cosa che non ho implementato, tuttavia, è MAC per le richieste. Come ho pensato di più, per alcune richieste penso che questo sia necessario, perché altrimenti i token possono essere rubati e prima di identificare questo e disattivare l'account del chiamante associato, alcuni danni potrebbero essere fatti ai nostri account utente.

In molti sistemi il MAC è generato dal corpo o dalla stringa di query della richiesta, tuttavia è difficile da implementare poiché sto usando l'API Web ASP.Net e non voglio leggere il corpo due volte. Altrettanto importante è che sia semplice per i chiamanti accedere al servizio e devo essere in grado di supportare sia app desktop / mobili che browser web.

Quindi quello che sto pensando è di avere un codice MAC inviato a un utente al momento della registrazione, e di averne calcolato un MAC su richiesta:

  • l'url, eventualmente meno la stringa di query
  • il verbo
  • la richiesta ip (potenzialmente è una barriera su alcuni dispositivi mobili e sicuramente è in javascript)
  • utc data e ora in cui il client invia la richiesta.

Per l'ultimo vorrei che il client mandasse quella stringa in un'intestazione di richiesta, ovviamente - e posso usarlo per decidere se la richiesta è abbastanza "fresca".

Il mio pensiero è che mentre ciò non impedisce la manomissione del corpo del messaggio, impedisce di utilizzare una richiesta di modello da utilizzare come modello per richieste diverse successivamente da parte di terzi malintenzionati. Credo che solo l'uomo più aggressivo nell'attacco di mezzo sarebbe in grado di sovvertire questo, e non penso che i nostri servizi offrano informazioni o abilità che siano abbastanza valide da meritarlo.

I servizi useranno anche SSL, per cose sensibili. E se lo faccio, allora userò HMAC-SHA-256 con la chiave generata usando un PRNG.

Questo suona abbastanza? Ho perso qualcosa?

Non penso di essere un principiante quando si parla di sicurezza, ma quando ci lavoro lo faccio sempre. Sono avvolto nel dubbio, quindi apprezzo avere questa comunità da richiamare!

    
posta Andras Zoltan 28.10.2012 - 12:51
fonte

2 risposte

4

Se si utilizza SSL per il trasporto e lo si esegue correttamente, qualsiasi altro MAC aggiuntivo è ridondante; e, quando si tratta di esso, lo è anche SCRAM . Un punto vendita di SCRAM è che deve resistere a situazioni in cui SSL viene utilizzato impropriamente , cioè senza autenticazione server appropriata (sfortunatamente succede ). Ma l'argomento sicurezza di SCRAM è piuttosto debole in una situazione del genere, perché non impedirà un man-in- attacco di mezzo-centrale ; e, senza un MitM, la semplice password semplice all'interno di SSL è già buona. L'unico vantaggio di SCRAM rispetto a una password semplice è che in caso di MitM, l'utente malintenzionato non impara subito la password. Vede ancora tutti i dati scambiati e può inserire comandi propri e ottiene sufficienti dati per eseguire un attacco dizionario offline , qualcosa che pochissime password arrivano indenni.

Nella tua proposta di aggiungere un MAC, non dici da dove proviene il tasto MAC . Questo è fondamentale. Un MAC ha un valore purché la chiave sia sconosciuta all'attaccante. Ma se il client e il server condividono già una chiave sconosciuta all'attaccante, perché dovrebbero preoccuparsi di una password e di SCRAM? Consentitegli di utilizzare TLS a chiave precondivisa , ovvero SSL / TLS con la chiave condivisa come base per l'autenticazione reciproca e la crittografia: no certificato (quindi nessuna convalida del certificato per sbagliare), operazione rapida e rapida.

Ancora meglio, se il client e il server condividono una password, non vogliono usare certificati, temono gli attacchi del dizionario offline e non vogliono che il server memorizzi le password così come sono, quindi la soluzione è TLS-SRP . Client e server si autenticano reciprocamente relativamente a una password comune, il server non memorizza la password ma solo un hash-equivalente e la password è al sicuro dagli attacchi del dizionario offline, anche in caso di tentativo MitM (non solo il tentativo è sventato, ma l'attaccante non guadagna nemmeno abbastanza dati da "provare le password a casa").

A un certo punto i progettisti SCRAM sono stati probabilmente informati sull'SRP, perché hanno aggiunto nella sezione 9 delle specifiche il seguente paragrafo:

Authentication mechanisms that protect against this attack are available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is an example of such technology. The WG elected not to use EKE like mechanisms as a basis for SCRAM.

Non forniscono alcuna giustificazione del perché rifiutano i protocolli PAKE (che chiamano impropriamente "EKE", che è solo il nome del primo protocollo PAKE conosciuto).

    
risposta data 31.10.2012 - 00:27
fonte
0

Per la maggior parte delle impostazioni, ti consiglio di utilizzare solo token HTTPS (SSL) e CSRF. Questa è l'architettura standard per la protezione di un'applicazione Web / servizio web. Se utilizzi token HTTPS + CSRF, non hai bisogno di un MAC.

Rinuncerei all'idea di "usare SSL solo per le cose sensibili". Questo ha alcuni problemi. Consiglierei di usare HTTPS in tutto il sito. Cerca su questo sito per informazioni su pro e contro sull'utilizzo di SSL in tutto il sito e su come implementarlo.

Non so se la tua interfaccia è solo per uso programmatico o se sarà usata anche dagli umani. In tal caso, HTTPS offrirà probabilmente la migliore usabilità per gli utenti, se il lato client ha una seduta umana dietro un browser web.

    
risposta data 31.10.2012 - 12:59
fonte

Leggi altre domande sui tag