Ingresso oscuro del nome utente nei moduli di accesso?

In teoria, il professore dovrebbe aver scollegato il computer dal proiettore durante la lezione. Qualsiasi numero di cose può andare storto quando si digita una password che dovrebbe essere codificata di fronte a una classe di studenti.

Ciò darebbe l'impressione che il nome utente dovesse essere tenuto segreto e farebbe credere agli utenti che il nome utente fosse altamente protetto dall'applicazione in misura simile a quella della password. Se la tua applicazione ha una sicurezza così elevata che potresti già archiviare il nome utente in modalità hash o in altro modo sicuro, la pagina di accesso potrebbe mascherare anche il nome utente, ma potrebbero esserci problemi di usabilità:

1. Se il nome utente dovesse essere mascherato, non ci sarebbe alcun completamento automatico per quel campo, probabilmente rendendo le persone infastidite nei tempi supplementari necessari per accedere al loro account.
2. Gli utenti potrebbero voler provare diversi nomi utente per vedere quale funziona. Se non riescono a vederlo e non riescono a vedere la password, avranno un tempo più difficile a capire se hanno sbagliato a digitare il nome utente, se la password è sbagliata o se il nome utente (o email) non è quello utilizzato per la registrazione innanzitutto. Gli utenti potrebbero semplicemente utilizzare un editor di testo in anticipo per essere sicuri, ma questo tipo di sconfigge lo scopo.
3. La possibilità di errori di battitura è maggiore. Poiché gli utenti non possono vedere il nome utente, la loro possibilità di errore è maggiore poiché potrebbero aver commesso un errore sia nel nome utente che nel campo della password.
4. Gli utenti non vengono avvisati quando è attivato Caps Lock (a meno che l'applicazione non provi a farlo). Normalmente, possono digitare il loro nome utente e capire che il blocco maiuscole è attivo. Quindi, lo spengono e si riavviano. Senza vedere nessuno dei due campi, non lo noterebbero.

Questa è un'ottima domanda. Non è difficile immaginare persone che commettono errori quando accedono al loro account in fretta, senza che ci sia un Tab e alla fine hanno digitato (o peggio sottomettendo) la loro intera password sul campo del nome utente.

È importante capire che l'obiettivo del mascheramento della password è impedire la navigazione a spallamento . Non impedisce ai keglogger di scoprire la tua password; né impedisce ad un MITM di intercettare la tua password in testo normale trasmessa su un canale non criptato. Tuttavia, è sempre una buona abitudine controllare l'ambiente prima di eseguire un'autenticazione per ridurre al minimo l'esposizione al rischio di navigare sulla spalla. Nei rari casi in cui devi eseguire un'autenticazione di fronte a un pubblico, è necessario l'assistenza speciale .

Detto questo, l'implementazione specifica dell'interfaccia di accesso è di solito un equilibrio tra rischio e usabilità. Per le applicazioni web mobili, ci sono già alcuni siti web che fanno l'esatto contrario, cioè smascheramento della password durante la registrazione per migliorare l'usabilità.

Nel caso in cui il tuo professore acceda al sistema scolastico, potrebbe fornire un buon argomento per mascherare il campo del nome utente. Tuttavia, come sottolineato da Anonimo , c'è un compromesso in termini di usabilità. Quindi, spetta davvero allo sviluppatore del sistema decidere se il rischio di divulgazione della password da parte di pochi individui disattenti valga la pena rendere l'interfaccia di accesso meno utilizzabile per tutti.

Un'opzione migliore è quella di educare tutti gli utenti alla sicurezza delle informazioni di base , come non condividere la password con altri account. Perché, tutto lo sforzo che serve per migliorare la sicurezza viene a zero se l'utente finale è spericolato e scrive la sua password su una nota post-it e attaccarla al monitor!