Domanda:
Perché non consentire spazi in una password?
David Cary
2013-03-15 21:12:22 UTC
view on stackexchange narkive permalink

"La tua password non può contenere spazi." è un messaggio che vedo da alcuni siti web, incluso 1.

Perché? (Questa domanda è molto simile a Perché non consentire caratteri speciali in una password?, ma le risposte non sembrano essere applicabili al carattere spazio).

Alcuni sistemi apparentemente eliminano tutti gli spazi prima hashing della password. ( In che modo Google non si preoccupa degli "spazi" nelle password specifiche delle applicazioni?)

Perché non semplicemente hashing qualunque cosa l'utente abbia digitato, spazi e tutto ?

C'è una domanda correlata da un diverso POV su UX.SE: [Devo tagliare gli spazi nelle password?] (Http://ux.stackexchange.com/questions/8010/should-i-trim-spaces-in-passwords) .
Qualsiasi restrizione esplicita come questa può essere utilizzata da un utente malintenzionato per ridurre lo spazio di ricerca.Come dire che deve iniziare con una cifra o avere una certa lunghezza.
Gli account Microsoft Office 365 non consentono spazi e parentesi angolari http://i.imgur.com/yxt96Jx.png.È il 2017, sei anni dopo che le password di quattro parole XKCD sono state rese popolari e Microsoft non è ancora in grado di gestire gli spazi.Immagino che memorizzino tutte le password in un enorme blob XML all'interno di un database di accesso da qualche parte.
Gli spazi non dovrebbero essere generalmente usati ovunque in cose come password, URL, nomi di file.In ogni caso possono causare diverse anomalie.
Una lettura interessante è che, in `NIST 800-63B`, si nota che * lo spazio dovrebbe essere accettato nella password *, vedere https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-verificatori-segreti-memorizzati Immagino che non tutti li ascoltino lol
Dieci risposte:
Jeff Ferland
2013-03-15 21:18:45 UTC
view on stackexchange narkive permalink

Non posso spiegarlo come qualcosa al di là della follia ereditaria o della copia pigramente delle restrizioni del nome utente in restrizioni della password senza previdenza.

Qualsiasi blocco di dati, stampabile o altro, dovrebbe essere accettabile se stai eseguendo l'hashing delle tue password. Le uniche restrizioni dovrebbero essere una complessità minima e una lunghezza massima di "sanità mentale" in modo che qualcuno non assorba 1 MB di larghezza di banda (e il tempo della CPU corrispondente per hash l'input perché si utilizza un algoritmo lento, giusto?) Ogni volta che effettua il login.

