Esiste un modo per accettare le richieste firmate senza memorizzare la password del client in testo semplice?

6

Stiamo sviluppando il servizio Web REST. Daremo l'identificatore e la stringa segreta a ciascuno dei nostri clienti REST. Quando eseguono le richieste, i client si autenticano utilizzando l'algoritmo HMAC (firmeranno il corpo e le intestazioni delle richieste HTTP utilizzando la stringa Secret). Il servizio REST riceverà intestazioni HTTP, corpo, trova il segreto del client dal database utilizzando il suo identificativo, lo firma e verifica se la firma calcolata è uguale alla firma fornita dal client.

In realtà, è meglio spiegato alla pagina di autenticazione di Amazon S3 .

Per utilizzare questo schema dobbiamo memorizzare le chiavi segrete dei clienti in testo normale, giusto?

C'è un altro modo per autenticare i client senza archiviare le loro chiavi segrete sui nostri server (o memorizzarli in modo non recuperabile, ad esempio i loro MD5-hash)?

    
posta galymzhan 11.03.2011 - 12:01
fonte

3 risposte

13

In senso stretto, l'uso del termine "firma" su HMAC è improprio; è diffuso, ma non è corretto: le firme riguardano algoritmi asimmetrici con una chiave pubblica e una privata, come RSA.

HMAC usa una chiave segreta (cioè un mucchio di byte arbitrari) che viene usata per calcolare il MAC e per verificarlo (in realtà è verificato ricalcandolo). Quindi, nel tuo problema, sì, il server deve memorizzare la chiave segreta o alcuni dati sufficienti per ripristinarlo.

Si noti che la chiave segreta K può essere derivata da la password in modo non invertibile. Per esempio. tramite una funzione di hash o, meglio ancora, con una funzione di derivazione chiave . Il server memorizzerà la chiave K "in chiaro" e la chiave di conoscenza K è sufficiente per produrre valori HMAC validi. Tuttavia, questo costringe un utente malintenzionato a utilizzare un software specifico per questo, non il client standard che richiede una password utente. A seconda del contesto e del modello di attacco, questo può o non può essere un miglioramento della sicurezza.

Un modo per ottenere ciò che stai cercando, ma con una complessità più elevata di un semplice HMAC, è quello di utilizzare SRP . SRP è un protocollo di scambio di chiavi asimmetrico con autenticazione reciproca basata su password, con le seguenti caratteristiche:

  • Nessuna necessità di distribuzione di chiavi pubbliche (PKI, certificati ...).
  • Il client autentica il server e server autentica il client, nello stesso passaggio, anche in presenza di attaccanti attivi (gli attaccanti "Man-In-The-Middle" vengono sconfitti).
  • Nessun attaccante attivo o passivo apprende informazioni sufficienti per eseguire attacchi di dizionario offline (un attacco di dizionario indovina la password provando parole casuali; l'attacco è offline se può essere fatto senza interagire con l'onesto client o server per ogni ipotesi).
  • Ciò che il server memorizza non è sufficiente per imparare la password o impersonare il client (ma consente attacchi di dizionari offline, il che è inevitabile).

La chiave che risulta dal protocollo SRP può quindi essere utilizzata per un algoritmo MAC come HMAC. Non ha bisogno di essere archiviato: è semplicemente tenuto nella RAM per tutta la durata della sessione.

SRP può essere integrato in TLS, come spiegato in RFC 5054 . Il modo più semplice e standard supportato di utilizzare SRP nel proprio contesto sarebbe quello di utilizzare HTTPS (ad esempio HTTP all'interno di un tunnel SSL / TLS) con la parte TLS che utilizza SRP per lo scambio di chiavi. GnuTLS è un'implementazione opensource di SSL / TLS che supporta SRP.

    
risposta data 11.03.2011 - 15:00
fonte
5

SRP non richiede una terza parte attendibile o un certificato SSL poiché utilizza il segreto condiviso esistente tra client e server per l'autenticazione. Una terza parte non è necessaria quando le due parti originarie si fidano l'una dell'altra. E a differenza degli schemi basati su HMAC, SRP memorizza la password sul server in modo "non recuperabile" o non in testo normale, il che significa che un utente malintenzionato che impara il segreto del server non acquisisce la capacità di impersonare un client.

Altri vantaggi di TLS-SRP rispetto a uno schema HMAC ad hoc sono: resistenza agli attacchi del dizionario offline, resistenza agli attacchi di replay e crittografia del trasporto.

    
risposta data 13.03.2011 - 01:55
fonte
5

Come ha sottolineato Thomas Pornin, SRP / TLS è supportato in GnuTLS e OpenSSL supporterà le cipherrite SRP nella versione 1.0.1. Le patch sono disponibili per OpenSSL 0.9.8 e 1.0.0. Se la tua applicazione utilizza C / C ++, sei abbastanza ben coperto.

Per Java, c'è BouncyCastle, e per Python c'è TLSLite. Quale lingua e piattaforma stai utilizzando?

    
risposta data 15.03.2011 - 22:25
fonte

Leggi altre domande sui tag