How difficult is it to crack salt portion of hash

Question

I write mobile application and I need to authenticate users against server. Server's side is written in php. I can't use cookies to store SID (Session ID), so I decided to send it at every request using GET method.

Later on, I decided that sending the same SID everytime is not secure enough, so I decided to use new string at every request. Server and Mobile client have stored same random string (let's call it salt). At the end of every request, server sends random string to mobile client and at the next request, mobile client sends to server hashed version of salt + random string. Server creates hash from salt + random string itself and compares it to one received from the mobile client to authorize it.

Now my question is:

1. If there would be a man-in-the-middle attack, how difficult it will be to crack the hash and find the salt portion of hashes?

2. How could I make it more difficult? (e.g. not using salt + random string formula, but salt_1st_half + random string + salt_2nd_half or hashing string multiple times based on length of username or other "tricks")

PS: I plan to use php's crypt function with blowfish algorithm at server

EDIT

I decided that sending the same SID everytime is not secure enough

Why? Because I will transfer some sensitive user data (actual location,..), and anyone who would capture SID could sipmly change this data, or use current SID to pretend he is someone other and could get other sensitive data from application (and it wouldn't be any bug or application error, because regular user with that SID would have access to this data). This is why I decided to change SID after every request and add some calculations and validation of SID.

Answer 1

If your "random string" is really a "random string", then none of your tricks can do any good. For that matter, the salt won't make things better either. Neither the use of bcrypt (what PHP calls "crypt with Blowfish").

Indeed, all the games with salts and iterations are just ways to cope with the inherent weakness of passwords. Passwords are weak. They cannot help being weak: they fit in a human mind. So as long as human users are, say, human, we must deal with passwords, and since passwords can be (for most human users) brute-forced, we must apply "tricks" which make the attack harder. The two main tricks being slowness (making the hash function inherently expensive through many iterations) and salts (to prevent parallel attacks and precomputations). I have written extensively on the subject there.

However, if you have random strings between a computer and another computer (smartphones are computer), then no human, then no problem. A sufficiently long and sufficiently random strings defeats brute force by its sheer randomness. Salts and slowness do not bring any additional security: it cannot be brute force, period.

(Or, said otherwise, if your random string can be brute forced, then you are doing it very wrong.)

It all boils down to this sentence of yours:

Later on, I decided that sending the same SID everytime is not secure enough

Why ?

Simply, why ? Why would it not be "secure enough" ?

There may be good, rational reasons. But you cannot make anything of value, in the domain of security, if you don't take the time to think your requirements through. Define your security: your goals, the attacker's goals, the attacker's powers, the assets at stake...

---

Anyway, if the communications between the application and your server need any kind of confidentiality or integrity or authenticity (I suppose this is the case, since you bother with authentication), then there is no escaping it: use SSL (also known as "HTTPS"). No SSL, no real security. But with SSL, things are fine. You can send your "random string" (which really is a custom session cookie) as is, it won't be intercepted by third parties, active or passive.