Schema di autenticazione web personalizzato

5

Per un progetto al lavoro attualmente sto implementando un webservice non troppo grande. Per motivi di apprendimento di qualcosa di nuovo, ho provato a crearlo come servizio REST, che ha quindi richiesto il problema dell'autenticazione. Alla fine ho optato per HTTP Basic Auth poiché ha il vantaggio di essere supportato praticamente da qualsiasi libreria HTTP, anche se ho dovuto implementare il lato server da solo.

Ieri un collega mi ha suggerito di inviare semplicemente la password con hash anziché il nome utente e la password in chiaro (eventualmente il servizio sarà accessibile solo tramite HTTPS, quindi ho considerato l'autenticazione di base come un problema di sicurezza, ma lasciamo da parte per ora ). Ma mi chiedevo cosa avrebbe effettivamente cambiato, per quanto riguarda la sicurezza.

L'invio della password hash significa fondamentalmente un hash di bcrypt poiché questo è ciò che memorizziamo nel database. Il che significa che prima dovrei inviare al cliente il fattore lavoro e il sale in modo che possano arrivare allo stesso hash che ho nel database. Ciò richiede un meccanismo di risposta alle sfide che è già molto più complicato da implementare.

Quindi c'è il punto che la password hash che il client invia per l'autenticazione funziona essenzialmente come una password in testo semplice, per quanto riguarda l'autenticazione; e potrebbe essere facilmente riprodotto, se qualcuno dovesse impossessarsene.

Quindi in pratica, quello che ho trovato:

  • risolve inviando la password in modo semplice, simile a Digest, invece di Basic
  • Non non risolve il problema del replay (Digest fa, a causa dell'uso di un nonce) di Basic
  • Richiede l'hashing della password sul client con prestazioni meno prevedibili. Per esempio. gli smartphone probabilmente richiedono fattori di lavoro minori rispetto alle macchine desktop e i principali utilizzatori dell'API sarebbero smartphone e tablet. Quindi dovremmo ridurre la forza di bcrypt in quel caso.
  • Sarebbe molto più complesso da implementare, sia nel client che nel server, a causa di uno schema di richiesta / risposta personalizzato e quindi più spazio per errori. Probabilmente va anche contro i principi REST.

Mi sono perso qualcosa? HTTPS risolve i problemi dell'autenticazione di base, per quanto ho capito e quindi lo schema personalizzato non risolve alcun problema reale, a parte forse la noia dello sviluppatore. Ma non sono esperto in questo.

    
posta Joey 02.08.2013 - 14:26
fonte

1 risposta

6

Hai praticamente ragione. In uno schema di autenticazione in cui esiste un solo messaggio, da client a server, qualunque sia il client mostra "concede l'accesso" e, in quanto tale, è equivalente alla password e può essere riprodotto. Se l'hash della password funziona, la password hash è equivalente alla password. In effetti, ciò che suggerisce il tuo collega non aggiunge sicurezza; invece, aggiunge un sentimento di sicurezza, che è, a parità di altre condizioni, una cosa negativa.

Il digest HTTP è in qualche modo migliore a causa del nonce, impedendo così attacchi di rimandi . Un concetto un po 'simile è password una tantum : questo è come il digest HTTP, con un contatore e / o l'attuale il tempo serve come nonce (vedi HOTP e TOTP .

Si noti, tuttavia, che anche se si dispone di un solido meccanismo di autenticazione che potrebbe essere tranquillamente riprodotto su un semplice HTTP, sarebbe comunque un semplice HTTP. Un attaccante industrioso semplicemente osserverà la connessione, attenderà che la parte di autenticazione sia terminata e poi dirotterà la connessione per inviare le sue richieste. HTTP Digest è stato progettato in un momento in cui si riteneva che la maggior parte degli aggressori fosse passiva e si riteneva (a torto) che gli attacchi attivi fossero troppo difficili da estrarre. Il moderno networking ha dimostrato che questa idea non è vera . Pertanto, SSL (HTTPS) è comunque necessario in modo che la parte di autenticazione stia realmente "autenticando" la comunicazione. E se hai SSL, allora l'autenticazione di base (ovvero "mostra la password") va bene.

Si potrebbe anche notare che per supportare protocolli come HTTP Digest, il server deve più o meno memorizzare la password dell'utente in testo chiaro o con crittografia reversibile, quindi in realtà è più debole rispetto al modo normale di memorizzare password hash .

    
risposta data 02.08.2013 - 15:44
fonte

Leggi altre domande sui tag