Il tempo di hashing non è irrilevante quando si utilizzano metodi di derivazione chiave, anche se il primo round richiede un po 'più di tempo?
Bene, non lo definirei irrilevante, ma hai ragione che la complessità temporale è la stessa per tutti i round dopo il primo, indipendentemente dall'input.
Vorrei controllare gli ambienti client pertinenti per i limiti di immissione dei campi. Ad esempio, un servizio online deve consentire gli accessi dai browser Web, quindi le restrizioni di input dovrebbero essere correlate alle limitazioni dei campi del modulo del browser (se presenti). Inoltre, il rifiuto delle nuove righe potrebbe prevenire problemi di incoerenza della piattaforma client (`\ r \ n` vs` \ n`).
Questo è guardarlo dal punto di vista di un computer. Certo, ai computer non importa quale sequenza di byte ottengono. Ma cosa succede se hai bisogno di condividere questa password tra esseri umani?
Non dimenticare di forzare il browser a inviare effettivamente UTF-8 tutto il tempo, altrimenti avrai fastidiosi bug.
@Laurent: è compito dell'utente assicurarsi di poterlo fare. Ma francamente, cosa ci fai qui se intrattieni il pensiero di "condividere le password"?
@jürgenA.Erhard, non ho alcun pensiero, solo affermando i fatti. Gli utenti a volte fanno "la cosa sbagliata" e non dovremmo fingere che non accada mai. C'è un costo / vantaggio per qualsiasi funzionalità che implementiamo. In questo caso, consentire gli spazi ha solo un vantaggio molto minore, ma un costo potenzialmente elevato (nelle chiamate di supporto o nel tempo di sviluppo sprecato per trovare "bug" quando in realtà sono solo gli utenti che digitano la password sbagliata).
E che dire di consentire "qualsiasi blocco di dati" come suggerito in questa domanda? Potrebbe andare bene dal tuo laptop, ma poi un giorno provi ad accedere da un dispositivo mobile che non avrà un tasto di tabulazione o i caratteri speciali non stampabili che hai inserito e sei bloccato. Ecco perché suggerisco di mantenerlo semplice: consentire di più solo porta a più problemi, con poca sicurezza aggiuntiva.
@this.lau_: Ho la "tastiera hacker" sui miei dispositivi Android proprio per questo motivo!
Allora che ne dici di qualcuno che salva la propria password che include un carattere di tabulazione in un file di testo? Quindi inseriscono il file in un terminale e la scheda diventa spazi. Non possono accedere e contattare l'assistenza, sprecare il loro tempo, dicendo loro che hanno copiato e incollato la password in modo che siano sicuri che sia corretta. Ancora una volta sprecato denaro e tempo e quasi nessuna sicurezza aggiuntiva. Ovviamente non ci piace che gli utenti salvano la password in file di testo, ma succede (specialmente quando il sistema super sicuro impone una modifica della password ogni due giorni).
"e una lunghezza massima di" sanità mentale "in modo che qualcuno non assorba 1 MB di larghezza di banda", a destra: http://www.cvedetails.com/cve/CVE-2013-1443/
Probabilmente non dovresti consentire il carattere di controllo nullo, poiché a) non puoi inserirlo in Chrome eb) Postgres solleverà un'eccezione
_e il tempo della CPU corrispondente per eseguire l'hash dell'input perché usi un algoritmo lento, giusto? _ I KDF lenti non diventano più lenti se l'input è grande.PBKDF2, ad esempio, pre-hash una password di grandi dimensioni con un hash veloce prima di eseguire l'HMAC iterato lentamente su di essa.L'algoritmo bcrypt accetta solo una password fino a 72 byte, quindi le password più grandi vengono solitamente sottoposte ad hashing con un algoritmo veloce.Argon2 utilizza BLAKE2 per questo.
Come ci si può aspettare che un utente annoti la propria password su un postit, se contiene spazi bianchi ?!Follia!
I servizi di timesharing CALL / 360 di IBM consentivano anche ** backspace ** nelle password.Aveva lo scopo di aggiungere sicurezza durante l'accesso su terminali che stampavano ciò che hai digitato.
mgjk
2013-03-15 21:31:15 UTC
view on stackexchange narkive permalink

Gli spazi iniziali e finali potrebbero essere un problema per le persone che sono libere di copiare e incollare. Altrimenti, d'accordo con gli altri post, nessuna buona ragione.

Tuttavia, quali altri caratteri stiamo bloccando? tab, cr, lf, backspace, beep ☻☺ ♪ ▬ ♣. ?

Non sarebbe difficile ignorare gli spazi iniziali e finali se questo è un problema.
Scommetto che qualunque linguaggio di elaborazione della pagina abbia funzioni di libreria standard per tagliare i caratteri di spazi bianchi iniziali e finali.
Sì, questa è la mia ipotesi. Non posso dirti quanti problemi ho avuto con gli spazi iniziali e finali con URL inseriti dall'utente sul sito che gestisco.
ewanm89- Se si rimuove lo spazio bianco dietro le quinte invece che in primo piano per le password, si verificano problemi con i casi in cui lo spazio bianco era intenzionale. Certo, questo probabilmente accade molto, molto raramente.
@AndrewStevens Ma anche se fosse stato aggiunto intenzionalmente, l'utente probabilmente non noterebbe che lo spazio vuoto viene rimosso dietro le quinte (a condizione che venga rimosso ogni volta che viene inserito, e non solo quando viene creata la password).
@PeterOlson Cosa succede all'utente la cui password è "_ _ _ _ _ _ _ _ password _ _ _ _ _ _ _ _ _ _"?
@Kevin Se rimuovi gli spazi, quella password non è distinguibile dalla password "password".
@PeterOlson: Immagino di non aver fatto bene il mio punto (legittimo colpa mia - scusa = P) Quello che volevo dire era, non penso che sarebbe bene che un utente conti su uno spazio vuoto finale per rendere la sua password lunga, ma non viene detto quando lo spazio bianco viene rimosso. Significa che la password dell'utente è potenzialmente molto meno sicura, ma l'utente non ne ha idea.
@Kevin, Penso che questo sia più un problema di UX, se noti al momento della creazione che ci sono spazi finali in una password, avverti l'utente che questo non è raccomandato. Non impedirgli di farlo, ma digli che la loro password non sarà così sicura.
Un altro motivo per eliminare almeno lo spazio finale: sulle tastiere morbide del telefono / tablet, è molto facile ottenere uno spazio aggiuntivo dopo il nome utente e / o la password.
user10211
2013-03-15 21:17:00 UTC
view on stackexchange narkive permalink

