Questa sicurezza di accesso è sufficiente?

17

Sto arrivando con il mio prossimo sistema di accesso per gli amministratori di un sito di e-commerce, che avrà questo:

  • il modulo di accesso è protetto SSL
  • la password viene convertita in SHA-256 prima di essere trasmessa (bcrypt è ancora troppo lento per il client JS / browser)
  • bcrypt ha memorizzato gli hash (non voglio che il mio database venga mai rubato per essere facilmente rotto)
  • La password hash
  • è crittografata con la chiave privata memorizzata come costante nell'app o nel file
  • un hash di tutti i valori importanti del database di login per quell'utente, in modo che se vengono modificati tramite l'iniezione in qualche modo, l'hash non corrisponderà e l'account verrà bloccato
  • recaptcha al primo errore di accesso
  • sistema di attacco di accesso per dispositivo, quindi se l'utente prova 5 accessi diversi e sono tutti sbagliati, è fuori - non è 5 per accesso
  • auth passo secondo. utilizzando SMS, email o AlterEgo - forse una volta per dispositivo + posizione e da utilizzare se si desidera modificare la password
  • se accedi da una posizione diversa dalla cronologia, invia SMS o e-mail all'utente
  • se le informazioni sul dispositivo o sulla posizione cambiano durante l'accesso, uccidi la sessione (per impedire il furto della sessione)
  • consente di rimuovere la cronologia di accesso dei vecchi dispositivi (gli utenti possono rimuovere i dispositivi che non usano più)
  • avere l'opzione per salvare il dispositivo di accesso + la posizione nella cronologia (ad esempio, non utilizzare questa opzione se si è su un netcafe o su una rete pubblica, ecc.) quindi verrà sempre richiesto il secondo passaggio

Questa sicurezza di accesso è sufficiente? Pensi che stia andando alla grande?

    
posta kzap 21.06.2011 - 04:53
fonte

6 risposte

13

Attenzione ai rischi eccessivi, è controproducente. Se il tuo sistema di accesso è troppo scomodo o fastidioso, gli utenti cercheranno attivamente di aggirarlo. "Utenti", qui, include gli sviluppatori di applicazioni e gli amministratori dei server.

login form is SSL secured

Questo è il più importante, ma non "solo". Teoricamente, l'intero sito dovrebbe essere protetto con SSL, non solo il modulo di accesso. SSL fornisce riservatezza per quanto riguarda gli intercettatori, ma se risulta in un cookie che successivamente si invia in chiaro per mantenere la sessione, quindi un intercettatore deve semplicemente inviare lo stesso cookie per dirottare una sessione. Se solo il modulo di accesso è protetto da SSL, l'unica sicurezza che ottieni qui è associata a un approfondito addestramento anti-phishing: tu istruisci gli utenti ad astenersi dall'inviare la loro password a siti che non hanno SSL attivo, quindi è necessario un sito SSL da soli. Ma questo è marginale.

password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client)

Questo è inutile. Significa solo che il risultato SHA-256 è la password. Se può essere afferrato da un utente malintenzionato, l'utente malintenzionato può utilizzarlo per accedere senza nemmeno conoscere la "vera" password.

hashed password is encrypted with private key stored as CONSTANT in app/file

Questa funzione è un vantaggio per la sicurezza solo nella situazione in cui l'utente malintenzionato può ottenere le password con hash ma non i file dell'applicazione stessi. Se questa è una situazione realistica è discutibile. D'altra parte, quella chiave costante disturberà gli amministratori quando l'applicazione deve essere aggiornata, e potrebbe incorrere in tempi di inattività aggiuntivi (è così facile dimenticarlo durante la distribuzione ...). Inoltre, questo rende la riservatezza dei file dell'applicazione un obiettivo importante, che è piuttosto raro.

recaptcha upon 1st login failure

Questo sarà più fastidioso che sicuro.

login strike system per device, so if the user tries 5 diff logins and theyre all wrong, he's out. its not 5 per login

Non bloccare account, basta aggiungere ritardi (ad esempio un minuto). Altrimenti, chiunque può bloccare l'account di qualcuno, che è un problema. Il conteggio dei tentativi per dispositivo è buono, ma è sottile, e può ritorcersi contro: ci sono alcune reti (incluso ISP) là fuori con massiccia NAT o proxy, che trasformano dal punto di vista del server migliaia di richieste di accesso dalla stessa fonte IP.

2step auth using sms, email? or AlterEgo - maybe once per device + location and to be used if you want to change your password

if logging in from a different location different from history, send SMS/Email to user

Gli SMS possono infastidire gli utenti: non funzionano bene per gli utenti internazionali, richiedono un telefono cellulare funzionale sul posto, e alcune persone pagano per gli SMS che ricevono (dipende dal paese e dal gestore di telefonia mobile). L'email è leggermente migliore (ma, naturalmente, non se l'applicazione che stai cercando di proteggere è una webmail ...).

have option to save login device+location in history (ie dont use this option if your at a netcafe or a public network etc) so it will always ask for your 2step

