Sto basando la mia risposta sul presupposto che una password monouso sia utilizzata come secondo fattore, oltre a una tradizionale combinazione nome utente / password. Se questo non è il caso e la password monouso è l'unico fattore, la risposta di Gilles è sicuramente più applicabile.

Molto probabilmente a causa della Programmazione Cargo Cult, che significa seguire ciecamente schemi che sono stati osservati altrove, senza comprenderne il vero significato.

Uno sviluppatore potrebbe vedere la password " "in" One-time password "e rendila felicemente <input type =" password "> . Dopotutto, è lì per questo, giusto?

C'è uno svantaggio?

Dal punto di vista della sicurezza, no. La divulgazione di una password monouso a terzi (ad esempio tramite navigazione a spalla) non è altrettanto problematica, perché la password perde validità dopo un utilizzo o dopo un certo periodo di tempo.

L'unico svantaggio immaginabile sarebbe un'esperienza utente inferiore, poiché un utente potrebbe avere problemi a garantire che ciò che ha digitato corrisponda effettivamente alla password ricevuta.

Il motivo per nascondere le password è impedire la navigazione a spalla: qualcuno che è fisicamente presente (o qualcuno che osserva attraverso una telecamera) potrebbe essere in grado di leggere la password sullo schermo. Anche questo è un rischio per una password monouso, ma in misura molto minore per due motivi: la password monouso è valida solo per un breve periodo e viene comunque visualizzata sul dispositivo OTP. Ma è comunque un rischio. A seconda del tipo di OTP, può rimanere valido per un paio di minuti (se è basato sul tempo e il server non protegge dalla riproduzione) o fino a quando l'utente legittimo non ha terminato di digitarlo (se è basato su sequenza o il server protegge dalla riproduzione). Spesso lo schermo del dispositivo OTP è meno visibile ai navigatori a spalla rispetto al computer in cui l'utente entra nell'OTP.

Dichiarare un campo come password fa altre cose oltre a nascondere i dati: potrebbe impedire la copia nel appunti e potrebbe impedire all'applicazione di registrare l'OTP in una cronologia delle voci del modulo. Nessuno di questi ha alcun vantaggio in termini di sicurezza, ma omettere l'OTP dalla cronologia delle voci ha un vantaggio di usabilità: evita di dare agli utenti l'impressione che l'OTP sia un input valido in seguito.

Queste sono ragioni piuttosto deboli. Il motivo principale è che i progettisti di moduli vedono che l'input è una password di qualche tipo e quindi la dichiarano come una password.

Speculare sul motivo di altri sviluppatori è forse uno scarso utilizzo del tempo, ma posso vedere un vantaggio che non è stato menzionato.

Psicologicamente, far sembrare una password aiuta le persone ad associarla con sicurezza. Trasferisce il messaggio che abbiamo spinto per decenni che "non dici alla gente la tua password" alle OTP e, si spera, aiuta alcuni utenti in più a mettere in pausa e fare domande quando Bob Hackerman li chiama chiedendo loro di confermare il codice a sei cifre che ha appena inviato loro. L'utente è solitamente la parte più debole del sistema, quindi sembra un luogo ragionevole in cui investire.

Tecnicamente, ci sono degli svantaggi (come il browser che lo memorizza) e sarebbe meglio con un campo HTML dedicato per le OTP. Anche se ne avessimo uno, sarebbe del tutto ragionevole averlo puntato come UX predefinito.

Il motivo per nascondere l'input del campo potrebbe essere dovuto a schemi di programmazione (come ha dichiarato @ MechMK1), perché lo sviluppatore non codifica un campo separato per ogni tipo di autenticazione offerto, quindi riutilizzano il campo con il tipo di password. In caso contrario, il codice potrebbe gonfiarsi.

Un utente malintenzionato potrebbe utilizzare la password una tantum quando vede che la digiti.

Si tratta di una questione di tempismo. Se è un aggressore sofisticato, potrebbe leggere la password monouso non nascosta e allo stesso tempo bloccare la connessione di rete prima di premere invio . Quindi può leggere l'OTP che stai digitando, impedirti di inviare il modulo e utilizzare l'OTP per accedere come te.

Questo potrebbe sembrare molto imbarazzante, ma a nostro parere dovrebbe occuparsi di un'implementazione sincera di Come ha sottolineato @ MechMK1, l'OTP è - come suggerisce il nome - valido solo una volta . Ma l'OTP viene invalidato solo quando il server lo verifica. E come accennato, se l'attaccante può impedirti di inviare l'OTP al server, l'otp non viene invalidato e l'attaccante può utilizzare questa stessa OTP prima di te.