Proteggi password / autenticazione durante il transito su socket TCP (non sicuro) per un gioco

4

Sfondo

Sto progettando un gioco multi-player con un singolo server che gestisce più mondi. Ogni giocatore accede al server inizialmente prima di richiedere a quale mondo aderire.

Il server ha un indirizzo IP fisso che è attualmente uguale all'indirizzo IP del sito. Questo potrebbe cambiare in futuro se i server dovessero essere eseguiti in parallelo, tuttavia al momento è sicuro che il server sia, in realtà, il server e non un impostore.

Le password sul mio sito sono state sottoposte a hashing con bcrypt e sale e sono state archiviate in un database MySQL.

Al momento non ho un certificato SSL, anche se sto pianificando di ottenere un ASAP e certamente prima che i dettagli del pagamento siano gestiti dal sito, ma è probabile che il gioco si possa connettere su una connessione TCP aperta, quindi la mia sicurezza i bisogni relativi all'autenticazione degli utenti del gioco devono essere gestiti manualmente.

Pubblico

Il pubblico principale del gioco sono i giovani adolescenti, ma in particolare quelli in grado di scrivere un piccolo codice, quindi posso aspettarmi che una piccola parte di essi sia programmatori relativamente competenti e un sottoinsieme più piccolo da poter decodificare e irrompere un sistema non sicuro.

Il mio approccio attualmente considerato

Ho passato un po 'di tempo a riflettere su questo problema e ho trovato una soluzione che sembra essere classificata in un algoritmo "Challenge-response", ovvero:

  1. Il client invia il nome utente
  2. Il server riceve e amp; verifica nome utente e invia una richiesta per dati della password insieme a un token unico . La mia attuale idea per questo il token univoco è generare una stringa casuale, MD5, quindi anteporre a intero univoco e incrementale per garantire che sia lo stesso hash mai inviato, e che non è prevedibile.
  3. Il client riceve token, esegue l'hash della password utilizzando bcrypt con il noto sale per ottenere il valore nel database del sito Web e quindi aggiunge il token prima di eseguirlo nuovamente attraverso bcrypt.
  4. Il client restituisce questo nuovo hash sul socket
  5. Server legge questo, lo verifica e notifica al client che lo è ora autenticato come nome utente inizialmente inviato.

Obiettivi

Nessun dispositivo, ma il vero client e il server dovrebbero essere in grado di trovare la password o autenticare intercettando i dati riservati scambiati.

Preoccupazioni

Ho un problema particolare con questo approccio in quanto ora il segreto che ho usato sul mio sito web per le password hash deve essere conosciuto dai clienti. Sto lottando per pensa a una ragione che sta compromettendo la mia sicurezza, ma è sbagliato. Suppongo, in teoria, che possano ora pre-generare tabelle arcobaleno, quindi se riuscissero a ottenere una copia del mio database, ci sarebbe una quantità di tempo molto inferiore tra loro di ottenerlo e crackare un numero decente di password dell'utente, il che significa che i miei account degli utenti corrono un rischio maggiore in quanto avranno meno avvisi se qualcosa dovesse accadere.

Al di fuori di questo, tuttavia, apprezzerei molto anche una valutazione del mio approccio considerato e di eventuali puntatori o collegamenti che potrebbero essere utili per assicurarlo di più.

Sono più che felice di rispondere a qualsiasi domanda! Grazie!

    
posta Ashley Davies 09.08.2015 - 20:00
fonte

2 risposte

3

Come Martin ha suggerito nei commenti, suggerirei vivamente di utilizzare TLS . Anche se il tuo pubblico è giovane, rivelare il sale al cliente non è una buona idea.

Ad esempio, che cosa succederebbe se il sale per gli hash fosse codificato nell'applicazione Web e che un utente malintenzionato sfrutti una vulnerabilità per estrarre gli hash delle password di bcrypt? Se l'utente malintenzionato può determinare il sale dal client, l'autore dell'attacco può iniziare a decifrare gli hash delle password con meno sforzo.

Alcune buone risorse sul motivo per cui non si dovrebbe stampare la propria crittografia possono essere trovate qui e qui .

    
risposta data 17.08.2015 - 18:21
fonte
0

Sono d'accordo sul fatto che l'utilizzo di TLS per crittografare l'intero scambio di autenticazione sarebbe la soluzione migliore. Se pensi che TLS sia troppo esteso per l'ambito che intendi, considera quanto segue:

  • L'uso della password come segreto condiviso in uno schema di richiesta / risposta non ti spinge a passare il suddetto segreto condiviso dal client al server la prima volta , quando il l'utente crea un account.

  • È possibile utilizzare una semplice crittografia asimmetrica (il server invia la chiave pubblica al client, il client crittografa la password, il server la decifra usando la chiave segreta), ma ciò non ti salva dagli attacchi man-in-the-middle .

Quando utilizzi TLS:

  • Chiedi al server e al cliente di concordare cifrari ragionevolmente sicuri, anche per il prossimo futuro.

  • Chiedi al client di eseguire anche un'autenticazione basata su certificato prima di stabilire la connessione. Non è solo il server che si dimostra al cliente che è legittimo, ma anche il client stesso deve dimostrarlo al server. Anche se ciò non impedisce al malware di manomettere il codice del client in memoria e ha ancora mostrato come legittimo, metterebbe un altro livello di sicurezza contro gli attacchi MITM.

  • Potresti volere che i certificati non del server (e del client) siano semplicemente autofirmati, ma firmati da un'ancora di attendibilità 'ufficiale' (come VeriSign) e utilizzare CA pinning per proteggiti dai proxy MITM che scambiano i certificati come fanno già i proxy sniffer SSL già pronti.

In questo modo dovresti essere ragionevolmente protetto dagli attacchi ai dati in transito, e rendere il client e il server (software e hardware) a prova di manomissione non erano lo scopo di questa domanda.

TL; DR: "Userò TLS" da solo non è tutto, tutti i mezzi per farlo - ci sono una serie di insidie che potrebbero rendere una connessione crittografata TLS ancora vulnerabile.

    
risposta data 13.03.2018 - 08:37
fonte

Leggi altre domande sui tag