Per quanto tempo i campi della password HTML (inviati al server come postati) rimangono in memoria?

In qualsiasi struttura web sul lato server principale, di solito c'è un meccanismo per leggere l'input del modulo HTML, ad es. in ASP, per un elemento HTML, <input type="text" name="the_field" /> , è Request.Form("the_field") , dove Request.Form è un oggetto di tipo dizionario in cui i valori vengono analizzati dai dati POST in coppie chiave / valore.

Ci sono anche varie raccomandazioni per mantenere solo le password in memoria per un tempo minimo, fino a includere un array di caratteri mutevole invece di una stringa immutabile, bloccandolo in modo che non possa essere sfogliato o copiato e azzerando ogni elemento dell'array quando fatto (o usando qualcosa come .NET SecureString , che fa lo stesso).

Dato ciò, quali meccanismi potrebbero esistere per comunicare al server Web che è necessario trattare i dati del modulo postati come sicuri e fare il pinning / clearing per, diciamo, un campo HTML <input type="password" /> ?

Si potrebbe ragionevolmente aspettarsi che il browser faccia il miglio supplementare per i campi password (anche se mi aspetto che non lo facciano), perché possono dedurre dal markup che tali protezioni sono necessarie.

Il livello di trasporto è coperto da HTTPS e non è in discussione.

Ma nulla di ciò che ho visto fornisce al server web la semantica dei dati post, quindi può scegliere di applicare protezioni in-memory.

Ho avuto un paio di idee su come una cosa del genere potrebbe essere gestita in un server web se progettata da zero (si noti che non sto progettando un server web da zero!):

1. Applica le protezioni in memoria a tutte le richieste: Sembra che potrebbe essere più diretto, ma potrebbe avere un impatto negativo sulle prestazioni per le pagine che non sono strettamente sensibili ma vengono servite sotto SSL (es. Siti tutto-SSL o pagine 'My Account' che non hanno campi 'Nuova password'). Potrebbe essere configurabile a "tutte le richieste" / "Solo HTTPS"

2. Standardizzazione di un'intestazione HTTP che definisce i campi da proteggere: attenua il problema all-SSL, ma fornisce un ovvio punto di partenza per l'ispezione (anche se sono sicuro che txtUser=foo&txtPassword=bar è già un indicatore abbastanza buono). Prenderesti x anni per il W3C per concordare uno standard, e un altro y anni per i browser per implementarlo.

3. Registra campi postali sicuri nella configurazione del server (o attraverso l'integrazione della lingua): Il parser del flusso di richiesta del server sarà responsabile della lettura di ogni chiave del post, verificando l'elenco interno e applicando protezioni di memoria al successivo valore di post. Forse anche escludendolo dal normale Request.Form al posto di un oggetto Request.Passwords con una struttura di dati adatta allo scopo, o sostituendo il valore Request.Form con un riferimento all'oggetto SecureString .

Quindi ci sono server web che già lo fanno (o qualcosa del genere), o ti permettono un accesso a livello abbastanza basso per implementare queste protezioni manualmente? Ho pensato che forse la pipeline integrata di IIS7, ma non riesco a vedere un evento che viene eseguito abbastanza presto.

Sono necessarie protezioni del genere, o è solo una soluzione alla ricerca di un problema? In tal caso, cosa rende questo non necessario quando la gestione della password in-app di una app desktop non è?