Ci sono vulnerabilità con questo meccanismo di autenticazione?

I am trying to come up with a way to implement token-based authentication for a REST API without the need for SSL.

Non farlo!

Utilizza SSL (beh, TLS in realtà).

nothing that isn't public already is going over the wire

Ovviamente non è esatto:

• il nome utente viene catturato; TLS nasconderebbe il nome utente (non sto dicendo che è ancora serio, ma è un'informazione che viene divulgata);
• viene acquisito un hash basato sulle informazioni disponibili e ora è possibile provare le password (attacco dizionario).

I have only started looking at security therefore pretty much a novice at this stuff so any help/advice would be appreciated!

Utilizza gli strumenti appropriati. Non provare a creare protocolli personalizzati. Se cerchi di elaborare i tuoi protocolli di sicurezza, saranno quasi sempre imperfetti.

Ci sono molti problemi con il tuo protocollo:

• rivela il nome utente (potrebbe non essere un problema enorme, ma comunque)
• rivela l'hash della password: consente l'attacco offline alla password
• il server deve conoscere tutte le password in chiaro (memorizzandole in chiaro o memorizzandole crittografate con la crittografia simmetrica e memorizzando la chiave di crittografia) (beh, non l'utente password, ma vero autenticatore segreto utente
• e la parte peggiore: assolutamente nessuna protezione contro un attaccante attivo

Risposta al tuo aggiornamento:

I should have been more clear with regards to the SSL.... it's not that I am trying my best to avoid using SSL, it's more catering for the scenario where it isn't an option.

Perché non è un'opzione in questo scenario?

Also, please target your answers more to the reasons why this approach wouldn't work & if it could be tweaked to work rather than "use SSL".

TLS ti offre livello di sicurezza "sicurezza": segretezza e integrità (in realtà, la segretezza è limitata, poiché la dimensione del messaggio è trapelata, la segretezza delle chiavi a dimensione fissa è protetta). p>

Può essere "ottimizzato" per funzionare senza utilizzare effettivamente TLS, se si reimplementa la maggior parte di TLS per ottenere la sicurezza del trasporto senza TLS. Il costo di implementazione sarebbe ottimo e, anche se è possibile ottenere tutti i dettagli corretti, l'implementazione potrebbe non funzionare come un'implementazione TLS accuratamente ottimizzata.

La domanda importante è perché non desideri utilizzare TLS .

Fornisci informazioni sufficienti per consentire la forzatura offline della password.

Esaminiamo. L'intercettatore conosce il timestamp, il sale e il risultato dell'hash (hash (password + sale) + timestamp). L'autore dell'attacco può eseguire hash (hash ( guess + salt) + timestamp) ripetutamente con valori diversi di "guess" finché il risultato non è uguale al token osservato. La password è quindi nota.

Questo è terribilmente sbagliato. Come ha detto il ragazzo curioso, mai e poi mai mai provare a creare i propri protocolli di autenticazione. Ciò che è più inquietante è che dici con sicurezza che evita gli attacchi replay, quando non lo fa affatto.

Se qualcuno con uno sniffer acquisisce il passaggio 5, riuscirà sempre ad accedere, perché il client sta inviando il timestamp e il server si fida di esso. Quindi puoi riutilizzare quel timestamp per sempre, fino a quando la password non viene cambiata. Anche se aggiungi una finestra temporale, l'hacker deve solo automatizzarlo per accedere non appena il client invia la sua risposta.

Qui ci sono un paio di grossi problemi.

Se stai parlando di un browser come client, hai subito una grande vulnerabilità. A meno che non si stia implementando il codice come script greasemonkey (cioè già sul client), il codice per implementare il passaggio 3 deve essere inviato tramite il canale non crittografato (presentando un'opportunità di essere intercettato e modificato).

Lasciando da parte questo, la tua proposta autentificherà il nome utente - ma come fai a mantenere una sessione / autenticare ulteriori richieste dal client?

Anche senza conoscere nome utente e password, né modificare il flusso di dati, un intercettatore potrebbe assumere l'indentità (a seconda di come viene implementata la gestione delle sessioni) sniffando e riproducendo il token fornito dal client.

Sì, è un po 'meglio dell'invio di una password in chiaro, ma solo E sì, c'è un vantaggio nell'impedire la diclosure di una password anche dove non è necessario aggiungere una strong sicurezza alle transazioni effettive in elaborazione (ma il tuo approccio può essere sovvertito da MITM per rivelare la password effettiva).