Problema di sicurezza dell'autenticazione client-server

Question

Problema di sicurezza dell'autenticazione client-server

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

4

Questo è un repost, perché ho postato accidentalmente su stackoverflow primo

Mi chiedevo come avrei potuto raggiungere un alto livello di sicurezza, usando l'autenticazione client-server. Di seguito è riportato un abbozzo di ciò a cui ho pensato:

Lasciachetispieghiunpo'dipiù:

L'eseguibileC++èinesecuzionesuunaconsoledigiocochehaunIDunivocochel'utenteutilizzaperregistrarsisulmiositoweb
Quandol'eseguibilevieneavviato,otterràl'attualehashdelmodulo/filedell'eseguibileel'IDunivoco("Chiave" nello schizzo) e eseguirà una richiesta web sul mio sito Web (esempio in blu sullo schizzo)
L'auth.php sul mio sito Web controllerà quindi se l'hash del file è uguale al file che è stato distribuito (rilevando se il file è stato modificato). Verificherà anche se la "Chiave" è connessa a un utente
Quindi invierà le informazioni individuali da quell'utente e anche alcuni dati / offset necessari affinché l'eseguibile possa essere eseguito in un secondo momento (Ciò impedirebbe teoricamente al pirata informatico di annidare semplicemente la connessione Internet, quindi deve effettuare una chiamata al mio sito Web per ottenere i dati necessari per eseguire correttamente l'eseguibile)

Mi è sembrato buono all'inizio ma poi ho notato alcuni difetti:

Anche se sto offuscando e crittografando il file, un hacker sarà comunque in grado di smontarlo. Il che significa che potrebbe togliere il mio assegno se la chiave è falsa e semplicemente inviare la chiave di un utente registrato (può anche modificare l'hash che viene inviato per impedire l'intero controllo se il file è stato modificato cosa lo rende ridondante)
Poteva anche leggere i dati che sono stati inviati dopo un'autenticazione riuscita e quindi annullare la connessione a Internet, quindi non c'è più alcuna chiamata al mio sito web e inserire i dati che ha inserito nell'eseguibile per farlo funzionare

Indipendentemente dalla sicurezza dell'eseguibile, un hacker sarà sempre in grado di smontarlo / decompilarlo a un certo punto. Ecco perché penso che l'Autenticazione Client-Server deve essere tale che anche se il client viene dirottato non sarà in grado di autenticarsi. Non so davvero se è possibile o se è solo l'approccio sbagliato.

Apprezzerei molto se tu potessi lasciare alcuni pensieri o idee in basso. Grazie per il tuo tempo e buona giornata:)

c++ php mysql license-enforcement

posta ZZ_James 05.05.2017 - 19:18

fonte

2 risposte

Leggi altre domande sui tag c++ php mysql license-enforcement

Sfruttare la vulnerabilità MD5 / sale in questo modulo PHP? Gli indirizzi IP sono prontamente disponibili sul mercato nero?

score 2 · Answer 1

Non ci si può fidare del client e l'autenticazione client-server non può funzionare.

Qualsiasi hacker può eseguire una versione non modificata del software, acquisire tutti i dati necessari e modificare l'eseguibile del client in un secondo momento. L'utilizzo di un proxy di intercettazione gli consentirà di modificare la richiesta e utilizzare l'hash originale del file.

Oppure può usare una chiave valida, scaricare le parti mancanti, correggere l'eseguibile per includere quelle parti e saltare l'autenticazione.

L'utilizzo di TLS non aiuta, nemmeno il pining del certificato. Poiché ha il controllo della connessione, può persino modificare l'eseguibile del client per consentire al proprio certificato di superare i controlli.

Potrà autenticarsi a prescindere da cosa. Le tue protezioni sono solo dossi stradali, non blocchi stradali. Elenco degli schemi di DRM rotti include Sim City, Diablo, Battle Field, Doom, Assassin's Creed, Dishonored, hai capito.

Se anche Ubisoft, EA, Sony, Microsoft, Konami e altri non possono dissuadere gli aggressori, probabilmente non riuscirai a scoraggiarli.

score 0 · Answer 2

Vedo un paio di possibili minacce:

Vulnerabilità per attacchi Man-in-the-Middle. Cosa succede se un utente malintenzionato ottiene un hash valido, modifica il file in seguito e quindi esegue un MitM-Attack per sostituire il file malico generato dall'utente con quello che ha calcolato in primo luogo? Nel tuo setup questo dovrebbe avere successo, sebbene abbia manomesso il file.
Autenticazione tramite URI HTTP Il parametro di query non è una buona idea, poiché è possibile trovarli in vari file di registro o nella cronologia del browser.
Come già sottolineato, tutto ciò che memorizzi su un client non può essere considerato affidabile come i file sul lato server, poiché gli autori degli attacchi possono modificarli in qualsiasi modo e possono estrarre il materiale chiave. Questo può essere banale o no, ma devi supporre che sia possibile.

Per mitigare quelle minacce dovresti:

Utilizza l'intestazione dell'autenticazione HTTP

Invece di inviare informazioni di autenticazione tramite il parametro HTTP Query, passali utilizzando l'intestazione di Auhentication HTTP. Come:

GET example.com Authorization: Basic base64(userid:userpass)

Invece di GET example.com?auth=xxx&hash=xxx

Dato che hai già una sorta di chiave API (parametro auth suppongo?) che è legata a un utente, dovresti dare un'occhiata a OAuth2.0. È un approccio consolidato per autorizzare i clienti ad agire per conto di un utente.

Utilizza TLS

La sicurezza dei livelli di trasporto è necessaria per garantire la riservatezza della connessione. In questo modo puoi essere sicuro che il client parla al tuo server usando la crittografia. Se hai bisogno di maggiore sicurezza, abilita anche l'autenticazione TLS reciproca (vale a dire che anche il client deve autenticare).

Firma i file

L'unico modo per rilevare i file manomessi sul client è di firmarli sul server prima di inviarli all'utente. L'applicazione C ++ deve verificare se la firma è valida prima di eseguire il file. Se hai abilitato una connessione TLS dovresti già essere in possesso delle chiavi richieste.