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!