Autenticazione senza registrazione

Question

Autenticazione senza registrazione

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

1

Sia S un server e C un client mobile (app iOS / Android). Supponiamo che la comunicazione tra S e C sia cifrata con SSL (o qualsiasi altro protocollo standard).

Il sistema è un'applicazione votante, cioè S invia alcuni articoli a C e C può upvotare / downvotare loro, inviando il suo voto a S. La cosa è che non voglio che C si registri / iscriva per questo, ma anche io non voglio che voti più di una volta.

Si potrebbe pensare a qualcosa di simile: quando l'app viene lanciata per la prima volta su C, S assegna un UUID a C e C lo memorizza. Quindi ogni volta che C vuole votare invia il voto e il suo UUID e S controlla se quell'UUID ha già votato.

Ma in tal caso, cosa impedisce a qualcuno di creare un programma che chiede sempre S per UUID e quindi vota lo stesso articolo quante volte desidera?

Tutto ciò che mi viene in mente è che S e C condividono una password che è hardcoded e quindi il sistema funzionerà in questo modo:

C chiede S per un UUID,
S invia C a UUID,
C memorizza l'UUID,
Quando C vuole votare, invia a S: {vote, crypt (UUID, sharedPwd)}

Ovviamente nel momento in cui qualcuno ha saputo che la password (e forse è facile ottenerla come è in realtà nel codice del client ...) il sistema sarebbe messo a repentaglio ...

Quindi ... Come può il mio server sapere che le richieste provengono effettivamente dall'App? O potrebbe essere un approccio diverso: in che modo alcune app senza registrazione eseguono l'autenticazione?

authentication

posta Carlos Navarro Astiasarán 09.10.2015 - 21:19

fonte

2 risposte

Leggi altre domande sui tag authentication

Come memorizzare e utilizzare i dati sensibili in Java Possibili minacce sul buffer di memoria

score 2 · Answer 1

Temo che quello che chiedi sia impossibile. Se vuoi che i nuovi utenti siano in grado di utilizzare la tua app, qualcuno troverà il modo di comportarsi come un nuovo utente ogni volta e falsare i voti in questo modo. L'unica soluzione è quella di avere una parte fidata che certifichi le identità di tutti, e ciò non accadrà finché non ci sarà una smart card standard con un certificato del cliente. A partire da ora potresti in teoria fare affidamento su una CA, ma sarebbe un'enorme barriera di accesso e nessuno potrà mai utilizzare la tua app.

Potresti renderlo più difficile però. Utilizzando l'apposizione di certificati sul lato dell'app, l'analisi del traffico è più difficile e l'offuscamento del binario rallenta potenziali aggressori che desiderano replicare il comportamento della tua app, ma anche in questo caso, l'autore dell'attacco deve semplicemente disinstallare / reinstallare l'app e ' Appare come una nuova installazione sulla maggior parte dei dispositivi.

Se possibile sui dispositivi di destinazione, dovresti fare affidamento su un identificatore fornito dal sistema operativo host o dall'app store - che è più difficile da replicare (o addirittura impossibile se il tuo server sta contattando i server dell'app store per convalidare l'installazione del tuo app) rispetto alla replica di un'app in quanto il sistema operativo dispone di modi per accedere all'hardware e ottenere ID per dispositivo da tale indirizzo (indirizzo MAC, IMEI, ecc.) mentre l'app non può accedervi direttamente.

Potresti anche legare gli ID dispositivo univoci a qualcosa di più difficile da ottenere, come i numeri di telefono richiedendo una conferma tramite SMS ogni volta che l'app viene installata. Non fermerà le frodi (e in quanto tale non è adatto per il voto "formale" come le elezioni o qualsiasi cosa in cui il denaro è coinvolto), ma aiuterà. È come il DRM, non ha bisogno di essere a prova di proiettile, deve solo essere più strong delle app del concorrente e gli attaccanti andranno dopo il basso appesantire la frutta, lasciando la soluzione da sola.

Infine, se tutto ciò di cui si sta cercando di difendersi è il voto di massa da parte dei bot, ma non preoccuparsi di occasionali, il voto manuale e l'aggiunta di un captcha sono sufficienti. Ovviamente, questo funzionerà solo se il denaro non è coinvolto, altrimenti potrebbe essere comunque redditizio per gli aggressori assumere uomini per digitare i captcha e commettere frodi in questo modo.

score 0 · Answer 2

È possibile emettere un cookie quando S invia l'articolo a C e C può inviare il cookie al server insieme all'UUID. Se il cookie è valido (il che significa che la sessione è valida), lascia che il voto avvenga. Se qualcuno tenta di inviare una richiesta utilizzando uuid di qualcuno, l'autore dell'attacco non ha cookie nella richiesta, quindi sarebbe un voto non valido, e puoi farlo cadere in sicurezza.

Assicurati di generare un cookie con scadenza appropriata in modo che possa aumentare la validità del voto dell'utente.