... che potrebbe essere utile in un attacco ma normalmente non è disponibile per l'attaccante

La conoscenza dei caratteri di input non validi è utile ma può essere facilmente trovata dall'attaccante con pochi tentativi. Pertanto, queste informazioni non sono realmente segrete e tenere tutti gli utenti all'oscuro di ciò che è andato storto esattamente non scoraggia gli aggressori, ma tiene lontani gli utenti innocenti poiché non possono continuare.

Creare una situazione psicologicamente frustrante per gli utenti potrebbe indurli a prendere decisioni meno sicure. Ad esempio, provano a scrivere una password in svedese, ma il tuo input rifiuta il carattere å senza spiegazione. Invece di scegliere una buona password diversa senza å , alzano le mani e usano password123 , che può essere facilmente sconfitta con un attacco del dizionario.

Così , hai tentato di creare un sistema "più sicuro" attraverso l'oscurità, ma una volta che teniamo conto dei comportamenti degli utenti, in realtà è meno sicuro.

I caratteri validi sono alla fine individuabili attraverso mezzi sistematici. Nasconderli non vale il danno che potresti arrecare ai comportamenti degli utenti.

Per ulteriori letture, vedere " Sicurezza e pregiudizi cognitivi: esplorazione del ruolo della mente" e " Misurazione degli impatti sulla sicurezza dei criteri per le password utilizzando cognitivo comportamentale Modellazione basata su agenti "di Sean Smith et al.

Dipende.

Se il messaggio descrive un errore dal punto di vista degli utenti normali, come "Il terzo carattere deve essere una cifra", non è una vulnerabilità di sicurezza. Ma visualizzare l'espressione regolare utilizzata per la convalida significa divulgare dettagli di implementazione che possono essere un punto debole, ad es. alcune librerie utilizzano ampiamente chiamate ricorsive e alcune espressioni possono causare un overflow dello stack o un elevato utilizzo di memoria e CPU, il che può portare a DoS.

Il CWE-200 definisce la divulgazione di informazioni come un punto debole solo se l'utente non è esplicitamente autorizzato ad avere accesso a tali informazioni . Stai considerando l'input dell'utente. Significa che l'utente è autorizzato a inserire queste informazioni e quindi gli è permesso di vedere queste informazioni e, naturalmente, gli è consentito vedere qualsiasi messaggio di errore di convalida relativo a questo input.

Stack trace così come altri messaggi tecnici possono fornire informazioni sulle tecnologie utilizzate nell'applicazione (ad esempio quale versione di quali librerie vengono utilizzate), sull'ambiente (ad esempio layout di directory e permessi, tipo di sistema operativo e versione), ecc. Un utente malintenzionato può utilizzare queste informazioni in modo efficace scegliere exploit per queste particolari tecnologie, librerie, sistemi operativi, ecc. Ecco perché divulgare tali informazioni all'utente è potenzialmente una debolezza.

Non spiegare all'utente cosa c'è di sbagliato nel suo input è sicuramente una cattiva UX, ma non sicurezza miglioramento.

Non confonderlo con casi simili, quando i dati sono sensibili e qualsiasi convalida ad essi correlata può essere sensibile. Ad esempio, se l'utente ha immesso lettere nel campo in cui ci si aspetta un anno, spiegare tale errore all'utente è sicuro. Ma se l'utente inserisce un indirizzo e-mail e controlli se tale indirizzo è registrato nel tuo sistema, qualsiasi informazione (l'indirizzo è noto, l'indirizzo è sconosciuto) può essere un punto debole. Ecco perché quando implementerai messaggi di convalida o qualsiasi altro feedback sull'input dell'utente, valuta le conseguenze. Ma vietare qualsiasi feedback per impostazione predefinita per tutti i campi può essere una scarsa UX con una falsa sensazione di sicurezza.

Questo è solo uno dei tanti scenari in cui sono previsti compromessi di sicurezza a favore dell'usabilità del sistema.

Tuttavia, c'è un'enorme differenza tra la visualizzazione delle tracce dello stack (scarsa gestione degli errori) e declinare quali caratteri sono previsti o proibiti in un campo di input.

Per la maggior parte degli scenari, si può sostenere che negare quali caratteri sono previsti o proibiti in un campo di input è non una vulnerabilità di sicurezza a tutti, se sono in atto altri meccanismi di sicurezza, come limitare i tentativi di password.

È possibile determinare utilizzando un framework di modellazione delle minacce che questo è un rischio accettato del sistema.

L'oscurità non è sicurezza. Un buon sistema è sicuro anche quando un utente malintenzionato sa tutto al riguardo. Nel tuo caso, ridurre le ipotesi di cracking sprecate di una certa percentuale, diciamo il 25%, non dovrebbe creare o distruggere la praticità del cracking: 1 trilione di anni è pratico quanto 0,75 trilioni di anni. Avere dettagli di implementazione non occlusi aiuta anche i nuovi bravi ragazzi a difendersi.

Ci sono anche considerazioni sociali. Un segno "ATTENZIONE AL CANE" potrebbe far trapelare dettagli sull'implementazione della sicurezza, ma scoraggia anche una certa scala di attacchi comuni. Il cane aiuta, noto o sconosciuto, ma un cartello potrebbe ridurre i costi di manutenzione della recinzione, liberando risorse per combattere altre battaglie.

Le altre risposte mostrano come divulgare questo non sia un problema di sicurezza.

Sosterrò con un vero aneddoto che la mancata divulgazione può portare non solo a frustrare gli utenti ma anche a una minore sicurezza.

Questo mi è successo più di una volta su siti che non chiarivano quali caratteri sono consentiti. A quel tempo non usavo un generatore di password, quindi avevo uno schema mentale per ricordare le password. Comprendeva l'uso di alcuni caratteri speciali come $ @. & . Alcuni tentativi frustrati in cui tutto ciò che ho ottenuto erano "caratteri non validi nella password" e ho iniziato progressivamente a eliminare i caratteri speciali. Poi è arrivato "la tua password non è abbastanza sicura, prova ad aggiungere alcune cifre e simboli" ... sì ... sono decisamente rilassato a questo punto.

Finalmente ho capito per accettare la mia password. Che non solo conteneva un solo carattere speciale, ma non si adattava a nessuno dei miei schemi per ricordare le password, quindi ho dovuto ... hmm ... conservarlo da qualche altra parte (questo era prima ancora che conoscessi i gestori di password, quindi immaginate come l'ho assicurato. Vi dirò che era come un elicottero e come una corda).

Non vedo alcun problema nel rivelare il set di caratteri tra cui l'utente può scegliere, a patto che queste regole siano da un lato anche applicate e verificate. Vale a dire, se l'utente non è autorizzato a utilizzare \ nel campo, non è sufficiente verificarlo nell'ingresso JS, ma anche prima di inserirlo, ovvero nel DB e quando vengono utilizzati i dati. Quindi le regole devono essere applicate sempre (TOCTOU). L'altra parte è che non è un problema ridurre il set di caratteri, purché l'entropia sia ancora data. Puoi ridurre i caratteri della password a "a" e "b", ma poi devi aumentare la lunghezza minima della PW di conseguenza (e verificare che non stiano solo tenendo premuto il tasto "a" finché non è abbastanza lungo). Con una password abbastanza lunga (casuale), anche questa sarebbe una password sicura. Alla fine, tutto ciò che c'è in un carattere sono bit, e tutti sanno che questi sono 0 & 1, quindi l'alfabeto (reale) è sempre noto, come molti possibili accordi ci sono, sta a te specificarli (e verificarli).