Come funziona l'autenticazione dell'account Microsoft di Windows 8?

In effetti funziona più nella direzione opposta. Per accedere al tuo PC, usi una password che hai istruito sul tuo PC per riconoscere. Quando si configura il PC per accettare un "account Microsoft", si impone infatti al PC di riconoscere la password dell'account Microsoft come "password locale" - e verrà utilizzata la stessa password per accedere ai server Microsoft per tutte le funzioni di auto-sincronizzazione e app che hanno.

I dettagli esatti possono essere intricati ma il principio rimane lo stesso: l'autenticazione è prima locale, e poi (solo allora) le credenziali vengono anche usate per parlare con i server Microsoft.

Una conseguenza è che se qualcuno riesce a ottenere la password del tuo account dai server di Microsoft (supponendo che lo memorizzino e non solo un hash, che non sarebbe una buona idea), otterrebbe la password per il tuo computer locale, che non lo porterebbe lontano finché non potrà accedere fisicamente al computer, a quel punto potrebbe semplicemente afferrarlo ed eseguire, password o nessuna password.

L'avvelenamento del DNS è sconfitto da SSL. Il punto di SSL è quello di astrarre il mezzo di trasporto, compreso il DNS e l'indirizzo IP. Il client è sicuro di parlare con il server giusto perché ha convalidato il certificato del server e utilizza la crittografia basata sulla chiave pubblica trovata in quel certificato. Presumibilmente, gli ingegneri di Microsoft si sono presi cura di utilizzare le convalide e le verifiche del certificato appropriate (sicuramente lo possono fare perché lo stesso codice viene utilizzato quando si accede al proprio conto bancario tramite il sito Web della propria banca gestito da HTTPS).

Windows utilizza un provider di credenziali e una SSPI per fornire la funzionalità. L'SSPI comunica tramite servizio Web agli endpoint Microsoft. Gli endpoint vengono configurati memorizzandoli in una DLL con firma del codice che viene spinta verso il basso tramite Windows Update. L'SSPI caricherà la DLL, verificherà il suo codice firmato da Microsoft e analizzerà gli endpoint necessari.

Quando l'SSPI si connette agli endpoint confronta il certificato SSL con un valore memorizzato nella DLL di configurazione. Non sono sicuro se si tratta solo di confronto soggetto o se hanno fatto confronti chiave, ma se il confronto non riesce per qualsiasi motivo la richiesta viene respinta.

Inoltre, il processo è protetto da un segreto client. Le credenziali inviate all'endpoint vengono crittografate utilizzando un segreto locale noto agli endpoint Microsoft. Non sono sicuro se sia una chiave simmetrica o una chiave asimmetrica. La chiave asimmetrica potrebbe essere più probabile. Questa chiave è condivisa durante il processo di bootstrap che si verifica quando registri il computer come Live ID abilitato.

Per ulteriore misura, il modo in cui funziona SSO nei siti abilitati al Live consiste nel memorizzare un cookie con un token di breve durata in esso contenuto per uno dei domini di Live ID. Una volta che un utente è stato autenticato dalla SSPI, una richiesta viene inviata a un altro servizio Web per ottenere un token dispositivo. Il servizio è autenticato da un trust federato su Live ID. Se si dispone di un token da Live ID rilasciato al dispositivo, è possibile chiamare questo servizio per ottenere un altro token. Questo token del dispositivo viene serializzato su un determinato formato e scritto su un cookie all'interno della sessione Windows dell'utente. La volta successiva che l'utente naviga su un sito di Live ID, il cookie sarà presente, convalidato e non ti verranno richieste le credenziali. C'è un po 'più di questo, ma questo è il succo del processo.

Pertanto, per quanto riguarda spoofing o manomissione, Microsoft utilizza il blocco del certificato per impedire MITM e utilizza un segreto condiviso per impedire ai client non autorizzati di effettuare richieste di autenticazione.

Modifica: se il certificato corretto non si trova nella DLL, la richiesta avrà esito negativo. Un amministratore potrebbe spoofare la DLL, ma avrebbero dovuto firmarlo con le chiavi di firma del codice di Microsoft e, beh, problemi più grandi e tutto questo se potevano farlo. Se l'amministratore acquisisce la chiave condivisa in qualche modo, allora potrebbe spoofare una richiesta utilizzando il token, ma ciò significa che devono acquisire il token in qualche modo, il che è reso molto più difficile dal blocco del certificato. A quel punto potrebbe essere più semplice installare un falso Provider di credenziali e raccogliere le credenziali.