Mi piace molto il primo approccio in generale.
- è semplice da capire e implementare
- è sicuro (per quanto ne sappia)
- è un approccio non insolito che ho visto usato in passato
Una cosa che non vedo menzionata sul primo che dovresti tenere a mente, il timestamp utilizzato per eseguire l'hash del token deve avere una scadenza TTL estremamente breve (come 1 secondo), quindi verifica che il messaggio non sia stato inviato con il stesso timestamp e token da un messaggio 12 ore prima; ovviamente calcolerebbe come legittimo ma non è in questo caso.
Se queste sono le uniche due opzioni che stai prendendo in considerazione, anche se mi piacerebbe solo assicurarti di aver preso in considerazione anche altri approcci, poiché ce ne sono molti. Più di quanto ho intenzione di elencare in effetti. Questi sono alcuni approcci di autenticazione comuni che vale la pena studiare solo per vedere se potrebbero adattarsi meglio al tuo scopo, e se nient'altro li capisce potrebbe darti alcune idee per aiutarti a stringere qualunque approccio segui.
Do atto, io sono non un esperto di sicurezza.
OAuth / Federated
In questo approccio hai un garante di terze parti in cui il codice utente richiede il token / cert / che cosa hai da loro e te lo passa, a questo punto tutto ciò che devi fare è chiedere alla terza parte se la chiave che ti è stata data è legittimo.
Pro:
- Basato su standard
- I problemi verranno rilevati da altri sui sistemi di altre persone, quindi scoprirai se si verifica insicurezza
- Sarà necessario molto meno lavoro di autenticazione da parte tua
con:
- Devi avere a che fare con un gestore di terze parti e la loro API, oppure creare e ospitare la tua "terza parte" per separare l'autent dal tuo servizio principale.
- Per molti servizi eccessivo, ma concettualmente vale la pena considerare
Certificati asincroni
Qui avresti i tuoi clienti crittografare le loro comunicazioni con un certificato pubblico che hai condiviso con loro quando hanno creato un utente. Dalla tua parte decifreresti usando la chiave privata associata all'utente. Generalmente inizieresti la comunicazione con una risposta alla sfida per mostrare che possono crittografare / decrittografare come ti aspetti di identificarli come chi sostengono di essere. Sebbene siano possibili approcci "sincroni" che non utilizzano la risposta alla sfida, hanno un po 'meno sicurezza e alcuni problemi di sincronizzazione del tempo che possono renderli più complicati.
di Novell (sì, lo so, Novell ? Davvero?)
I token utilizzano una variabile come base per generare la password singola. Questa variabile è chiamata la sfida. I due metodi principali per determinare la variabile utilizzata per generare la password sono asincroni o sincroni.
Con il metodo asincrono o challenge-response, il software server invia al token una sfida esterna, una variabile generata casualmente, per la crittografia del dispositivo token. Il token utilizza questa variabile di verifica, l'algoritmo di crittografia e il segreto condiviso per generare la risposta, ovvero la password crittografata correttamente.
Con il metodo sincrono, la variabile challenge utilizzata per generare la password è determinata internamente dal token e dal server. Un contatore di tempo, contatore di eventi o combinazione di contatore di tempo ed eventi all'interno di ciascun dispositivo viene utilizzato come base per la variabile challenge. Poiché il token e il server determinano ciascuno separatamente e internamente la variabile challenge dai propri contatori, è molto importante che i loro contatori temporali e contatori eventi rimangano sincronizzati. Poiché è così facile per il server e il token uscire dalla sincronizzazione, la maggior parte delle implementazioni consente una certa deviazione tra i contatori. In genere, per calcolare la password viene utilizzato un intervallo o una finestra di questi valori del contatore. Tuttavia, se il token e il server non vengono sincronizzati oltre questa finestra,
Pro:
- I certificati hanno radici CA che li rendono affidabili e difficili da forgiare
- Ci sono servizi standard nei sistemi operativi per la gestione e la manutenzione facili di depositi di certificati
- Approccio ben studiato, molte informazioni disponibili su di esso
- La scadenza insieme a una varietà di altre cose sono strutture integrate di certificati standard, generalmente robuste
con:
- I certificati possono essere difficili da lavorare a livello di codice
- A seconda se si richiede una CA esterna, potrebbe non essere libero
- Potrebbe essere necessario gestire manualmente gli archivi di certificati per garantire la configurazione dei trust root previsti
NTLM
Non ridere, se si tratta di un servizio solo più piccolo o interno e ti trovi in un ambiente Windows, non c'è nulla di sbagliato nell'utilizzo dell'autenticazione NTLM standard per garantire l'accesso. Soprattutto se stai lavorando con IIS, questo è senza dubbio l'approccio più semplice. Facile da mantenere e configurare anche in un web.config.
Pro:
- Estremamente facile da configurare, implementare e gestire
con:
- Interoperabilità minima
- Non sufficiente per l'autenticazione pubblica
nonces
Quando si lavora con nonces nel proprio approccio di autenticazione, si fornisce un metodo per ottenere un nonce sul servizio. Questo metodo restituisce una stringa arbitraria univoca o un pezzo di dati ("un nonce") su ogni richiesta. Ogni richiesta ad altri metodi ora richiede che un nonce sia recuperato e utilizzato nell'algoritmo crittografico per la richiesta. Il valore qui è che il server tiene traccia dei nonce utilizzati e non consente mai il riutilizzo di un nonce, questo impedisce completamente gli attacchi di riproduzione poiché una volta effettuata una richiesta con un nonce, una richiesta con quel nonce non potrà più essere fatta. Quando vengono richiesti nonces, questi vengono aggiunti a un elenco di nonces disponibili, poiché vengono utilizzati vengono spostati dall'elenco disponibile all'elenco utilizzato.
Pro:
- I replay respingono abbastanza bene gli attacchi
- Non del tutto difficile da implementare o comprendere
con:
- Richiede che i client facciano due richieste per ciascuna richiesta (anche se può essere ridotta richiedendo nonces solo per determinate richieste)
- Richiede la gestione di nonces, che dovrebbe essere transazionale
- Influisce negativamente sulle prestazioni richiedendo le richieste extra per le nonces (la transazionalità aumenta ulteriormente il costo delle risorse per lavorare con le nonces)