Applicazione web del dispositivo affidabile

What is required to store for recognizing the machine securely?

Immagino tu intenda ragionevolmente univocamente e in modo affidabile - nel qual caso, questo è un problema difficile. Reso più difficile dal fatto che qualsiasi applicazione web non abbia accesso all'hardware sottostante: solo informazioni transitorie come la versione del browser e l'indirizzo IP. Sì, puoi ottenere molte informazioni su un sistema, ad es. come fa panopticlick, ma tale informazione è modificabile su richiesta.

Inoltre, qualsiasi di queste metriche può cambiare. Usando CPUID? Cosa succede se l'utente finale aggiorna il proprio processore? Il tuo stato di "dispositivo fidato" scompare. Potrebbe essere accettabile, oppure potrebbe non funzionare - pensa a Windows Activation.

In ogni caso, per proteggere da intercettazioni di token, MITM, replay e tutti gli altri tipi di questo tipo, devi assolutamente usare SSL per questo canale che mi porta a:

He will still have to log in using password + username, however, he can ONLY log in from given machine.

Questo mi sembra un caso d'uso per i certificati client SSL, nella mia mente. La solita logica assomiglia a questo:

1. Chiedi al browser un certificato client.
2. Se ne ottieni uno, controlla quel certificato, trova il DB utente ecc. e registra l'utente.
3. In caso contrario, visualizza la pagina di accesso dell'utente.

Penso che quello che stai chiedendo, tuttavia, è una variazione, in cui se trovi il certificato che presenti un modulo di accesso e altrimenti visualizzi un 403.

Ciò riguarda piuttosto bene il lato dell'autenticazione delle cose. Riduce inoltre la necessità di archiviare ID macchina univoci e tutti i problemi relativi alla loro generazione, anche se è possibile farlo insieme a ciò che si desidera, e consente all'utente di designare dispositivi attendibili semplicemente installando il certificato.

Can I safely store an encryption key (private) on the machine, so the user, doesn't need to input it when uploading data etc.?

Bene, non hai mai avuto alcuna garanzia della sicurezza del lato client sul web. Devi semplicemente fidarti che gli utenti si occupano delle loro credenziali.

Lo stesso vale per i cookie. Ricorda, gli utenti possono fare ogni sorta di cose sui cookie, incluso pulirli inaspettatamente. Se stai creando un'app Web e intendi eseguire la crittografia sul lato client in JS e perdi quella chiave, l'utente perderà i suoi dati.

Le alternative sono:

• Cifra i dati sul server. Come probabilmente hai intuito, questo significa che chiunque abbia accesso al server può ottenere da questi dati e nessuna protezione che applichi aiuterà.
• Cifra i dati sul client al di fuori del browser, dove lo spazio di archiviazione è più affidabile. Quando dico "al di fuori del browser", intendo tramite un meccanismo con un'archiviazione persistente adeguata che non sia cookie.
• Attendi la crittografia omomorfica.
• Progetta un modo per estrarre la chiave dal cookie e assicurati che gli utenti possano reinserirla nuovamente, se necessario.

In generale, il consiglio standard per i cookie (inclusi i cookie di sessione) su https è quello di utilizzare sicuro e httponly contrassegna in modo che XSS non funzioni e il cookie non perda.

Regola generale: non creare un'autenticazione personale. sistema. Utilizzare invece soluzioni esistenti e comprovate. Molto probabilmente fallirai diversamente, se consideri che gli esperti di stoneage continuano a fallire quando costruiscono cose del genere. Quello che descrivi (autenticazione hardware + memorizzazione dei dati di autenticazione nei cookie) sembra che tu stia cercando una soluzione basata sulle attestazioni. Dai un'occhiata al protocollo SAML e alle tecnologie che lo implementano come Microsofts Windows Identity Foundation . Assicurati di essere consapevole dei noti punti deboli delle implementazioni .