La semplice risposta è che si tratta di una cattiva politica per le password.

Non riesco a pensare a una ragione particolarmente valida per vietare il carattere spazio. Questo è probabilmente solo un requisito arbitrario stabilito da una persona ben intenzionata ma sbagliata.

AJ Henderson
2013-03-15 21:16:38 UTC
view on stackexchange narkive permalink

Non riesco a pensare a nessun motivo di sicurezza valido diverso dal fatto che scoraggia le persone dall'usare frasi reali come password che sarebbero molto insicure se avessero un significato reale. A rigor di termini, non c'è nulla di insicuro in uno spazio in una password se mantiene una buona entropia, quindi le persone "creative" sono l'unica cosa reale che posso vedere.

Potrebbe anche esserci un problema di usabilità che gli spazi sono difficili da verificare visivamente, assicurati di aver digitato correttamente se la password viene visualizzata in modo visibile. (È uno spazio o 4, concesso se appare un * s, allora è facilmente numerabile.)

Le frasi per le password non sono poi così insicure, ci sono più modi possibili per mettere insieme 5 parole da un dizionario di ~ 250.000 parole rispetto a 5 caratteri da un set di caratteri di 128 caratteri (ASCII). Anche se scegliamo solo combinazioni di parole che hanno significato rispetto a caratteri individuali casuali, sembra che ci sia più entropia, il problema è che alcune frasi sono probabilmente più comuni di altre è anche un problema con le stringhe di caratteri usate come password. Infine rifiutare lo spazio non interrompe l'uso di una frase, ma non mettere gli spazi tra le parole.
@ewanm89 - Hai ragione sul fatto che le parole casuali non sono insicure, ma le persone tenderebbero a creare frasi significative come "questa è la mia password" che non sono sicure in alcun modo. Inoltre non sto dicendo che sia una BUONA ragione. Sto solo dicendo che potrebbe essere un motivo. Personalmente, non bloccherei gli spazi.
sì, ma non è diverso dalle persone che usano la password come password ... si applicano gli stessi problemi, le frasi sono più facili da ricordare e possono avere significati molto diversi con un numero maggiore di possibilità usare il più comune in entrambi i casi è sempre un male perché sarà il primo che l'attaccante proverà.
@ewanm89 In realtà, è molto diverso dall'utilizzo di "password". "Questa è la mia password" è infatti molto più sicuro di "password". Inoltre, se richiede numeri e caratteri speciali, è probabile che finirai con "1his is my p@ssword", che è almeno più sicuro di "p@ssw0rd". Infine, questo è probabilmente piuttosto istruttivo: http://xkcd.com/936/
@PatrickM - la graffetta della batteria del cavallo funziona perché sono parole casuali. Le frasi non aggiungono molto perché ci sono abbastanza poche opzioni su come si connettono. Non sto dicendo che non aggiungono nulla, ma possono effettivamente essere distruttivi rispetto a una password non inglese ben selezionata che è molto più breve.
@PatrickM che dipenderebbe se l'aggressore sapesse che stai usando una frase o meno. Se un utente malintenzionato disponeva di un dizionario delle frasi più comunemente usate, è lo stesso di un dizionario delle password più comunemente utilizzate.
Ovviamente in tutti i casi stringhe casuali di parole o caratteri prive di senso di lunghezza sufficiente sono più sicure di quelle non casuali. ma con i personaggi anche le persone li danno senso, e ci sono meno combinazioni che hanno senso. dopotutto sono suono consonante, suono consonante suono vocale, suono vocale foneticamente. Ci sono meno modi per collegare una stringa per creare una parola memorabile, soprattutto perché tendiamo a imparare a leggere / scrivere foneticamente.
@AJHenderson Sì, può essere peggio di una parola inglese "ben selezionata", ma se hai bisogno di una politica per le password, stai assumendo che la maggior parte degli utenti non "selezionerà bene" la propria password. Fondamentalmente, la mia affermazione è che una frase selezionata male è quasi sempre meglio di una password altrettanto male selezionata. Ad esempio, le persone spesso scelgono ciò che hanno davanti per la loro password. Quindi, potrei scegliere "cavallo" o "Su un cavallo pallido". (Un libro che era casualmente di fronte a me) Ora, ammetto che quella frase è una pessima password, ma quella frase è spesso MIGLIORE di una parola equivalente mal selezionata.
Fondamentalmente, in un mondo perfetto le persone sceglierebbero buone password, ma spingere qualcuno da una frase selezionata male a una parola selezionata male è un errore. (Sto ignorando i requisiti relativi a numeri e simboli, perché l'aggiunta di numeri e simboli a una parola di solito non la migliora più dell'aggiunta di numeri e simboli a una frase)
Non sono sicuro di essere d'accordo sul fatto che le parole con spazi siano meno sicure delle parole senza spazi. Se la regola "nessuno spazio" è nota, qualsiasi tentativo che si sarebbe verificato utilizzando frasi con spazi verrebbe eseguito solo senza spazi. A meno che tu non stia contando su un attaccante che non controlla le regole della password prima di lanciare un attacco, immagino ...
Quindi, per riassumere questi commenti: "I'm a little teapot" (entropy 4 ^ 250k) è meglio di "teapot" (6 ^ 26) ma forse peggio di "T3@p0t45" (8 ^ 128) perché è un * molto * frase ben nota. Sicuramente non è peggio (e forse leggermente migliore) di "I'malittleteapot" (anche 4 ^ 250k), ma "mi piace molto bere il tè, soprattutto se è da una teiera di alta qualità". è migliore di tutte le altre, con 13 parole più 3 segni di punteggiatura (virgola, trattino e punto - l'apostrofo in "è" non si aggiunge all'entropia) - quindi 16 ^ 250k, e sebbene abbia un significato, non lo è una frase particolarmente comune.
@DanHenderson - No, i tuoi calcoli di entropia non sono corretti perché non sono parole selezionate a caso. Le frasi significative hanno molte strutture che riducono drasticamente l'entropia effettiva. I calcoli semplicemente dell'entropia sono validi solo per scelte veramente casuali. Ad esempio, se hai "Sono un po '........", allora ci sono molte meno di 250.000 parole che probabilmente riempiranno quel punto. A meno che non sia puramente casuale, non è semplice entropia. Inoltre, come il tuo cognome ... :)
@PatrickM - Non sono in disaccordo, probabilmente è una cattiva politica. Tuttavia, se qualcuno sceglie una parola semplice, sa che è insicuro. Se pronunciano una frase, potrebbero pensare che sia più sicura senza esserlo effettivamente. Suppongo che la speranza sarebbe che non permettendogli di essere "intelligenti" potrebbero effettivamente creare una password sicura, ma non è nemmeno un'idea particolarmente buona poiché potrebbero semplicemente eliminare gli spazi.
@AJHenderson beh, per lo stesso motivo, "teiera" non è realmente 6 ^ 26 per lo stesso motivo - ci sono solo circa 10 lettere che seguirebbero logicamente l'iniziale ** t ** (incluso ** v **), e forse solo una lettera a seguire "teapo". Tuttavia, proprio come un attaccante non * sa * che hai usato "teiera" senza maiuscole e devi quindi includere "Alpha" e "aLPhA" e "a! 3h ^" nel suo attacco, e decidere quale di questi viene prima di "teiera "influisce sulla forza effettiva di" teiera ", inoltre non * sa * che non hai usato" fiocco batteria a cavallo "e deve decidere se le frasi senza senso di 3 parole debbano
... essere provato prima di frasi significative di 4 parole.
@DanHenderson - in effetti, la frase di 4 parole è sicuramente più sicura di una sola parola in termini di indovinare. Il rischio è che la maggior parte delle persone si accorga che la "teiera" non è sicura, ma potrebbero non rendersi conto che "sono un po 'bassa e robusta" in realtà non è molto più sicura. Dare a qualcuno l'illusione della sicurezza può essere molto pericoloso dal punto di vista dell'utente. Detto questo, non credo che una politica "nessuno spazio" faccia molto per ottenere ciò, ma è letteralmente l'unica ragione per cui mi viene in mente che qualcuno potrebbe cercare di limitarla. Purtroppo una politica inefficace ma ben intenzionata è comune
sharp12345
2013-03-17 07:40:20 UTC
view on stackexchange narkive permalink

