Scambi di sicurezza durante la progettazione di un'API di servizi Web mobili

0

Non sono un esperto di sicurezza ma voglio chiedere dei compromessi in un'API di servizi web che sto progettando per le app mobili.

È un'API che tiene traccia delle posizioni degli utenti, quindi sì, i dati sono ragionevolmente sensibili. Tuttavia, verrà utilizzato dalle applicazioni mobili, quindi credo che la maggior parte delle volte verrà eseguito su reti meno inclini alle intercettazioni.

L'app manterrà le credenziali dell'utente (login e password) crittografate in un database locale. Non sono sicuro di quale sia lo schema di crittografia da utilizzare.

Si accede all'API tramite HTTPS.

Sto considerando un token multiuso di lunga durata o token di una durata breve di breve durata. Più corto (lunghezza) è il migliore, al fine di ridurre l'utilizzo della larghezza di banda. Tuttavia, non sono a conoscenza di come un token debba essere generato correttamente, nel caso in cui alcuni dieci o più byte casuali non siano sufficienti.

Chiedo informazioni sui compromessi, quindi mi piacerebbe ricevere consigli su quanto sia sicura questa strategia nella maggior parte dei casi, ad esempio in situazioni che hanno maggiori probabilità di accadere. Tuttavia, se senti che trascuro i rischi, sentiti libero di enfatizzarlo e suggerire alternative (anche se sarei curioso di sapere fino a che punto potrei arrivare con i compromessi se i dati fossero meno sensibili).

    
posta Piovezan 06.03.2015 - 20:36
fonte

1 risposta

1

The app will keep user credentials (login and password) encrypted in a local database. I'm not sure which encryption scheme to use though.

Non crittografare la password, cancellala. Idealmente usando qualcosa come bcrypt .

I'm considering either a long duration multi-use token or short duration one-time tokens. The shorter the better, in order to reduce bandwidth usage. However, I'm not aware of how a token should be properly generated, in case some ten or more random bytes is not enough.

Il sistema più comune che ho visto utilizza qualcosa come Token Web JSON . Quando un utente autentica se stesso, crea un token con informazioni che identificano l'utente (ad esempio l'ID utente) e una data di scadenza. Firma e restituisci il token.

Ogni volta che il token viene utilizzato per autenticare un utente, verificare la firma, confermare che la data di scadenza non è stata superata, quindi utilizzare l'ID utente per identificare l'utente.

    
risposta data 06.03.2015 - 21:27
fonte

Leggi altre domande sui tag