crea un'app per iPhone / Android che invia una password utente al mio server, come proteggere?

Le persone possono origliare sulle reti mobili? Sicuramente. Inoltre, il tuo server è probabilmente connesso alla rete mobile attraverso l'internet ordinaria dove le persone potrebbero origliare. Inoltre, le persone utilizzano frequentemente la connessione Wi-Fi dai loro telefoni (rispetto alla connessione dati 3g / 4g) che di nuovo andranno oltre l'ordinario Internet ed è soggetta a molti potenziali fattori di rischio.

Perché non SSL? Se si dispone di un proprio dominio, è possibile ottenere gratuitamente un certificato SSL da una CA firmata attendibile (autorità di certificazione) (https://startssl.com), che impedisce attacchi di tipo eavesdropping / MitM, ecc.

Ci sono problemi con il tuo schema. Ad esempio, gli attacchi di replay (che intercettano ripetutamente l'hash), MitM alterano i messaggi dopo l'autenticazione (ad esempio, sostituendo la recensione legittima con spam o una vulnerabilità XSS), firesheep, ecc. Puoi migliorarlo marginalmente con nonces o timestamp, ma di nuovo è molto più semplice solo per usare SSL piuttosto che provare a reinventare la ruota.

Potresti pensare che non mi occupo di carte di credito perché mi interessa se non sono sicuro. Forse hai recensioni e alcuni spammer decidono di rubare credenziali per molti account per rivedere positivamente i loro prodotti. O qualche script kiddie si arrabbia con una recensione e cancella tutte le recensioni che possono dal tuo sito. O la tua idea di un hash strong è sha-1 senza sale (ad esempio, hai lavorato per linkedin) e qualcuno cattura gli hash inviati sulla rete e presto cattura un milione di sha-1 hash e brute li forza in parallelo in un incidente imbarazzante.

C'è una frase che voglio insegnarti: "Qual è il tuo modello di minaccia?" Se interagisci con la sicurezza, garantisco che uno di loro ti chiederà a questo punto. Questa domanda è un suggerimento per te che non hai pensato attentamente esattamente quale problema stai cercando di risolvere.

Quando ho letto la tua dichiarazione "Non ho SSL sul mio sito web, ma è solo un sito di recensioni e nessun dato privato viene trasmesso, tuttavia, su un telefono cellulare mi sembra più pericoloso", quello che percepisco è che non stai pensando attentamente alla sicurezza. Sembra che tu stia reagendo sulla base di sentimenti, impressioni superficiali e associazioni emotive. Non è il diritto di fare sicurezza. Invece, è necessario prendere in considerazione il rischio reale, valutare le possibili attenuazioni per difendersi da questi rischi e quindi capire se ne vale la pena.

Sulla tua domanda, no, non ti consiglio di fare quella strana attività di doppio hashing delle password. Non cercare di diventare troppo intelligente e non provare a reinventare la ruota; molti altri hanno provato prima di te, e le probabilità sono che si ripeterà un errore che hanno già fatto.

Ci sono fondamentalmente due opzioni che potrebbero avere senso per te:

• Usa SSL. Se sei preoccupato per il rischio di intercettazioni e attacchi man-in-the-middle, la soluzione giusta è ottenere un certificato SSL e abilitare SSL. Scovare con la password personalizzata doppio-hashing non è raccomandato.

• Non fare nulla. Personalmente, penso che una risposta più ragionevole sia: non preoccuparti di SSL. Non preoccuparti per questo. Non fare niente di speciale Hai detto che non ci sono dati privati e il sito web non è importante. Se è così, allora usare l'ordinario HTTP va bene. (Sospetto che questa risposta potrebbe non essere così popolare su questo sito: per la sicurezza, a volte c'è la tendenza a cercare di rendere tutto il più sicuro possibile, tuttavia, in pratica non è sempre la risposta giusta.)

Scegli uno o l'altro. Ma non provare a fare qualcosa di strano. C'è una ragione per cui le soluzioni standard sono, beh, standard.

Dipende da quali sono i tuoi obiettivi. Se stai cercando di proteggere il trasferimento della password come sviluppatore Android, posso facilmente dire che è molto più efficiente per te abilitare semplicemente https sul tuo sito web e sulla app piuttosto che progettare e implementare un metodo di hashing. Tuttavia, implementerei un metodo di hashing di qualche tipo almeno per memorizzare la password sul server in modo che se viene violato non si perdono i dati della password.

Se il tuo modello di sicurezza sta davvero evitando di rivelare la password agli intercettatori, allora un qualche tipo di hashing potrebbe fare il trucco. Avrai voglia di farlo bene, però.

Se l'utente accede al sito Web (tramite l'app) semplicemente mostrando un hash della password, allora questo hash è sufficiente per l'autenticazione. Qualcuno spiando la linea imparerà l'hash e potrebbe quindi accedere anche al sito. Il valore hash è equivalente password . Se lo stesso utente ha la stessa password su un altro sito (che non si conosce), l'hashing avrà alcuni vantaggi solo nella misura in cui l'altro sito (che non si conosce) non ha avuto la stessa idea e ha utilizzato la stessa stessa funzione di hash di quella che stai proponendo di usare. Se il tuo sito richiede SHA-1 (password) per accedere, e l'altro sito anche richiede SHA-1 (password) per accedere, l'hacker che apprende SHA-1 (password) tramite l'intercettazione ottenere l'accesso ad entrambi i siti, esattamente quello che volevi evitare.

La soluzione è assicurarsi che la tua funzione di hash sia diversa da quella di qualsiasi altro sito. Per farlo, includi il nome del sito nell'input dell'hash. Ad esempio, se il nome del sito è www.example.com e la password è sdfl478gb9 , quindi esegui il calcolo delle app SHA-1 ("www.example.com:sdf1478gb9"). Altri siti possono utilizzare strategie diverse, ma è altamente improbabile che usino il nome del tuo del sito (e se lo facessero, allora probabilmente hanno cercato attivamente dei problemi).

Ovviamente, l'utilizzo di SSL potrebbe essere più semplice. Tanto più che controlli sia l'app che il server: potresti creare un certificato autofirmato per il tuo server e incorporare una copia di tale certificato nell'app, evitando tutti i problemi con la "CA stabilita".

Personalmente, vorrei mordere i $ 100 / anno per comprare un certificato SSL - non è così tanto, e se sei preoccupato per la sicurezza, ne vale la pena. Se qualcuno annusa una password e ottiene l'accesso al tuo sito, può utilizzarlo per trovare altri exploit, portando a compromessi più ampi: cose come la possibile iniezione di SQL per ottenere password / hash degli altri utenti, account di posta elettronica, ecc.

Se assolutamente non lo farai, usa un valore prevedibile per salare con, come un timestamp. In questo modo l'hash è valido solo per un breve periodo e lo sniffing non darebbe accesso permanente.

<script type="text/javascript">
var timestamp = new Date().valueOf();
var hash = sha256(sha256(userpass)+salt+timestamp);

Invia sia l'hash che il timestamp al server per il confronto (esempio di php):

<?php
if ($_POST['timestamp'] / 1000 - ts() > 60) {
    //throw error or exit, password was hashed more than a minute ago
if (sha256($userHashFromDatabase.$salt.$_POST['timestamp'] ==
    $_POST['hash']) {
    // Login successful -- do stuff
} else { 
    // login failed
}