È un'ottima norma per praticità e, avendo visto questo dal lato dell'assistenza clienti, penso che dovrebbe essere implementata ovunque.

Puoi scrivere la password in questo modo: "abc def ghi" e copialo su un pezzo di carta o copia e incolla.

È semplicemente più facile eliminare tutti gli spazi che continuare a dire a tutti:

  • "Assicurati di non copiano e incollano alcun carattere di spazio bianco "
  • " Digita la password manualmente, non copiarla e incollarla "

Che di solito è una risposta alla domanda:

  • "La mia password non funziona, anche se l'ho copiata esattamente dall'email che mi hai inviato"
Oppure potrebbe semplicemente essere scritto come "abc def ghi" ...
Ci sono due grossi difetti in questo. Prima di tutto, se gli spazi sono un tale problema, puoi semplicemente spogliarli dietro le quinte prima di eseguire l'hashing della password e quando l'utente accede. Secondo, se stai inviando la password a qualcuno, hai problemi più grandi degli spazi. Inoltre, l'eliminazione degli spazi per conto dell'utente prima dell'hashing e all'accesso si occupa anche del problema del copia-incolla.
Se devi fornire la password iniziale al cliente, generane una senza spazi per evitare problemi che hai menzionato.Ma il cliente dovrebbe essere in grado di cambiare questa password iniziale con un'altra che contenga spazi.
jordan
2013-03-16 02:55:58 UTC
view on stackexchange narkive permalink