Si noti che in un netcafe, la sicurezza va giù nel lavandino. Un keylogger è semplicemente troppo invisibile. Non c'è molto che puoi fare contro quello.

So think I'm going overkill?

Sì. Ma, soprattutto, manca anche l'importante funzionalità, che è SSL a livello di sito.

    
risposta data 21.06.2011 - 15:49
fonte
20

I fattori chiave che cerco sempre in una specifica di definizione del progetto sono qui mancanti:

Che cosa stai proteggendo? Da chi lo stai proteggendo? Qual è l'impatto se è compromesso?

Se stai proteggendo il tuo elenco di compleanni degli amici è quasi certamente eccessivo. Se stai proteggendo il materiale Top Secret da spionaggio internazionale o aziendale, potrebbe essere troppo debole.

Devi pensare al potenziale rischio, agli attori della minaccia che potrebbero bersagliarti e ad altri fattori come la resilienza (un accesso fallito di lunedì mattina rende estremamente difficile per un utente accedere quando serve davvero )

Spero che tu abbia delle risposte a questi, ma a meno che tu non li pubblichi qui può essere difficile per gli altri fornire indicazioni sull'architettura di sicurezza.

    
risposta data 21.06.2011 - 13:47
fonte
5

Qui stai usando molte parole d'ordine sulla sicurezza, ma il risultato finale non è sicuro come dovrebbe essere, e come Lucanos dice che c'è molta ridondanza.

leggi questo thread .

password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client) bcrypt stored hashes

Significa che si genera un hash bcrypt dell'hash sha256 della password? Senza una parola salt la password sha256 non fa nulla per aiutare la sicurezza, e l'uso di un secondo giro di hashing non aiuta neanche.

hashed password is encrypted with private key stored as CONSTANT in app/file

Che cosa? Perché? Vuoi mai recuperare l'hash dell'hash della password? Anche se lo facessi, il modo per farlo sarebbe crittografare usando una chiave pubblica.

recaptcha upon 1st login failure

Non aggiunge molto valore.

if device/location information changes while logged in, kill session

Quindi stiamo parlando di gestione delle sessioni e di autenticazione - in questo caso hai ancora molto lavoro da fare.

    
risposta data 21.06.2011 - 14:48
fonte
4

Ci sono alcune cose che non trovo qui e probabilmente una o due cose che vale la pena aggiungere:

  • la password hash è crittografata con chiave privata memorizzata come COSTANTE in app / file

Come "COSTANTE" - che cosa significa? È difficile da codificare? Come è protetto. Sono d'accordo con altri post che un sale è un buon piano - se salate e cancellate le password, non vedo la necessità della crittografia su di esso. E - se la chiave privata per la crittografia è memorizzata in un file flat o codificata nell'app, hai un punto debole. Consiglia di trovare un modo per proteggere meglio questa chiave.

  • "per dispositivo"

In un certo numero di posti hai detto che stai monitorando il comportamento "per dispositivo", cosa significa? Come stai determinando il dispositivo? Stai implicando qui un tipo di autenticazione del dispositivo, e da quel poco che so su quest'area, molti modi sono immensamente parassiti e le modalità che non richiedono l'emissione di dispositivi da un punto di fiducia, che può cambiare notevolmente il tuo modello di funzionamento .

Nei luoghi in cui dici "per dispositivo", dovrai pensare a cosa significa se il dispositivo sta simulando il tuo sistema. Inoltre, se hai deciso che "Indirizzo IP"="dispositivo", potresti dover considerare numerose situazioni in cui l'indirizzo IP dell'utente cambia senza alcun errore dell'utente.

  • consente di rimuovere la cronologia di accesso dei vecchi dispositivi

È qualcosa che sei pronto a supportare? Lo scrubbing, ad esempio, un cookie è piuttosto semplice, ma intendi tutte le parti della memoria? Personalmente, se facessi questa promessa, l'avrei legata in un modo tale che, se le informazioni di accesso fossero state rese strane dal sistema operativo, non si trattava di una violazione di ciò che il mio sistema aveva promesso agli utenti.

Vedo anche alcuni problemi:

  • Come può un utente recuperare da una password persa / dimenticata?

Vedo che citi un processo abbastanza coinvolto per cambiare la password. Se questo è un sistema web casuale, scommetterei sul denaro che questa sarà la funzione meno utilizzata. Invece, gli utenti si allontaneranno dal sistema, solo per tornare e hanno bisogno delle loro password e li hanno completamente dimenticati (o li hanno scritti su una nota appiccicosa sui loro schermi ... è ancora peggio).

Avrai bisogno di un modo per eseguire il ripristino / ripristino della password adatto al tuo modello ad alta protezione. È gestito da una persona? Hanno domande di riserva per rispondere? Ricevono una password di reset inviata via e-mail fuori dalla banda? Ogni meccanismo di recupero ha un rischio, e generalmente meno rischi = costi più elevati - ad esempio, il controllo dell'identità finale della mia carta di credito per problemi come questo è un doloroso Q & A con una persona dal vivo sulla mia cronologia degli acquisti. Molto buono, ma costoso in termini di salario di quella persona.

  • Un modo semplice per gli utenti di controllare il sistema

