Usa la password per calcolare il checksum per le richieste API

Naviga le tue risposte
3

Mi chiedevo se sarebbe stato un modo efficace per proteggere un'API richiedendo il check-up di tutte le richieste, salate con la password degli utenti (o una versione hash)? Con la protezione intendo dire "impossibile" per una terza parte fare richieste in nome di qualcun altro o alterare il contenuto. Il contenuto della richiesta sarebbe non privato.

Immagina un'API che permetta a un utente di salvare un testo, quindi la richiesta (contenente l'id utente, il testo, altre informazioni) verrà sottoposta a hash insieme alla password dell'utente che funge da segreto comune e non codificato un client e il server. Il server controlla quindi se il checksum è corretto e sa che la richiesta non è stata modificata e proviene da tale utente.

Questo è qualcosa che viene comunemente fatto e se è una cattiva idea - perché e cosa invece può essere fatto?

    
posta Samuel 10.01.2016 - 19:49
fonte

2 risposte

1

L'uso di un hash per l'autenticazione è molto ragionevole, ma è un po 'difficile da ottenere. Dovresti utilizzare una autenticazione dei messaggi basata su hash in quanto elude alcuni sottili difetti. Puoi trovare librerie affidabili che la supportano per la maggior parte delle lingue / piattaforme.

Uno svantaggio di questa strategia è che richiede che il server abbia una copia in chiaro della password. Questo è raramente consigliabile per le password degli utenti. Ma usarlo per i segreti generati è molto utile.

Un modo per evitare la memorizzazione della password è richiedere un passo di autenticazione nome utente / password (o altro) che restituisca un token sicuro generato dal server. Il client può quindi utilizzare quel token per la firma e il server potrebbe convalidarlo. Se il token è un HMAC di informazioni chiave dal login come nome utente, timeout della sessione, ecc., Il server non ha bisogno di memorizzare il token per verificarlo. Ma, a questo punto, hai praticamente ricreato OAuth e probabilmente dovresti semplicemente usarlo.

Tutto ciò presuppone che tu stia utilizzando SSL. Senza questo, sarà molto difficile prevenire MiTM, replay e attacchi simili.

    
risposta data 10.01.2016 - 20:40
fonte
2

Questo odora di homebrew con tutti i problemi inerenti. HTTPS ha affrontato molti possibili attacchi, compresi quelli che hai descritto. Sarà ingenuo presumere che tu / io / qualcun altro sia in grado di trovare alternative migliori. A meno che tale approccio non venga rivisto da una grande comunità di sicurezza e comprovato dal tempo.

L'HTTPS standard con autenticazione strong risolve tutte le tue preoccupazioni.

    
risposta data 10.01.2016 - 21:57
fonte

Leggi altre domande sui tag

Certificato di risponditore OCSP: punti di distribuzione CRL e URI di AIA OCSP Qual è il vantaggio di un tunnel SSH rispetto a una shell Netcat per le comunicazioni remote?