si tratta solo di semantica programmatica. quasi tutto gestisce il carattere spazio "" o "" in modo diverso da altri simboli come "a" o "dds".

il carattere spazio vuoto viene raggruppato in altri caratteri strani come le nuove righe - "\ n" o caratteri vuoti - ""

Inoltre non è univoco, poiché alcuni caratteri speciali su determinati ambienti di computer non hanno una rappresentazione e vengono analizzati in un carattere vuoto ""

In alcuni ambienti di computer in cui passavamo file avanti e indietro da MAc a Windows a Linux, a volte ci siamo ritrovati con ('' == '') per produrre un risultato FALSO (il segno di doppio uguale indica semplicemente un operatore di confronto). Era falso perché c'erano simboli nascosti esistenti nello spazio che non potevamo vedere a causa delle diverse culture dei computer nel nostro team.

Non sono sicuro che questo problema si sarebbe mai verificato quando si parlavano di password rigorose , ma non avere spazi in aree speciali come password e nomi di funzioni e nomi di file è decisamente il modo migliore per andare sempre. L'analisi degli spazi nei nomi dei file è una storia completamente diversa, con alcuni programmi che aggiungono un% a uno spazio per rimuovere lo spazio in modo che il nome sia il nome%

Tutto ciò che hai menzionato è strettamente un problema di codifica, che non dovrebbe avere un impatto su un sistema di hashing delle password adeguatamente progettato.
vabbè, aggiungo solo altro materiale di lettura alla base di conoscenza comune.
La risposta di Jordan è almeno rilevante. Problemi con gli spazi come quelli che ha menzionato potrebbero aver contribuito alla costruzione del paradigma "nessun spazio nelle password" / "gli spazi possono essere problematici". Anche se gli spazi non dovrebbero influenzare i sistemi di hashing delle password progettati correttamente, la loro tendenza a causare bug in altro codice potrebbe aver spaventato alcune persone a vietare gli spazi dalle password sui loro siti.
Cristian Lupascu
2013-03-20 15:15:34 UTC
view on stackexchange narkive permalink

