utente / pass auth vs hmac firmato per REST API

Question

utente / pass auth vs hmac firmato per REST API

#1 da (2 voti)

5

So che entrambi impediscono l'utilizzo delle API RESTful. L'API firmata Hmac è comunemente usata rispetto all'altra. Ma penso che l'utilizzo della coppia di utenti / pass per l'autorizzazione sia più sicuro, ecco il motivo:

Per firmare un'API utilizzando hmac è necessario un segreto condiviso tra client e server. Quindi il server DEVE memorizzare il segreto in un formato leggibile dal computer (reversibile). Se il server viene danneggiato (non si tratta di un piccolo evento di probabilità), tutti gli utenti sono in pericolo.
Durante l'utilizzo di user / pass per autorizzare il client, il server può salvare la password del client con hash (con sale) nel database. Quindi è inutile dopo il furto. Inoltre, usando tls / ssl per proteggere la password durante il trasferimento, non c'è attacco MITM.

Quindi la verità è che la maggior parte delle aziende usa hmac signed api. Qualcuno potrebbe dirmi cosa ho perso?

rest authorization

posta user23832 31.03.2013 - 07:44

fonte

1 risposta

Leggi altre domande sui tag rest authorization

Il server di posta (sendmail) invia spam a persone innocenti Qual è l'impatto sulla sicurezza del cambiamento di PSLanguageMode di PowerShell?

score 2 · Accepted Answer

Ecco alcune cose a cui pensare:

Per le app mobili: hai memorizzato la password dell'utente sul dispositivo? A quel punto aggiungi rischi nel caso in cui il dispositivo venga rubato. Se utilizzi una qualche forma di autenticazione basata su token, memorizzi il token e non la password - dato il modo in cui gli utenti riutilizzano le password, qualsiasi possibilità di ridurre la possibilità di esposizione è buona.
Non definirei inutili gli hash delle password salate: possono comunque essere interrotti finché viene preso il sale. A seconda di come viene eseguito l'hashing, anche salato, è probabile che un aggressore abbia un alto tasso di successo.
A meno che l'applicazione chiamante non abbia bloccato il certificato, non assumere la sicurezza dagli attacchi MiTM. Sebbene possa richiedere circostanze insolite (CA compromessa, CA che rilascia cerattori di firma, ecc.), Può (e ha) successo.

Tuttavia, per capire la risposta giusta, dipende dalle minacce specifiche che un servizio sta affrontando e quali sono i rischi considerati più importanti.