I nomi utente dovrebbero essere tenuti segreti?

37

Aiutami a sistemare una discussione tra colleghi e guida il design futuro:

Anche in uno scenario ad alto impatto: ad es. proteggere l'applicazione di pagamento o il gateway governativo ma in un'applicazione accessibile a Internet

Vale la pena implementare una delle seguenti (o altre) misure per proteggere un nome utente:

  • Richiedere un nome utente generato dal sistema complesso come gateway governativo del Regno Unito o HSBC on-line banking ? È il compromesso in termini di utenti che dimenticano questo, che hanno bisogno di annotarlo, il traffico del call center aggiuntivo, gli utenti che hanno un promemoria del nome utente self-service utile rispetto al rischio di utilizzare un nome utente pubblico come l'indirizzo e-mail o il numero di cellulare? p>

  • Fornire un messaggio generico: "il tuo nome utente o password non erano corretti" invece di più user friendly "il tuo nome utente non è stato riconosciuto" e "la tua password non era corretta"

  • Utilizzo del seguente tipo di sequenza di accesso in cui è utilizzata una pass-frase personale per la chiave del sito o utente per l'identificazione dei siti di phishing:

    • Inserisci nome utente e valore segreto semplice (ad es. codice postale)
    • Se non validi, viene fornito un errore: nome utente o valore errati
    • Se sono validi, viene visualizzata l'immagine personale del sito chiave dell'utente e viene richiesta la password
    • Se la password non è valida, messaggio di errore password errata
    • Se è concesso un accesso valido

Contrariamente al modo più amichevole su dire Quora.com in cui ti viene mostrata la tua immagine sulla voce corretta del nome utente. È accettabile solo su Q & A site? A basso rischio?

I miei colleghi sostengono che mantenere i nomi utente segreti e le misure del tipo sopra riportate:

  1. L'enumerazione del nome utente di massa consente di provare i tentativi di dizionario e bruteforce contro un sito
  2. ti consente di dosare un sito bloccando tutti gli account in cui il blocco degli account è abilitato
  3. Gli utenti preferiscono utilizzare lo stesso nome utente e password tra i siti e molti siti utilizzano l'indirizzo di posta elettronica e il numero di cellulare per i loro siti. Se gli utenti condividono le credenziali tra siti, le credenziali potrebbero essere rubate o utilizzate dagli altri siti e quindi utilizzate per accedere al sito
  4. I fatti noti pubblicamente, come il cellulare e la posta elettronica, non contano per la forza dell'autenticazione. Se il nome utente è un fatto noto, per mantenere lo stesso livello di sicurezza la password deve essere significativamente più strong per compensare la differenza statistica, ad es. se username e password hanno entrambi un minimo di 6 caratteri, supponendo 52 possibili caratteri abbiamo 52 ^ 12 combinazioni. Tuttavia, se il nome utente è un fatto noto, allora diventa solo 52 ^ 6 combinazioni; devi aumentare la password di almeno 12 caratteri per ottenere lo stesso livello di protezione: l'impossibilità di farlo aumenterebbe il rischio di acquisizione dell'account.

I counter per each:

  1. Il tuo reale controllo su questo è la lunghezza della password, la complessità e il criterio di blocco dell'account
  2. Puoi mitigare ciò avendo lo sblocco automatico dopo un periodo di tempo (ad es. 5 - 30 minuti), una funzione di sblocco di massa, un esponenziale di back-off o un bando IP per un periodo di tempo dopo un numero di tentativi errati, selettivo controlli anti-automazione (es. Captcha, script Roboo) visualizzati dopo un numero di tentativi falliti
  3. La formazione degli utenti, un secondo fattore di autenticazione, l'autenticazione adattiva (ad es. step-up o autenticazione graduata basata su ID dispositivo, posizione, ecc.) sarebbero migliori difese contro questo
  4. Vedo il nome utente come identità e password come autenticazione. Se si desidera un'autenticazione più strong, rendere la password più lunga o richiedere 2 password: lasciare solo l'identificazione

Felice di imparare e cambiare la mia posizione. Grazie in anticipo.

    
posta Rakkhi 23.06.2011 - 15:46
fonte

5 risposte

12

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.

    
risposta data 23.06.2011 - 18:40
fonte
5

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 "

    
risposta data 23.06.2011 - 16:09
fonte
4

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.

    
risposta data 23.06.2011 - 18:25
fonte
0

Ero solito fare un mix di sicurezza.

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

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.

    
risposta data 23.06.2011 - 16:14
fonte
0

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.

    
risposta data 23.06.2011 - 17:47
fonte

Leggi altre domande sui tag