Sicurezza dell'API REST

2

Sto lavorando su un'API REST che consentirà a un'app Android di comunicare con un sito Web. Purtroppo più della metà delle persone che lo utilizzeranno non può farlo tramite HTTP, quindi dovrò massimizzare la sicurezza su HTTP.

Ciò che deve accadere è semplicemente l'autenticazione tramite un'API REST, nome utente / email e password.

Ho pensato di eseguire l'hashing della password (o del nome utente + della password) clientide e inviarlo al server, ma poi si finirebbe con una seconda password con cui chiunque potrebbe ancora autorizzare. L'hashing della password clientide significherebbe anche che se qualcuno accede al database, quella persona sarebbe in grado di accedere a tutti gli account.

Qual è un modo per autenticarsi in sicurezza su HTTP? Ho il pieno controllo su client e server, quindi non c'è nulla che non sia possibile.

    
posta Ieuan 26.01.2015 - 10:49
fonte

2 risposte

1

Puoi creare uno scambio Diffie-Helman tramite l'API REST.

Prima il client richiede una serie di parametri e il server crea g , a e un ID per identificarli nella cache dei server. Invia quindi g , g^a e ID al client.

Quindi il client può generare b e calcolare g^(ab) ed estrarre una chiave da quella per crittografare la password. Il client invia quindi g^b la password crittografata e l'ID al server.

Il server può quindi ottenere a dalla sua cache in base all'ID e calcolare g^(ba) ed estrarre la chiave per decrittografare la password. Dopo queste normali operazioni di salatura e di hashing si dovrebbe fare per memorizzarlo nel DB e verificarlo.

Gli ID dovrebbero essere validi solo per un breve periodo.

Questo è comunque vulnerabile agli attacchi MitM attivi.

Per aggirarlo è possibile firmare le risposte del server con una chiave privata la cui chiave pubblica è nota al client.

    
risposta data 26.01.2015 - 11:01
fonte
1

Hai esaminato il meccanismo di autenticazione del digest?

È meglio che cancellare utente / password su HTTP. Tuttavia, ci sono alcuni problemi di sicurezza (come MitM attacker potrebbe dire ai client di utilizzare l'autenticazione di accesso di base o la modalità di autenticazione dell'accesso digest legacy RFC2069), ma se si ha il controllo del client è possibile superarlo.

link

    
risposta data 26.01.2015 - 14:52
fonte

Leggi altre domande sui tag