Google Authenticator, un codice QR, molti dispositivi (utenti)

Question

Google Authenticator, un codice QR, molti dispositivi (utenti)

#1 da (1 voti)
#2 da (1 voti)

-1

Ho un sito web commerciale dove le persone pagano per usare i servizi su di esso. I servizi che offro su di esso sono di una parola "giochi-natura", quindi in realtà non ha bisogno della crittografia di tipo bancario "Ford Knox", ed è quindi la sicurezza di autenticazione dell'utente di base di cui ho bisogno. Attualmente utilizza un normale nome utente e autenticazione della password. Il problema è che una persona può iscriversi e dare il suo nome utente + password a tutti quelli che desidera e tutti possono ottenere l'accesso gratuito. Indirizzo IP, tipo di dispositivo, ubicazione, ecc. Non è un ottimo modo per autenticarlo poiché desidero che sia in grado di effettuare il login su qualsiasi computer o da qualsiasi dispositivo mobile, purché sia presente lì stesso quando lo fa. Poiché l'invio di smss (che dovrebbe andare a un solo dispositivo) diventa piuttosto costoso, speravo che l'app Google Authenticator sarebbe stata un'opzione meno costosa dal momento che si verificava sul suo dispositivo, per garantire che fosse la stessa persona ad accedere al sito web.

Il mio problema arriva con quel codice QR (o codice che digita) che viene creato quando colleghi il mio servizio alla sua app Google Authenticator la prima volta. Sembra da quanto ho letto finora che se copia quel codice QR a tutti i suoi amici e parenti (screenshot e invialo o in qualsiasi modo) e lo scansionano semplicemente sulla loro applicazione Google Authenticator e poi avranno lo stesso accesso come lui. Ho ragione e sarebbe quindi un brutto modo di approcciare la pirateria informatica o la protezione dei contenuti del sito web?

Grazie

authentication

posta JayCee 05.07.2016 - 03:24

fonte

2 risposte

Leggi altre domande sui tag authentication

Quale editor WYSIWYG ha la migliore reputazione di sicurezza? [chiuso] Queste query sono vulnerabili all'iniezione in mysql

score 1 · Answer 1

L'autenticazione a più fattori non può proteggere gli account se il proprietario dell'account stesso desidera condividere un account.

Quando utilizzi Google Authenticator (o qualsiasi altra app di questo tipo), riceve un "seme" che può calcolare il numero PIN 2FA corrente. Se qualcun altro ha lo stesso seme, può anche generarlo.

Se dovessi inviare un SMS senza badare alle spese, potrebbe essere un problema di accessibilità e sembreresti piuttosto avidi.

Per una vera protezione, dovrai controllare qualcosa che è:

Non può essere modificato dall'utente a un valore arbitrario.
Garantito per essere disponibile.

Apple ha una sfilaccia sul numero di dispositivi che l'account iTunes può essere utilizzato. Hanno l'ID hardware per determinarlo. Per un'interfaccia web, non c'è molto che tu possa fare.

Limita il numero di sessioni che può contenere. Ad esempio, mantieni solo le ultime 3 sessioni. Ciò renderà poco pratico la condivisione di un account per esteso.

score 1 · Answer 2

Ci sono 4 opzioni qui:

In alternativa, puoi utilizzare Sistema Android Keystore per generare una chiave all'interno di Archiviazione sicura, ad esempio la chiave privata è molto difficile o impossibile da estrarre. (dipende dal modello di telefono, alcuni modelli possono avere solo un keystore basato su software e non è sicuro come una memoria di chiavi basata su hardware)

Ci sono 2 opzioni qui quando usi questo metodo. In entrambi i casi, è possibile che il valore booleano di IsInsideSecureHardware () sia true, ma ciò limiterà il gioco o l'app solo ai dispositivi che dispongono di una memoria sicura.

Oppure puoi semplicemente utilizzare il Keystore così com'è e essere compatibile con tutti i dispositivi Android 6.0 e successivi.

La seconda opzione consiste nel fornire un dispositivo OTP fisico. Un dispositivo OTP fisico non può essere copiato ed è progettato per cancellare qualsiasi segreto se si tenta di aprirlo. Puoi anche fornire un dispositivo U2F, ma ciò limiterebbe la compatibilità a Chrome.

Una terza opzione è fornire un Yubikey standard. Il codice OTP di un yubikey viene immesso come una tastiera e il tasto AES per la creazione della chiave viene archiviato all'interno dell'archivio protetto che ne rende impossibile l'estrazione. Se segui questo percorso, puoi persino programmare ogni Yubikey per avere lo stesso codice AES per tutti gli utenti, quindi memorizzare l'ID utente all'interno dell'ID privato. Quindi nessuna identità deve essere parte della stringa OTP pubblica e l'utente non deve inserire alcun ID utente o simile, ma inserisce semplicemente YubiKey in una porta USB e tocca il pulsante - voilà ha effettuato l'accesso.

Una quarta opzione che hai, è quella di utilizzare l'HOT basato sugli eventi insieme a Google Authenticator. Possono ancora condividere il seme, ma in tal caso si ha una trappola, ad esempio se viene inserito un codice esaurito o se viene immesso un codice che non è il codice "corrente" (ad esempio un codice futuro), l'account è bloccato e quindi è necessario sia inserire 2 codici dal token HOTP, quindi fornire un nuovo seme (nuovo codice QR), e quindi si dispone di una "tassa amministrativa" pari al 25% della tariffa originale.

Ciò significa che se si verifica una condivisione, e non riescono a "sincronizzare" i propri token insieme a ciascun membro del "gruppo di azioni", costerà loro il 25% della quota di ammissione. Il 25% (potrebbe anche essere il 10%) non è eccessivo se si fa accidentalmente clic sul token senza utilizzare il codice o si reinserisce accidentalmente un codice esaurito, ma è troppo per essere bloccato nuovamente, ancora e ancora se si condivide l'account .