Le credenziali presentate dal server in SSL dovrebbero essere abbastanza buone, ma pochissimi utenti sono abbastanza esperti di PKI per questo. So che le grandi istituzioni finanziarie hanno iniziato a utilizzare parole e immagini selezionate dagli utenti che gli utenti dovrebbero verificare durante il login. L'obiettivo qui è quello di evitare una situazione in cui un phisher potrebbe inviare una e-mail all'utente indirizzandoli a "paypa1.com" (un numero 1 e non a un), e ottenere le loro password. Dal momento che disponi di funzionalità che consentono l'accesso remoto, l'utente malintenzionato sarà quindi in grado di utilizzare un account utente legittimo da qualsiasi sistema.

  • Altra ingegneria sociale

Probabilmente questi due problemi non sono i soli processi orientati all'uomo a cui dovrai pensare attraverso: accedi agli accessi? Avete un piano per separare il controllo degli accessi dai privilegi di amministrazione? Quanto accesso hanno gli amministratori e in che modo il sistema è protetto da loro? Ci sono altri attacchi di social engineering che potrebbero funzionare?

Finora, ciò che descrivi è tech-heavy e human-light - stai parlando di un paio di meccanismi che potrebbero avere un impatto sull'usabilità, che potrebbe portare gli utenti a non utilizzare il sistema, o gli utenti che si stanno adoperando per hackerare il sistema per renderlo più facile da usare, e sono preoccupato che non abbiate pensato ai vettori di attacco di un ingegnere sociale. Come l'acqua, gli hacker troveranno il crack o la fessura che è più facile da usare.

Ti colpisco con le cose pesanti qui, perché la mia percezione è che stai cercando di progettare qualcosa di piuttosto alto per qualcosa che è presumibilmente ad alto rischio. Se è questo che stai cercando di progettare, devi eseguire il backup e vedere il sistema intero - la tua comunità di utenti, la nascita dei conti, il comportamento all'interno del sistema ei rischi di un comportamento scorretto.

    
risposta data 21.06.2011 - 15:48
fonte
3

Sto solo andando a fare alcune domande per provare e 1) educare me stesso e 2) darti una prospettiva diversa sul sistema:

password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client)

Se stai usando una connessione SSL per cominciare, hai bisogno di fare questo? Anche nel caso in cui qualcuno fosse in grado di intercettare la password hash, in che modo è più sicuro dell'intercettazione della password in chiaro? Se sono stato in grado di falsificare il login e inviare lo stesso payload hash, come mai è diverso?

a hash of all the important login database values for that user, so that if they are changed via injection somehow, the hash wont match up and the account gets locked out

Quindi, se l'utente aggiorna il proprio indirizzo email o password, l'hash cambierà e la sessione terminerà? O disponi di protezioni per consentire che queste, legittime, modifiche vengano gestite?

if device/location information changes while logged in, kill session (to prevent session stealing)

Non sicuro al 100% di questo, ma questo potrebbe significare che un dispositivo mobile potrebbe essere preso a calci da una sessione (legittima) se passa da WiFi a GSM / Cell, GSM / Cell a WiFi o possibilmente all'interno della rete GSM / Cell ( se cambia l'indirizzo IP pubblico presentato dal dispositivo)?

login strike system per device, so if the user tries 5 diff logins and theyre all wrong, he's out. its not 5 per login

Come stai monitorando "per dispositivo"? Per l'indirizzo IP? Può essere condiviso. Da un biscotto? Può essere eliminato. Da una stringa User-Agent? Anche questo può essere cambiato.

Oltre a queste, alcune delle altre idee sembrano belle.

    
risposta data 21.06.2011 - 05:06
fonte
1

ok, questo è quello che ho imparato dalle risposte di tutti

  • Utilizza SSL, non è necessario hash il lato client della password come inutile, SSL è il modo giusto per proteggere dallo sniffing.
  • Usa BCrypt (w / Salt) per memorizzare l'hash della password, SCrypt se riesco a trovare un'implementazione PHP di esso.
  • Non bloccare l'accesso per la password fallita, basta usare un limite di tempo crescente per prevenire il DOS. Naturalmente registra i tentativi falliti e avvisa gli amministratori se il suo livello è insolitamente alto.
  • la crittografia e il rimodellamento delle password sono inutili
  • considera modi per controllare il sistema e impedire l'ingegneria sociale
  • forza le password lunghe e difficili per gli utenti, come usare passwdqc per controllare e consentire agli utenti di sapere quali sono le password che ci si aspetta da loro.
  • il blocco a causa di modifiche del dispositivo / posizione può essere problematico su telefoni cellulari, wireless o alcuni ISP, prendere in considerazione forse solo la disconnessione dalla sessione.
  • necessità di implementare correttamente la gestione delle sessioni
  • la sessione di amministrazione dovrebbe rimanere all'interno dell'area SSL.
risposta data 25.06.2011 - 07:15
fonte