Protezione del modulo di accesso in un'applicazione desktop

Question

Protezione del modulo di accesso in un'applicazione desktop

#1 da (1 voti)

1

Attualmente ho un'applicazione desktop che richiede all'utente di avere un nome utente e una password. Queste credenziali sono memorizzate su un server web (myserver.com), quindi quando digita il nome utente e la password e fa clic sul pulsante Login, vengono inviati al server web. Se le credenziali sono corrette, il server restituirà "ok", alcune informazioni utente e verrà visualizzato il modulo principale. In caso contrario, il server restituirà "sbagliato" e verrà visualizzato un avviso. Tuttavia, questo è molto insicuro, perché un utente può semplicemente modificare il file hosts, reindirizzare myserver.com al suo localhost, che restituisce sempre "ok", ed evitare la schermata di login. Mi è stato detto di generare un paio di chiavi RSA e quindi di crittografare un "nonce" (un numero casuale) nell'app desktop e inviarlo insieme alle credenziali. Se il server può restituire il numero decrittografato, ciò significherebbe che è in realtà il mio server. Devo dire che il server web è ospitato in Heroku, quindi HTTPS è abilitato di default, ma non ho alcun certificato SSL di sorta. Questo sembra essere abbastanza buono, ma questo è incline ad un attacco man-in-the-middle? Un utente malintenzionato potrebbe semplicemente reindirizzare myserver.com al suo localhost, inviare la richiesta da localhost, ricevere il numero decrittografato, cambiare "errato" in "ok" (o modificare alcune informazioni utente) e inviarlo nuovamente all'app.

Come posso creare un modulo di accesso più sicuro per un'app desktop?

authentication desktop rsa

posta Ivan 19.08.2014 - 11:15

fonte

1 risposta

Leggi altre domande sui tag authentication desktop rsa

Qual è l'inverso del modello di sicurezza sandbox? Perché Oauth2 redirect_uri può essere un URI non-https?

score 1 · Accepted Answer

L'aspersione della polvere fata cripta non impedirà al malintenzionato che controlla il client di fare fare al client tutto ciò che desidera. Può comunque reindirizzare a localhost, ma ora ha bisogno di sostituire la chiave pubblica che hai incorporato con l'app con la sua chiave pubblica. Oppure collega un debugger e disabilita completamente l'uso di crypto. Oppure decompilare, rimuovere l'uso della crittografia e ricompilare. Non puoi controllarlo perché è tutto in esecuzione sul computer client su cui il tuo aggressore ha il controllo totale e non hai controllo e provare a controllarlo è una strategia perdente.

Quello che devi fare è mantenere le risorse che l'utente vuole accedere al tuo server, quindi non lo aiuta a cambiare il comportamento del cliente. Se il client si connette a localhost anziché al server, non possono accedere alle risorse poiché le risorse sono sul tuo server, non su localhost. Se provano ad accedere a servizi per i quali non hanno ancora effettuato l'accesso, il tuo server dovrebbe rifiutare la richiesta - dopotutto, il tuo server dovrebbe monitorare chi ha effettuato l'accesso con un'implementazione di gestione delle sessioni standard (non scrivere da solo; difficile e scrivere i propri risultati sempre in un'implementazione vulnerabile).

Oh, e devi usare crypto, ma solo dove effettivamente aiuta. Utilizzare TLS 1.1 o 1.2 o utilizzare SSHv2 per proteggere il traffico di rete. Seleziona cifrari forti. Fornire agli utenti la chiave pubblica firmata digitalmente da un'autorità di certificazione attendibile. Cripta le risorse quando le memorizzi nel tuo database. Usa la crittografia strong come aes128 o 3des. Genera la tua chiave in modo sicuro, leggendo la documentazione completa sul tuo generatore di numeri casuali, usando solo quella che dice che va bene per scopi crittografici, che è standard, e senza correre il rischio di sovrascrivere il seme invece di integrarlo (alcuni documenti sono molto fuorviante, come Java java.security.SecureRandom).

E infine, assumi un esperto di sicurezza o impara da solo sulla sicurezza su OWASP.org (un ottimo punto di partenza, ma fai attenzione, perché spesso hanno degli errori).