Identifica il client in base all'hash calcolato

Naviga le tue risposte
2

Attualmente sto sviluppando un'applicazione web che fornirà dati ai client iPhone. Per essere il proprietario dei dati, non voglio che altri client siano in grado di ottenerli.

Pensavo di poter utilizzare una chiave segreta condivisa tra il server e i client: una stringa hardcoded che salverebbe il timestamp per garantire che la richiesta fosse stata eseguita da uno dei miei clienti. Quindi la richiesta sarebbe simile a questa: 

http://domain.com/request/[desired_object_id]/[device_id]/[timestamp]/[hash]

Vorrei calcolare l'hash in questo modo nell'app: 

hash = sha(desired_object_id + device_id + timetsamp + "mysecretkey")

E sul lato server, mi sarei assicurato che l'hash fosse stato generato correttamente prima di inviare i dati. (tutti gli oggetti identificati da "desired_object_id" sono disponibili per tutti gli abbonati). In alternativa, potrei anche generare una chiave casuale piuttosto che un timestamp.

Il problema è che non mi sembra sicuro ... I dati non sono critici, è solo che non voglio offrire una API pubblica usata dai non abbonati. E fare ciò mi impedirà anche di cambiare la chiave segreta, perché ciò costringerebbe gli utenti ad aggiornare ad una nuova versione client (non molto utile per gli affari ...)

C'è qualche altro problema noto con questo? C'è un modo migliore per farlo? Preferibilmente con la stessa semplicità.

    
posta Julien 09.04.2011 - 12:06
fonte

3 risposte

5

Diversi problemi qui:

  1. Questa configurazione costringerebbe a mettere la chiave segreta sul client. Chiunque abbia una decente abilità di reverse engineering potrebbe recuperarlo e quindi riprodurre tutte le richieste a proprio piacimento.
  2. Non ha senso inserire elementi come 'desired_object_id e così via nell'hash, se tutti questi elementi sono visibili in chiaro (l'URL). L'unica ragione per farlo è impedire che l'hacker trovi la tua chiave segreta. Ma il metodo di prevenzione più semplice qui è semplicemente scegliere un segreto buono (alta entropia).
  3. Il timestamp è la forma più debole di un nonce. Se hai bisogno di riprodurre il timestamp sul server, allora stai costringendo tutti i client ad avere orologi ben sincronizzati. Se la stai usando solo per un nonce, allora non stai riconoscendo un'importante proprietà dei nonce: devono essere casuali. I timestamp non sono casuali, anche se gli orologi sono sciatti, saranno entro un giorno (86400 secondi al giorno), fuori dai possibili 32 bit (4,2 miliardi di secondi), che utilizza una piccola frazione del possibile spazio delle chiavi e non è nemmeno distanziato in modo casuale, sono raggruppati tutti attorno a un valore che conosci praticamente (ora corrente).
risposta data 09.04.2011 - 15:24
fonte
2

Prima di tutto: la tua "stringa hardcoded" non può essere segreta, perché ogni istanza client la contiene, una facile preda per reverse engineering . L'attaccante ha già questo. Un esempio famoso è la chiave di crittografia per contenuti DVD, incorporata in alcuni lettori software "autorizzati" come PowerDVD ...

Quindi quello che stai cercando deve essere una stringa segreta per client - che può essere una password, o un valore memorizzato in un cookie sul client.

Quindi la risposta facile: utilizza SSL (ad esempio HTTPS ). All'interno della richiesta, incorporare la stringa segreta per client (ciò avverrà automaticamente con un cookie); SSL gestisce il resto. In particolare, SSL proteggerà non solo la richiesta ma anche i dati stessi dagli sguardi indiscreti di chi ascolta. Non otterrai nulla di paragonabile in termini di sicurezza da qualsiasi schema nazionale, indipendentemente da quante funzioni hash e timestamp includi nello stufato.

    
risposta data 03.02.2013 - 16:32
fonte
0

Ho trovato un interessante articolo su StackOverflow , che descrive diversi modi per farlo.

    
risposta data 13.04.2011 - 08:29
fonte

Leggi altre domande sui tag

HTTPS Ovunque contro NoScript È vero che la "forza" del bit di crittografia, sebbene numericamente identica, potrebbe effettivamente essere diversa a seconda dell'algoritmo?