Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Unfortunately, you're not going to be able to guarantee with 100% certainty that the phone number reported to the server is the one it's coming from. The reason is that the client code can be reverse engineered, regardless of what you do. There are some things you can do however to make it a little more difficult, although it is important that you don't depend on this to be 100% secure. If you need 100% assurance, then you need to have the app authenticate to the server through traditional means.</p> <p>The way that I would do this, is embed a token in each copy of the client that gets released, such that each client has a different token. The token should have extremely large entropy (such as a 128-bit or greater integer), and you should keep a list on the server of tokens you've issued with the phone number of the device, so you can check them for validity. Require re-installs of the app to use a new token, and blacklist the previous token so it can no longer be used. The UID can be used, but be advised that it can easily be spoofed by a rooted device.</p> <p>Submit this token to the server each time and ensure that the phone number the app claims to have never changes. To make it harder for reverse engineers to find the token in your code, you can <code>xor</code> it one or more times with additional tokens, and you can also lay out a bunch of fake tokens throughout the code that are blacklisted on the server. </p> <p>You can also encrypt it with a secret key that is retrieved from the server so that the embedded token must be retrieved by an RE during live interaction with the server. Again this in no way <em>guarantees</em> that the token won't be found and changed/stolen, but it raises the bar for potential reverse engineers.</p> <p>To prevent someone from sniffing the wire and obtaining and/or tampering with your token, or from using a proxy like <a href="http://portswigger.net/burp/" rel="nofollow noreferrer">Burp Suite</a> to capture/tamper with it, you should use an <a href="https://en.wikipedia.org/wiki/Hash-based_message_authentication_code" rel="nofollow noreferrer">encrypted HMAC</a>. If you've never used an HMAC before, be advised that unless you encrypt it, it only provides authentication and integrity, <em>not confidentiality</em>.</p> <p>EDIT:</p> <p>Should also add, that you should <a href="https://stackoverflow.com/q/2531187/2062384">run your code through an Obfuscator</a> before you deploy it. This won't obfuscate the token, but it will obfuscate the decompiled code so it looks like gibberish to the RE. This forces the RE to use the byte code/assembly code from your app, which is much, much harder.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload