Forza ID sessione ASP.NET

Poiché entrambe le implementazioni si basano sulla sicurezza del cookie per proteggere la sessione, ciò significa che il confronto si basa principalmente sulle qualità dei valori del cookie (ovvero se rubi i cookie in cui ti trovi).

Entrambi i valori sono fondamentalmente un valore crittografato rispetto a una chiave memorizzata sul lato server. Le sessioni utilizzano un valore casuale crittografato rispetto alla chiave del computer e le identità ASP.NET utilizzano una raccolta di valori che descrivono l'identità della sessione crittografata rispetto alla chiave del computer.

Le sessioni si basano su una mappa in memoria (o persistente su DB) dell'ID sessione decrittografata sulle informazioni di sessione, mentre le identità reidratano l'identità della sessione direttamente dal valore memorizzato nel cookie.

Da un lato, Sessions non è portabile perché si basa su un puntatore che riporta al valore in memoria, quindi se rimuovi quel puntatore la sessione è morta. D'altra parte, in realtà non scala bene.

Da un punto di vista puramente di sicurezza sono più o meno alla pari, ma Sessioni è stata deprecata per un intero gruppo di motivi non correlati alla sicurezza.

L'aggiunta di identità ASP.NET non dovrebbe essere un grosso problema. Guida qui .

La sessione non è stata progettata come meccanismo di autorizzazione. Ha alcune caratteristiche che lo rendono inadatto come usare lo stesso identificatore pre e post autenticazione, rendendolo vulnerabile alla fissazione della sessione . Inoltre, è difficile controllare lo stato di autorizzazione per l'accesso alla pagina, poiché ogni pagina dovrà avere i propri controlli manuali implementati.

Detto questo, alcuni meccanismi di autorizzazione nella vecchia autenticazione basata su form non erano perfetti. Ad esempio il metodo di disconnessione non ha cancellato lo stato di accesso al lato server :

Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.

Non sono sicuro che sia stato corretto nella nuova identità di ASP.NET.