Questa autenticazione di accesso è sicura?

2

Ho pensato a un modo per autenticare gli utenti in modo tale da scegliere gli utenti che utilizzano versioni di cracking del mio gioco dalle persone che lo hanno effettivamente acquistato. Mi è venuta in mente questa idea:

Il client chiede al server di login il suo bl_hash , che viene aggiornato ogni 12 ore. (Ha bisogno di essere un intervallo di tempo più piccolo? Sto usando Threefish-512 per aggiornare i blocchi, la chiave sarebbe un output di CSPRNG.)

Il client quindi crittografa bl_hash con l'hash della sua password (il u_hash ), questo è noto come l_hash .

Il client invia il suo l_hash al server dei giochi insieme al suo nome utente. Questo è packet_login .

Il server di gioco invia i dati di% co_de ricevuti al server di login.

Il server di login decrittografa packet_login con l_hash e risponde al server se questo è il ragazzo che dice di essere o no.

Il server di gioco rifiuta o accetta il lettore in base a quanto ricevuto dal server di login.

Capisco che questo potrebbe essere suscettibile a un attacco man-in-the-middle per il server, ma questo probabilmente sarebbe impossibile da fare poiché i server di giochi saranno probabilmente all'interno di un data center. Sono possibili miglioramenti che posso apportare?

Grazie per il vostro tempo, e mi scuso profondamente se questo è nel sito sbagliato!

    
posta 02.09.2012 - 11:44
fonte

2 risposte

2

Se ho capito bene, il pacchetto di accesso sarà esattamente lo stesso per lo stesso utente entro il tempo di validità di bl_hash . Quindi un attaccante passivo può registrarlo e riprodurlo . Per evitare questo tipo di attacco, bl_hash deve essere usato una sola volta (vedi nonce ).

Decrittografia del pacchetto di accesso con l'hash della password utente, implica che l'hash non sia salato . Una salt è una stringa casuale che è unica per ogni password ed è concatenata prima che l'hash sia calcolato. Impedisce a un utente malintenzionato, che ha accesso al database dell'account, di attaccare tutte le password in parallelo con un attacco di dizionario. Invece di un semplice hash, dovresti utilizzare uno degli algoritmi di hashing della password come sha512crypt, bcrypt o scrypt per memorizzare la password.

Il client non autentica il server. Pertanto è possibile un uomo nell'attacco centrale .

Consiglio vivamente di utilizzare SSL. È un protocollo molto ben collaudato con librerie per tutti i linguaggi di programmazione comuni. E non è vulnerabile a nessuno di questi problemi.

    
risposta data 02.09.2012 - 19:01
fonte
0

Questa non è principalmente una domanda di crittografia; è principalmente una domanda sulla gestione del rischio. Nessuna soluzione fornirà sicurezza Ironclad. Invece, è necessario identificare i rischi principali (i modi principali in cui gli utenti tenteranno di frodare te) e quindi introdurre controlli o attenuazioni che riducano il rischio a un livello accettabile. La maggior parte di questi controlli è probabilmente di natura non crittografica.

(Per questo motivo, penso che otterresti risposte migliori sul sito IT Security.)

Alcuni esempi di attenuazione:

  • Usa SSL quando accedi.

  • Registrare l'indirizzo IP del client. Controlla la loro area geografica. Segnala qualsiasi account che sembra spostare le regioni geografiche in modo sospetto.

  • Registra i dettagli sulla piattaforma del cliente (ad es. sistema operativo, numeri di versione, indirizzo MAC di rete). Segnala qualsiasi account in cui questi sembrano cambiare in modo sospetto.

  • Rileva la lingua utilizzata nella chat online da questo utente (ad es. inglese, russo, tedesco, ecc.). Se cambia in modo sospetto, segnala all'account un ulteriore esame da parte di un essere umano.

  • Implementa le difese contro le "crepe" del tuo gioco binario. C'è molto scritto su questo argomento; puoi cercare su Internet.

Dovrai decidere quali hanno un adeguato rapporto costo / beneficio.

    
risposta data 02.09.2012 - 20:27
fonte

Leggi altre domande sui tag