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:
- Il client invia il nome utente
- 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.
- 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.
- Il client restituisce questo nuovo hash sul socket
- 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!