Sulla maggior parte delle tastiere, il tasto Spazio emette un suono leggermente diverso da quello di qualsiasi altro tasto.

Considera lo scenario in cui una persona sente qualcun altro digitare la propria password.

Se quella persona è in grado di capire che la password è composta, ad esempio, da 3 caratteri + uno spazio + 4 caratteri, questo potrebbe essere un suggerimento molto utile in alcuni casi.

Lo stesso argomento in molti casi potrebbe valere anche per molti altri tipi di caratteri non alfanumerici, in particolare quelli accentati, così come l'uso di lettere maiuscole e minuscole (poiché le pressioni dei tasti suonano diverse dai comunicati, la stampa da comunicato stampa).
laurent
2013-03-16 10:36:37 UTC
view on stackexchange narkive permalink

Mi vengono in mente diversi motivi per cui gli spazi dovrebbero essere esclusi; queste ragioni non hanno nulla a che fare con la sicurezza, ma con l'usabilità:

  • Se trasmetti una password che contiene spazi, come fa il destinatario a sapere che è uno spazio o una scheda? Ed è uno o due spazi? Supponendo che tu debba scriverlo a mano (succede), come mostrare queste informazioni? A seconda del tipo di carattere del loro client di posta, c'è anche la possibilità che non notino gli spazi vuoti.

  • Di nuovo, quando si invia la password, se gli spazi sono all'inizio o alla fine, ci mancherà facilmente e dovrà essere racchiuso tra virgolette. Ma anche così sembrerà strano e posso facilmente immaginare che gli utenti non includano questo ultimo spazio e non siano in grado di accedere.

  • I caratteri vuoti (nuove righe, tabulazioni, spazi) vengono spesso tagliati dalla fine e dall'inizio di un campo, per evitare che le persone copino e incollino dati errati. Ovviamente se gli spazi fossero significativi, ciò causerebbe un problema.

Tutto sommato, penso che non avere spazi eviti tutti i tipi di problemi e le chiamate di supporto salvate, quindi è una buona cosa.

Modifica:

Per rispondere ai commenti sulla cattiva pratica di condividere le password:

Diciamo affari importanti i documenti sono bloccati sulla stazione di Bob, che è attualmente in vacanza. Cosa fare in questo caso? Aspettare che Bob torni due settimane dopo e nel frattempo perda potenziali affari? O semplicemente chiedergli di inviare la password? Sicuramente è un male, ma comunque meglio dell'alternativa.

Come disse Linus Torvald (a proposito di qualcos'altro, ma mi piace lo spirito): "dovresti occuparti della realtà , non quello che vorresti fosse la realtà ".

Ebbene, inviare le password in chiaro è una cattiva idea.
1) Come accennato, inviare password in chiaro è una cattiva idea. Se l'utente decide di inserire uno spazio e poi prova a dire a qualcuno qual è la sua password, questo è il suo problema. Se questo è per il recupero della password, interrompi la memorizzazione delle password in testo normale e consenti agli utenti di reimpostare la password. 2) Se non stai citando / eludendo correttamente le password dei tuoi utenti, ti meriti il ​​problema che ti aspetta. 3) Se la password viene tagliata in modo coerente, è importante? Dopotutto, se ogni dialogo di immissione della password taglia gli spazi, non avrà molto effetto che l'utente può vedere.
Penso che tu stia perdendo il punto, sono uno sviluppatore, ho hash delle password, non le invio via e-mail, conosco la buona pratica, ma non è questo il punto. A volte le password vengono inviate via e-mail, per telefono, scritte su fogli, ecc. È tutto sbagliato, ok. Ma come sviluppatore, lo renderemmo ancora più sbagliato consentendo spazi nelle password. Sarebbero potenzialmente ore di chiamate / e-mail di supporto sprecate per una funzione inutile.
Non lo compro. Se qualcuno sceglie di utilizzare uno spazio nella propria password, può facilmente dire a qualcuno di badare allo spazio. Secondo la tua logica, anche le lettere maiuscole dovrebbero essere vietate. Uso gli spazi nelle mie password ogni volta che posso e ho condiviso le password tramite e-mail o verbalmente molte volte. Quello che faccio sempre è dire "la password è 'La mia password' - fai attenzione alle lettere maiuscole e agli spazi tra le parole". Non è mai stato un problema.
La digitazione e la grafia hanno tutte convenzioni per la comunicazione degli spazi (e anche di altri caratteri di spazio).E secondo questa logica, anche la I maiuscola e la l minuscola dovrebbero essere evitate.Per questo caso d'uso molto ristretto, si potrebbe scegliere di non utilizzare gli spazi.Non hai dimostrato di impedirne sistematicamente l'uso.
user11717468
2019-07-03 13:13:51 UTC
view on stackexchange narkive permalink

