should I store an encription key as hardcoded in m

问题:

I plan on using One-Time Password encription for the comunication between the server and the client(which is a mobile app). But I need to hardcode the key in the mobile App. So all my mobile Apps installed by different users will have the same key.

How easy is to reverse engineer on the builds for Android and iOS and extrat the hardcoded value?

some other infomation about the security I plan: I plan also to add extra security by sending each user an SMS with a 4 digit number that will be used to sign requests. This way I can assure that the user is who pretends to be.

I send over the internet the user's position, his phone number(once), his name(once).

What do you think about my ideea, and what would you recommnd?

回答1:

Your design has many security holes in it. Seriously, just use SSL with basic authentication. It's battle tested and more than sufficient for the use case you are describing.

回答2:

Generally, if you have to ask questions about designing your own encryption scheme in production code, you shouldn't be designing your own encryption scheme in production code (and you should never hard code a one time password into an app, as that implies it's being used more than one time).

Two factor authentication is good, but the actual encryption you use should be something fairly well known. If you're looking to embed a key of some kind into the app, you might want to look into a public key cryptography scheme, like RSA. An encryption suite like SSL is probably the appropriate system to use here.

回答3:

FYI, it is extremely easy to reverse-engineer out the hard-coded value from iOS or Android, in different ways:

1. Static analysis: Using static analyzing tools such as IDA Pro reveal a wealth of information about a binary. Similarly, the standard *NIX command strings shows every string contained within the binary.

2. Runtime analysis and debugging: Tools such as GDB can show the internals of an app as it is running, allowing the user to set breakpoints, read/write registers and data locations, and otherwise dig around in the program.

3. A network proxy: Simply by specifying a network proxy in the system settings application to a laptop hooked up to the same local network will allow the laptop to view EVERYTHING that the device sends to and receives from the server. Unless this data is encrypted before it is sent or after it is received, the user will be able to determine what the key is.

The main thing to keep in mind is this: no matter what you do to try and hide the key from the user, with enough time and effort, they will be able to figure it out.

回答4:

How easy is to reverse engineer on the builds for Android and iOS and extrat the hardcoded value?

Very easy.

sending each user an SMS with a 4 digit number that will be used to sign requests

It is too complicated for users and should be used only if it really necessary(for applications with strong security requirements)

First of all: use an SSL-encrypted connections(HTTPS).

Also you can, for example, get a key and sessionId from server for each connection. Server will store the sessionIds and keys in some storage...

回答5:

On iOS you could store your key in the keychain.

However, I'm not so sure about your single key for everyone strategy. Isn't it possible for you to authenticate your users with a username and password (or SMS authentication for that matter) and susequently generate a unique user key for them. You can store this key in the keychain for future reference.

And use a secure connection! (https?)

回答6:

Here's a high-level suggestion:

1) If (keychain is empty) generate a random password, perhaps with base64 encoding
   If (keychain is not empty) you must have already generated a password from one of your apps, so just use the one in the keychain.
2) If from 1) (keychain is empty) store that new random password in the keychain

回答7:

It's easy to extract an encryption key from an app if it's just left in the binary in plain text. You need to hide the key in code, or inside another file.

For example, if hiding the string in code, instead of just doing something like @"my secret key", build the string using some non-standard way, maybe store 10 strings, and pick one letter from each one, concatenate them together to form your actual key.

Another way is to hide the key inside another file, say an image. If you can pick your encryption key, pick a specific set of bytes out of an image that you use in the app.