I nomi utente dovrebbero essere tenuti segreti?

Saggezza convenzionale re: Attacco o enumerazione forza bruta

Ci sono alcuni modi per vederlo. Uno dovrebbe iniziare con link prima di provare a pensarci davvero, però.

Esistono vari gradi di divulgazione delle password. Il mio username su Slashdot è conosciuto da tutti coloro che leggono un mio post. Il mio nome utente al lavoro può essere visualizzato da tutti in ufficio, e ugualmente discernuto da chiunque conosca il mio indirizzo email. Nessuno dovrebbe conoscere il mio numero di conto bancario (che è il nome utente per il mio banking online).

In ciascuna di queste situazioni, il vantaggio di affermare esplicitamente che il nome utente non è valido o che la password non è valida è limitato. Ora, in quello scenario: se sei su Slashdot, sai che l'account è lì per sempre così puoi capirlo a prescindere. Se stai attaccando il mio lavoro, questo può dare se sono ancora occupato. Contro i miei conti bancari o di carte di credito, questo è l'unico modo per enumerare gli account. Fornisce un obiettivo chiaro.

Sono dell'opinione che, dal momento che riconoscere l'uno o l'altro abbia un valore limitato per i sistemi pubblici e possa trapelare informazioni su quelle private, l'autenticazione della password dovrebbe sempre avere la forma "fai corrispondere username e password?" Questa è una domanda T / F senza passaggi intermedi.

New Age Wisdom re: Phishing

Un utente accede a un sito Web, che potrebbe essere il sito Web sbagliato. Inseriscono le credenziali di accesso senza prestare attenzione all'URL (o forse ottengono realmente lo spoofing) e il loro account è compromesso. Le banche hanno affrontato questo problema rendendo l'autenticazione un processo a più fasi. A questa idea, il questionario originale menziona la visualizzazione di una serie di foto se il nome utente è corretto. Contro: SEMPRE fare in modo che il processo di autenticazione segua tutti i passaggi. jonjacob (jinkleheimerschmidt) potrebbe non essere un login valido, ma dovresti comunque visualizzare una serie di foto e chiedere una password. Ciò ti consente di limitare il rischio di perdite di informazioni e di tentare ancora di impedire che il phishing comprometta un account utente.

Rischio v. Premio

La saggezza convenzionale sui nomi utente e le password di cui sopra è semplice e gradevole ai più, credo. Il phishing è una nuova variabile e affrontare questo cambierà la situazione di alcuni sistemi. Ci sono risposte alla tua domanda che potrebbero non essere discusse qui, o addirittura pensate ancora. Credo comunque che dovresti essere in grado di impedire a qualcuno di enumerare gli account in qualsiasi situazione.

Se gli utenti hanno password complesse o usi una sicurezza aggiuntiva come token per forzare la complessità di un attacco a un livello "ragionevole", l'aspetto crittografico dovrebbe essere coperto. Tuttavia, c'è l'aspetto della privacy da considerare: ad alcune persone non piace qualcuno per capire qualsiasi su di loro. Ricorda che non puoi soddisfare la ogni minoranza e progettare in base ai requisiti aziendali e della comunità.

Citazione obbligatoria: " La sicurezza è sempre un compromesso "

Il suggerimento di mantenere i nomi utente segreti sembra assurdo.

È inevitabile che tu abbia bisogno di un modo per identificare un utente in un modo che non comprometta la sicurezza di un account. Come funzionerebbe la posta elettronica se il tuo indirizzo email fosse il token di autenticazione? Se riscontro problemi nell'utilizzo di alcuni software, come faccio a comunicare all'helpdesk a quale account si riferisce?

it enables you to dos a site by locking all the accounts where account lockout is enabled

Ti permetterebbe anche di accedere a un sistema in cui non esisteva una password separata - rivelare che il nome utente non è il problema, ma piuttosto l'implementazione delle regole di blocco.

Users like to use the same username and password

OK, concederò questo. Ma non giustifica il postulato. Gli utenti sono stupidi. Farsene una ragione. Se vuoi che pensino che il tuo sito sia sicuro, ci sono molte ricerche per dimostrare che la creazione di una grande immagine di un lucchetto funziona meglio rispetto all'utilizzo di SSL. Se stai provando a utilizzare i token di autenticazione secondari implementati tramite partial (come in "seleziona le 3 e le 8 cifre dal tuo pin), inserisci una casella di testo e chiedigli di fornire il tutto.

Publicly known facts, such as mobile and e-mail, do not count towards authentication strength

? ma i numeri di cellulare e gli indirizzi email sono nomi utente !!!!!!!!

Le password non sono una soluzione completa per ambienti ad alta sicurezza. Ma provare a usare un nome utente come autenticatore non aiuta a migliorare la sicurezza e compromette altre cose.

Ero solito fare un mix di sicurezza.

Ad esempio, per l'account di posta dell'utente:

• ID: [email protected]
• PASSWD: 1z "1dgG" @ "é ~ #.

Per l'account utente sulla intranet, è così:

• ID: 1501823098 (di solito utilizzo un proprio ID dalla loro carta d'identità, o genero quell'ID se non posso fare diversamente.)
• PASSWD: # \ ed "1:!) 3qs

Il problema di far conoscere agli utenti l'account utente su intranet (o internet) è che qualsiasi hacker proverà a forzare il login. Anche se la password è complessa, l'attacco del dizionario e la forza bruta avranno un impatto sulla tua connessione, la riduzione della larghezza di banda e così via.

Anche avere solo una politica sull'account utente e sulla password per l'intera applicazione intranet / internet è come correre con solo il casco del pane contro un tornado. Puoi sopravvivere ma è come un suicidio!

Anche se l'utente si lamenterà perché deve apprendere 3 diversi ID account e 3 password diverse, il tuo lavoro sarà molto più semplice, perché sarà semplice isolare 1 account che viene violato e l'utente dopo alcuni settimane, adattati a questa politica, e avrai una roccastrong davvero ben protetta.

Beh, almeno questo è quello che ho fatto nel mio lavoro. Anche ora, a volte gli utenti tendono a dimenticare il loro ID o password, oa scriverli, ma questo è il loro problema, ho fatto il mio lavoro per garantire una buona politica di sicurezza. (Puoi dare loro il loro ID o reimpostare la loro password se li hanno persi.)

Spero che questo ti possa aiutare.

EDIT:

Your real control against this is password length, complexity and account lockout policy

Avere una buona lunghezza della password con la complessità ha un grosso difetto, dizionario. Uso (per me stesso) una password con una complessità elevata e una lunghezza di 26 caratteri. Anche se il dizionario non lo trova immediatamente, consumerà un sacco di processi di rete. E avere una politica di blocco degli account è una buona idea, ma quando l'account è bloccato, lo script di forza bruta proverà un altro account e procederà in questo modo. Anche se almeno l'account è sicuro, la rete perderà molta larghezza di banda e, nel peggiore dei casi, tutto il tuo account sarà rotto e potresti persino avere un blackout di rete globale.

You can mitigate this by having auto unlock after period of time (e.g. 5 - 30 mins), have a mass unlock function, have exponential back-off or IP banning for a period of time after a number of bad attempts, selective anti-automation controls (e.g. Captcha, Roboo script) displayed after a number of failed attempts

Lì, il difetto è l'utente. Beh, l'utente è sempre un difetto in IT, ma prova a immaginare un utente, che dopo 3 settimane di vacanza (Happen nel mio lavoro con la mia N + 2 ... storia vera) ha dimenticato la sua password, proverà a bloccarlo conto, aspetta, riprova, blocca di nuovo, dopo 2 tentativi ti corre incontro come un mongolo che invade l'Europa! Dovrai disabilitare questa regola per lui, ma si spargerà la voce che hai fatto un'eccezione e altri utenti vorranno che tu faccia lo stesso per loro. Nel peggiore dei casi, l'utente non verrà da te, ma utilizzerà l'account di uno dei suoi colleghi (che annota ID e password e li custodisce in modo prezioso sotto il bloc della scrivania).

User education, a second authentication factor, adaptive authentication (e.g. step-up or graduated authentication based on device ID, location etc) would be better defenses against this

Bene, sono completamente d'accordo con te su questo punto. Eseguo regolarmente la formazione degli utenti in merito alla politica di sicurezza, solo per essere sicuro che non dimentichino la posta in gioco e addestrare il nuovo commer. Ma dovrebbe essere normalmente in ogni azienda.

I see username and identity and password as authentication. If you want a stronger authentication make the password longer or require 2 passwords. Leave identification alone

L'identificazione è puramente utente / amica dell'amministratore. Se si desidera rafforzare la sicurezza, rendere la password più lunga o richiedere 2 password ostacolerà solo l'hacker. Il vero modo (almeno per me) di rafforzare la tua politica, è quello di aggiornare la crittografia (hash md5, RSA, ecc ...). La mia N + 2 pensava che fosse inutile, ma dopo una perdita critica sui nostri server di sicurezza, non la pensa più così (la perdita è stata colpa sua, fai riferimento alla seconda risposta per capire ...). Penso che con la sicurezza non si possa mai fare attenzione.

Dopo è solo il punto di vista. Alcuni potrebbero dire che i tuoi colleghi hanno ragione, altri potrebbero dire che hai ragione, per me penso che entrambe le parti abbiano ragione, tu e il tuo collega avete bisogno di trovare un compromesso con cui lavorare.

Spero che questo abbia risposto alle tue domande.

La semplice risposta sta dando via il nome utente rende la tua applicazione meno sicura.

Qualsiasi argomento sull'aumento della sicurezza di altri fattori di autenticazione è una falsa pista.

Qualunque cosa tu faccia per migliorare ulteriormente la sicurezza degli altri fattori potrebbe anche essere fatto mantenendo il nome utente nascosto. Se questa applicazione ha davvero un impatto elevato, implementerai tutte le contromisure a cui puoi pensare se la sicurezza del nome utente è concessa o meno alla porta.

Sì. La sicurezza generale è un equilibrio e solo misurando i costi di supporto effettivi puoi vedere se regalare il nome utente vale il rischio percepito o calcolato per la tua reputazione e il tuo budget.

La vera domanda è perché dovresti sostenere tutti i costi di ingegneria per mantenere un campo username per poi memorizzarlo in un cookie o altrimenti dare via quel fattore di autenticazione.