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


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.

1 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.

  • Thank you for your answer :), please see my update to your question... I will use SSL, I dont know how it didn't cross my mind earlier. Anyway, I still would like to use my SALT + RANDOM STRING in combination with SSL. I hope this can't do any wrong. But one thing still interests me, why would none of my "tricks" do any good? Wouldn't it add work to cracker if he would have to guess not only salt, but also how is salt combined with random string?
    – Buksy
    Commented Sep 18, 2013 at 6:57

You must log in to answer this question.

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