2013-02-08 9 views
6

Ho creato un'applicazione che funge da ponte tra 2 diverse API - WebEx & Servizi Web di Exchange - e Email. Un utente invia un invito del calendario a un indirizzo email speciale, l'app analizza l'ICS e crea una riunione WebEx, quindi si connette a Exchange Web Services e inserisce le informazioni di invito WebEx nell'invito originale.Archiviazione sicura delle credenziali API che devono essere utilizzate come testo semplice

Questo è stato creato poiché WebEx non ha l'integrazione Mac Email/Calendario.

Il problema è che per utilizzare API WebEx e API di Exchange, ovviamente ho bisogno di credenziali per entrambe le API. Conservo in modo sicuro le credenziali con crittografia AES 256 bit nel DB, ma per accedere alle API, ho bisogno di credenziali di testo in chiaro originali (nessun supporto oAuth o token nelle API). Sono trasmessi in modo sicuro su SSL, ovviamente.

Il rischio per la sicurezza non consiste nel far rubare le password in quanto le chiavi di crittografia sono archiviate in modo sicuro. Il problema che sto cercando di affrontare è il fatto che i clienti temono che le loro credenziali aziendali siano ora archiviate in modo da consentire a qualcuno che ha accesso a quelle chiavi - io o qualcuno del team di sviluppo - di decodificare le loro informazioni e ottenere l'accesso alle credenziali .

Il valore dell'app è ottimo: consente di risparmiare un sacco di tempo, ma come posso proteggermi da questa paura, pur continuando a far funzionare questo approccio?

+0

Il server chiama casa e trasmette le credenziali? In caso contrario, non vedo perché i clienti pensino che i dati che inseriscono e archiviano sul proprio dispositivo siano disponibili a chiunque altro. –

+0

Le credenziali vengono memorizzate, crittografate all'interno del database utilizzato dall'app Web. Quando viene ricevuto un messaggio di posta elettronica, questo viene elaborato, quindi le credenziali archiviate vengono utilizzate per agire a nome dell'utente con le API WebEx ed Exchange. –

risposta

0

La realtà è se il codice ha bisogno di inviare le password quindi se uno sviluppatore ha il codice sorgente di e le password criptate avranno accesso alle password di prova pianura. L'unico modo per aggirare questo è negare al team di sviluppo l'accesso alle password crittografate e negare a chi ha le password crittografate l'accesso al codice sorgente. Lo fai mantenendo il team di sviluppo lontano dal database di produzione.

Il rischio per la sicurezza è che si ha accesso al database di produzione che memorizza le chiavi. Eliminare quell'accesso e la loro preoccupazione dovrebbero essere eliminati. Fornire un'utilità (desktop o basata sul Web) che può essere utilizzata per configurare le chiavi, una buona idea comunque poiché tali password dovranno essere modificate in futuro.

Fare in modo che il cliente crei un database e quindi indirizzare l'app al database tramite una modifica della stringa di connessione. Il cliente può utilizzare l'utilità per impostare le password.

+0

Sarebbe bello se fosse possibile identificare in modo univoco il proprio client di posta elettronica e utilizzare qualsiasi valore identificativo presente come parte della chiave ... –

Problemi correlati