I'm making an iPhone/Android app for my website, users already have an account on the website and the app will allow them to login.

I don't have SSL on my website, but it's just a reviews website and no private data is transmitted, nevertheless, on a mobile phone it seems more dangerous to me as mobile phones are always using a wireless network. and people sometimes use the same passwords for several websites.

What I want to do is: The app hashes the password twice, with two hashing algos which are considered secure, and then transmits it so at least if someone sniffs the data he can only use use it for my website, or maybe other websites which use the same hashing technique. maybe even more then twice, according to what is appropriate.

Is this a good idea?

and also, are mobile networks vulnerable to this kind of sniffing attacks? is there commonly some kind of protection like an SSL-like relationship with the network provider when someone just sits in a restaurant and is provided with a connection?

5 Answers 5


Can people eavesdrop on mobile networks? Most definitely. Also your server is likely connected to the mobile network over the ordinary internet where people could eavesdrop. Also, people frequently use wifi connection from their phones (versus 3g/4g data connection) which again will go over the ordinary internet and is subject to many potential eavsedroppers.

Why not SSL? If you have your own domain, you can get an SSL certificate from a trusted signed CA (certificate authority) for free (https://startssl.com), which prevents eavesdropping/MitM attacks, etc.

There are problems with your scheme. E.g., replay attacks (eavesdropper replays the hash), MitM altering messages after authentication (e.g., replacing legitimate review with spam or a XSS vulnerability), firesheep, etc. You can improve on it marginally with nonces or timestamps, but again its far simpler just to use SSL than to try and reinvent the wheel.

You may think, I'm not dealing with credit cards why do I care if I'm unsafe. Maybe you have reviews and some spammer decides to steal credentials for many accounts to positively review their products. Or some script kiddie gets upset with a review and deletes all reviews they can from your site. Or your idea of a strong hash is sha-1 without a salt (e.g., you worked for linkedin) and someone captures hashes sent over the network and soon captures a million sha-1 hashes and brute forces them in parallel in a embarassing incident.

  • 3
    Since this is a client application, not a web application, even self signed is perfectly fine. You can just use a fingerprint of the cert to validate it. Aug 28, 2012 at 18:47
  • @CodesInChaos thanx for the tip, about the fingerprint, you mean I should hard code it into the application?
    – fiftyeight
    Aug 29, 2012 at 18:30
  • @dr_jimbob thank you very much, isn't there any disadvantage to the free certificate in this case?
    – fiftyeight
    Aug 29, 2012 at 18:39
  • 1
    @fiftyeight - There's no real disadvantage for free cert except it is only class-1 (tied to an individual who owns the domain not an organization) and lacks some fancy features (e.g., wildcard domains) or self-signed (except self-signed you'll have to verify the fingerprint yourself and roll an update if the certificate expires/changes and can't reuse the certificate for browser-based traffic to your site).
    – dr jimbob
    Aug 29, 2012 at 19:13

There's a phrase I want to teach you: "What's your threat model?" If you interact with security folks, I guarantee one of them will ask you at this some point. This question is a hint to you that you have not carefully thought through exactly what problem you are trying to solve.

When I read your statement "I don't have SSL on my website, but it's just a reviews website and no private data is transmitted, nevertheless, on a mobile phone it seems more dangerous to me", what I perceive is that you are not thinking carefully about security. You seem to be reacting based upon feelings and superficial impressions and emotional associations. That's not the right to do security. Instead, you need to take a level-headed look at the actual risk, brainstorm the possible mitigations to defend against those risks, and then figure out if they're worth it.

On your question, no, I don't recommend you do that funky password double-hashing business. Don't try to get too clever, and don't try to re-invent the wheel; many others have tried before you, and odds are that you will repeat a mistake they've already made.

There are basically two options that might make sense for you:

  • Use SSL. If you are concerned about the risk of eavesdropping and man-in-the-middle attacks, the right solution is to get a SSL cert and enable SSL. Faffing around with custom password double-hashing is not recommended.

  • Do nothing. Personally, I think a more reasonable answer is: don't bother with SSL. Don't worry about it. Do nothing special. You said there is no private data and the website is not important. If so, then using ordinary HTTP is fine. (I suspect this answer might be not-so-popular on this site: for security folks there is sometimes a tendency to try to make everything as secure as possible. However, that's not always the right answer in practice.)

Pick one, or the other. But don't try to do some weird custom thing. There's a reason why the standard solutions are, well, standard.

  • Thanx for the help, if I decide to do nothing, won't adding on top of that the hashing will, at worst, not help? I don't really see what damage hashing can do
    – fiftyeight
    Aug 29, 2012 at 18:31
  • @fiftyeight, it's certainly not a crazy idea; hashing is not without some merit. I just don't think it adds enough security benefit to be worth your time. Implicit in my answer is the assumption that your time has value. If your time has value, I suspect your time and energy might be better spent either (a) using to improve your site and add features that will delight your users, or (b) if you want to spend some time on security, deploying SSL. But you're free and encouraged to form your own opinion, based upon what you've read here!
    – D.W.
    Aug 30, 2012 at 5:20

It depends on what your goals are. If you are looking to secure the password transfer as an Android developer I can easily say it's far more efficient for you to simply enable https on your website and on the app rather than designing and implementing a hashing method. However, I'd implement a hashing method of some kind at least to store the password on the server so that if it gets hacked you don't leak password data.


If your security model is indeed avoiding a disclosure of the password to eavesdroppers, then some kind of hashing might do the trick. You will want to do it right, though.

If the user logs on the Web site (through the app) by simply showing a hash of the password, then this hash is sufficient for authentication. Someone spying on the line will learn the hash, and may thus log on the site as well. The hash value is password equivalent. If the same user has the same password on another site (that you don't know), then your hashing will have some benefits only insofar as the other site (that you don't know) did not have the same idea and used the same hash function as the one you are proposing yourself to use. If your site requires SHA-1(password) to log on, and the other site also requires SHA-1(password) to log on, then the attacker learning SHA-1(password) through eavesdropping will gain access to both sites -- precisely that which you wanted to avoid.

Solution is to make sure that your hash function is distinct from that of any other site. To do that, include the site name in the hash input. For instance, if the site name is www.example.com and the password is sdfl478gb9, then make the app compute SHA-1("www.example.com:sdf1478gb9"). Other sites may use different strategies, but it is highly improbable that they will use your site name (and if they did, then arguably they actively looked for trouble).

Of course, using SSL might be simpler. Especially since you control both the app and the server: you could create a self-signed certificate for your server and embed a copy of that certificate in the app, avoiding all the trouble with "established CA".

  • 1
    Would it not be better to use a random salt along with the hash, instead of the site name? This would also help thwart rainbow table attacks to get the original password.
    – Indy
    Feb 24, 2014 at 5:25

Personally, I would bite the $100/year to buy an SSL cert--it's not that much, and if you're concerned at all about security, it's well worth it. If someone sniffs a password and gains access to your site, they can use that to find other exploits, leading to larger compromises: things like possible sql injection to get other users passwords/hashes, email accounts, etc.

If you absolutely will not do this, then use a predictable value to salt with, like a timestamp. This way the hash is only valid for a short time, and sniffing it would not give permanent access.

<script type="text/javascript">
var timestamp = new Date().valueOf();
var hash = sha256(sha256(userpass)+salt+timestamp);

Send both the hash and the timestamp back to the server for comparison (php example):

if ($_POST['timestamp'] / 1000 - ts() > 60) {
    //throw error or exit, password was hashed more than a minute ago
if (sha256($userHashFromDatabase.$salt.$_POST['timestamp'] ==
    $_POST['hash']) {
    // Login successful -- do stuff
} else { 
    // login failed
  • You can get SSL certificates for cheaper than $100/year signed by a certificate authority; e.g., free from startssl.com if you don't need any fancy features. Also, md5 is broken for these purposes (even if a collision in the form of a time stamp may be difficult to force); at the very least use sha-2 (e.g., sha256).
    – dr jimbob
    Aug 28, 2012 at 18:18
  • Good point--I changed the hash in the example
    – Bryan Agee
    Aug 28, 2012 at 18:58
  • 1
    I don't understand why you recommend hashing the password on the client side. I'm having a hard time identifying any security value of that against any plausible attack that I am able to imagine. I presume you are familiar with Firesheep, session hijacking, man-in-the-middle attacks, and so on? Also, you are aware that by doing the hashing on the client side, the hash now becomes the password-equivalent, and any attacker who observes it can simply replay the hash and timestamp to the server to gain access?
    – D.W.
    Aug 28, 2012 at 22:31
  • 1
    @BryanAgee, actually, it doesn't, since your server-side code don't impose any requirements on the timestamp. Your code doesn't validate the timestamp. (And if you did try to validate the timestamp, you'd quickly discover that this is a swamp: many people's machines have clocks that are set wrong, sometimes ones that are wildly wrong. What are you going to do then? Block them from using the website? Not a practical solution.)
    – D.W.
    Aug 28, 2012 at 23:40
  • 1
    @D.W. - Yes the hash becomes the effective password, but at the very least the pre-hash password is not given as plaintext (though again; a simple cryptographic hash like sha256 is usually easy to brute force via GPU. Also local timestamp issues could be resolved if the timestamp nonce is server-generated (possibly with JS to keep up to date) when the page loaded and checked. But still this is rolling your own, vulnerable to several problems. In this case MitM where the fake site bypasses this scheme and asks/ records users' pw directly.
    – dr jimbob
    Aug 29, 2012 at 19:26

You must log in to answer this question.

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