2

Note : I'm posting this for a friend of mine who doesn't speak english very well... Well, I'm not so good myself, so excuse me in advance !

My friend's developing a Smartphone application, and they would like to have some advice to protect the IDs of the database.

The only idea we've got so far consists in :

  • All communications are done using asymmetric encryption (private key on the server)
  • The credentials are stored, encrypted, client side and the decryption key is stored server-side

When the application would need to use the credentials, it would ask the server for the decryption key.

Would that be secure?

Wouldn't we need to authenticate the client? I guess if we don't, it would be the same as sending the decryption key as plain text.

3
  • 1
    Are these credentials different for each user? If so, that's not bad. If they are the same for all installs, what's to prevent a fake client from just handing the encrypted password to the server?
    – crovers
    Sep 29, 2016 at 13:30
  • 1
    @crovers Database's ID are the same across all installs. And in fact, nothing, as even the request for the decryption key could be faked, and the credentials could be decrypted. I guess we just came up with an obfuscated way of doing bad things ^^'.
    – Katenkyo
    Sep 29, 2016 at 15:08
  • When designing client-server software, you need to always remember that the client is running in hostile territory and it may have been turned traitor - only the server is trustworthy and it must verify everything the client says or does. Never do client side authorization or authentication or validation (if you do client side validation (for field values, for instance), this can be good for usability, but you must re-do them on the server side too)
    – crovers
    Sep 29, 2016 at 20:21

1 Answer 1

3

It smells like security by obfuscation. If the credentials are stored client side, and if the decryption key is sent to the client, an attacker could install the application on an emulator and through a debugger obtain the decryption key and the credentials. Ok, it is far from being simple but all depends on the value of the database.

A more common (and more secure) usage is to build a multi-tier application: the front app (on the smartphone) does not know the database but only communicate with a server. Here we authenticate the client with user+password, certificate or whatever... And only the server actually communicates with the database. That way the database credentials are never present on client and are never exchanged except on the server-database connection.

TL/DR: you proposal would actually make things harder for a possible attacker that would want to steal the database credential, but does not prevent all possibilities. Use multi-tier design for a really secure solution.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .