Autorizzazione a un computer per accedere a un'applicazione Web

Question

Ho un'applicazione Web e ho il compito di aggiungere l'accesso sicuro per rafforzare la sicurezza, simile a ciò che Google ha aggiunto agli account Google.

Use Case

In sostanza, quando un utente accede a, vogliamo rilevare se l'utente ha precedentemente autorizzato questo computer. Se il computer non è stato autorizzato, all'utente viene inviata una password monouso (tramite e-mail, SMS o telefonata) che deve immettere, in cui l'utente può scegliere di ricordare questo computer. Nell'applicazione web, monitoreremo i dispositivi autorizzati, consentendo agli utenti di vedere quando/dove hanno effettuato l'accesso da quel dispositivo per ultimi e rimuovere l'autorizzazione di qualsiasi dispositivo, se lo desiderano.

Abbiamo bisogno di una soluzione molto leggera (che non richiede l'installazione di software sul lato client) e funziona con Safari, Chrome, Firefox e IE 7+ (sfortunatamente). Offriremo la sicurezza x509, che fornisce una sicurezza adeguata, ma abbiamo ancora bisogno di una soluzione per i clienti che non possono o non vogliono usare x509.

La mia intenzione è quella di memorizzare le informazioni di autorizzazione utilizzando i cookie (o, potenzialmente, utilizzando la memoria locale, degradando ai cookie flash e quindi i cookie normali).

a prima vista

pista due valori distinti (dati locali o biscotti): un hash che rappresenta un sign-on di token, oltre a un gettone dispositivo sicuro. Entrambi i valori sono guidati (e registrati) dall'applicazione Web e dettati al client. Il token SSO dipende dal dispositivo e da un numero di sequenza. Ciò consente di rimuovere i dispositivi in ​​modo efficace (tutti i token SSO non sono più validi) e attenua il replay (non efficacemente, tuttavia, ecco perché sto facendo questa domanda) attraverso l'uso di un numero di sequenza, e utilizza un nonce.

Problema

Con questa soluzione, è possibile che qualcuno di copiare solo i token SSO e dei dispositivi e l'uso in un'altra richiesta. Mentre il numero di sequenza mi aiuterà a rilevare un tale abuso e quindi a rimuovere l'autorizzazione del dispositivo, il rilevamento e la risposta possono avvenire solo dopo che il dispositivo valido e la richiesta malevola hanno tentato l'accesso, il che comporta un tempo sufficiente per il danneggiamento.

Mi sento di usare HMAC sarebbe meglio. Traccia il dispositivo, la sequenza, crea un nonce, timestamp e hash con una chiave privata, quindi invia l'hash più quei valori come testo normale. Il server fa lo stesso (oltre a convalidare il dispositivo e la sequenza) e lo confronta. Ciò sembra molto più semplice e molto più affidabile ... supponendo che possiamo negoziare, scambiare e archiviare in modo sicuro le chiavi private.

Domanda

Allora, come posso negoziare in modo sicuro una chiave privata per il dispositivo autorizzato, e quindi archiviare in modo sicuro la chiave? È più possibile, almeno, se mi accontento di memorizzare la chiave privata usando i cookie di archiviazione locale o flash e dico solo che è "abbastanza buono"? O c'è qualcosa che posso fare alla mia bozza originale per mitigare la vulnerabilità che descrivo?

Answer 1

Sospetto che tu stia chiedendo più sicurezza rispetto al sistema, come descritto, può fornire. In parole povere, se non riesci a controllare il cliente, può (errare) utilizzare i token SSO e dispositivo in una miriade di modi (non intenzionali), come sai. Non importa quanto bene progetta le altre parti del tuo sistema; questo è il tallone d'Achille del tuo sistema.

In un altro modo, nel sistema come lo avete descritto, state affidando e affidando al browser Web del client il token del dispositivo e il token SSO. Destra? In tal caso, come si può impedire il movimento di questi token su altri dispositivi? (Vedere strategie di mitigazione, di seguito).

Ora, per rispondere alle vostre domande a testa alta con questo in mente:

"Allora, come posso negoziare in modo sicuro una chiave privata per dispositivo autorizzato , e quindi memorizza in modo sicuro quella chiave? "

Non fa male a farlo, ma non sarà di aiuto, come ho spiegato sopra.

"è più possibile, almeno, se mi sistemo per memorizzare la chiave privata utilizzando cookie di stoccaggio o Flash locale e solo dire che è 'abbastanza buono'?

non posso dire che cosa "abbastanza buono" è. è necessario comunicare chiaramente l'attacco "gettoni in movimento" e aiutare il cliente a prendere una decisione informata.

"Oppure, c'è qualcosa che posso fare per il mio progetto iniziale per mitigare la vulnerabilità Descrivo? "

Esistono certamente strategie di mitigazione che dipendono dalla base di installazione dell'utente e dalla tolleranza al rischio.

La domanda chiave, per come la vedo io - pensa alle capacità e alle abilità del tipo di persona che può spostare i token da una macchina all'altra - può la tua strategia di mitigazione fare una profonda ammaccatura in quel comportamento senza degradare il sistema prestazioni e usabilità per utenti "onesti"?

Ecco alcune idee:

• Si potrebbe utilizzare autenticazione a due fattori, come ad esempio RSA SecurID. Ciò non impedirà lo spostamento di token macchina, ma richiederebbe che il TFA si sposti con esso.

• Si può provare a nascondere o nascondere le copie locali di questi token, ma questo sembra sicurezza solo attraverso l'oscurità.

• È possibile controllare l'indirizzo MAC di una macchina. Se è più difficile clonare un indirizzo MAC che spostare un token dispositivo, questo potrebbe essere un utile livello di sicurezza.

• Si potrebbe provare a richiedere l'utilizzo di alcuni browser personalizzati che "bloccano" l'accesso a questi token. Questa è solo un'idea; Non so se è pratico.

• Se si sa che le macchine non devono spostarsi fisicamente, è possibile esaminare le proprietà di rete per cercare prove che una macchina si trovi in ​​un percorso di rete diverso e, quindi, in una posizione fisica.

• Se si interrogano e si memorizzano (sul server, non sul client) le informazioni di configurazione del computer, è possibile rilevare se un token si sposta da una macchina con una configurazione a una macchina con una diversa. (Questo approccio, ovviamente, si lamenterebbe quando una macchina viene aggiornata.)

• Anziché memorizzare token dispositivo locali, è possibile richiedere l'installazione di un'applicazione che fornisce un'API di autenticazione all'applicazione Web. Questa applicazione potrebbe incorporarsi da qualche parte sul computer che è difficile da hackerare, sradicare o spostare. (In questo modo, questa applicazione potrebbe fornire un sistema di "autenticazione a due fattori" per la macchina.)

• In concerto con, o separatamente dall'idea sopra, è possibile installare un'applicazione separata "telefono di casa" sul dispositivo. Avrebbe "check-in" di volta in volta con il tuo server. Se cambia la posizione della rete, la configurazione del dispositivo o si blocca, è possibile negare l'accesso di conseguenza.

Spero che questo aiuti. Non mi considero un esperto di sicurezza, ma mi piace pensare ai problemi di progettazione. Potresti ricevere risposte migliori se chiedi oltre allo https://security.stackexchange.com/)

Answer 2

Che dire dell'acquisizione dell'indirizzo MAC del computer e della memorizzazione di tali informazioni anche nel database? Gli indirizzi MAC che conosci sono unici per tutti i computer, contro un indirizzo IP.

Getting MAC address on a web page using a Java applet

ricerca online ci sono diversi modi per catturare gli indirizzi MAC tramite pagine web e applet.