Credo che la maggior parte dei non programmatori ritenga (consapevolmente o meno) che il carattere spazio sia essenzialmente diverso dagli altri caratteri in quanto serve solo a separare le parole l'una dall'altra; essendo solo metadati invece di dati.

Questa sensazione è rafforzata dal fatto che non vi è alcun suono corrispondente al carattere dello spazio. La maggior parte delle persone ricorda le proprie password in forma pronunciata (come suonano quando pronunciate ad alta voce) invece che in forma visiva (come appaiono quando scritte).

Pertanto inconsciamente considererebbero "La mia password", "La mia Password "e" MyPassword "devono essere uguali perché sono pronunciate allo stesso modo e possono facilmente vedere (grazie per la" P "maiuscola) dove finisce una parola e inizia la successiva, anche senza spazi. Naturalmente, se chiedessi loro se quei tre sono la stessa cosa, solleveresti la questione dall'inconscio alla mente conscia e tutti risponderebbero "no". Ma fintanto che nessuno fa la domanda ...

Quindi il problema nel consentire spazi nelle password è pratico: aiuta gli utenti a dimenticare le loro password, cioè li aiuta a dimenticare se c'era uno spazio (o due o tre o ...) nella password oppure no.

_È essenzialmente diverso_ Il termine per questo è (non sorprende) ** spazi bianchi **.
Steve Warnek
2018-03-28 04:16:56 UTC
view on stackexchange narkive permalink

Qualificherò questo commento dicendo che sono un amministratore di sistema da oltre trent'anni ... e uno scrittore per almeno il tempo.

Anche se l'uso di uno spazio in una password può essere consentito in alcuni ambienti, e potrebbe essere più sicuro nel senso che hai un set di caratteri più ampio per rafforzare la tua password con ... stai chiedendo guai in questo modo. Uno spazio non è solo un carattere, è una rappresentazione di uno spazio nullo, proprio come uno zero rappresenta un'assenza di valore numerico. Alla fine arriverà il giorno in cui "dimenticherai" lo spazio e ti tirerai fuori i capelli chiedendoti perché la tua password di root non funziona più e devi ricaricare il tuo server da zero. Dal punto di vista dell'usabilità - dico di stare lontano dallo spazio ... è una di quelle "regole non scritte" a cui puoi dare cento motivi per non obbedire ma la tua vita sarà facilitata dall'aderenza. In trent'anni ho incontrato solo una persona che ha usato uno spazio in una password ed è stato un inferno cercare di capirlo. Altri non saranno d'accordo - e questa è la loro prerogativa. Non userei mai uno spazio.

Un carattere spazio non rappresenta "spazio nullo".Al di fuori di alcune rappresentazioni Unicode, è solo una stringa di otto bit, come lo sono lettere e numeri.Inoltre, uno zero non è un'assenza di valore numerico;è un segnaposto che ha un significato.Se dubiti di questo, sostituisci binario tutte le "10000000" x con "00000001" x in uno dei tuoi eseguibili e guarda cosa succede.:)
È il 2018. Abbiamo Unicode 10.0 contenente 1.114.112 grafemi enumerati.Di questi, 136.690 sono assegnati e nominati.Sono 17,061 bit di entropia per simbolo (che potrebbero essere usati).È tempo che l'industria tenga il passo con la tecnologia e smetta di rigurgitare le politiche degli ultimi 3 decenni.Potrebbero esserci state ragioni molto pratiche e tecniche per proibire il codepoint 32 UTF-8, ma ora non esistono.Per creare una passphrase, gli utenti dovrebbero essere liberi di utilizzare * qualsiasi * punto di codice Unicode;risultante in una chiave di crittografia salata, con hash, allungata (o ruotata).


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...