0

I'm not a security expert but I want to ask about tradeoffs in a web service API I'm designing for mobile apps.

It is an API which tracks users' locations so yes, the data is reasonably sensitive. However, it will be used by mobile applications, so I believe most of the time it will run on networks which are less prone to eavesdropping.

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

The API will be accessed over HTTPS.

I'm considering either a long duration multi-use token or short duration one-time tokens. The shorter (length) 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.

I'm asking about tradeoffs so I'd like advice on how safe is this strategy in the majority of cases i.e. in situations which are more likely to happen. However if you feel I'm overlooking the risks feel free to emphasize it and suggest alternatives (though I'd be curious about how far I could get with the tradeoffs if the data was less sensitive).

  • Can you clarify what the token is for? A token for use in authenticating API calls in lieu of resending the credentials with each API call? – gowenfawr Mar 6 '15 at 19:40
  • Yes, exactly. I wasn't sure of how such token would be called. Is it an authentication token (and this scheme token-based authentication)? – Piovezan Mar 6 '15 at 19:41
  • I think you'd call that an Access Token, Session Token or API key. – gowenfawr Mar 6 '15 at 19:59
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.

Don't encrypt the password, hash it. Ideally using something like 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.

The most common system I've seen is using something like a JSON Web Token. When a user authenticates themselves, create a token with information identifying the user (e.g. the user ID) and an expiration date. Sign and return the token.

Every time the token is used to authenticate a user, verify the signature, confirm the the expiration date hasn't passed, and then use the user ID to identify the user.

  • Could you provide some context on in which scenarios those measures would improve security? – Piovezan Mar 6 '15 at 20:56
  • @Piovezan hashing the password or using a JWT? Or both? – citruspi Mar 6 '15 at 21:01
  • Both if possible. I'm guessing that hashing would improve security on the client side and in case a server database is invaded, but I'm not sure about the token. – Piovezan Mar 6 '15 at 21:03
  • @Piovezan You would hash a password instead of encrypting it because it's a one way function. If your database is compromised and the attacker gets the encryption key, he can decrypt all the passwords. If you hash it... – citruspi Mar 6 '15 at 21:03
  • @Piovezan as far as the random token vs JSON Web Token, I don't think it makes a major difference with your use case. I like JSON Web Tokens because they're more flexible - you can include as much data as you want in the token itself. So you'd include the expiration in the token, and then validate it when the user authenticates as opposed to querying a database to get a random token's expiration date. Here's a good article on JSON Web Tokens. – citruspi Mar 6 '15 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.