70

You cannot. As soon as the user has the mobile device and your application, nothing stops him from decompiling your application, understanding how it works & what data it sends, and replicating it. They can even cheat using some contraption that rotates the phone around and make your application believe it's a human that is using it. They don't even ...


24

While I generally agree with ThoriumBR's answer, there are some things you can do. For example, you can analyze the user's behavior for discrepancies, such as: Obviously Replayed Data For example, a user could act in a desired way, then capture the sent data and replay the data again at a later time. This can be determined quite easily, given how the ...


24

While I agree with the other answers, I find there are a few pragmatic things that are overlooked there. Full disclosure: I work for a company that builds obfuscation / protection software for mobile applications. Full, unbreakable protection is not possible for an app running on an attacker-controlled device. However, software exists that aims to raise ...


8

It's not malware. It's what wikipedians call vandalism. You can see the revision you saw here, complete with the image you describe. It was up for about three minutes. At this point, you should ignore it. If you come across vandalism in wikipedia in the future, you can report it, or simply fix it, by rolling back to the appropriate revision.


6

It is somewhat possible. Simply send the recorded data off to a remote server that does the pattern checking. Make sure there is a delay between observing a correct pattern and the reward. It will be very difficult to figure out exactly what pattern is being matched. If you combine this with heuristics that detect replayed activity and ban offenders, there ...


4

Google Maps uses your wifi for location services. So, no, it will not always work. In fact, to answer your question, you should read how Android Location Services work to know what factors are used and what you would need to override. Police do not need to use the phone's location services. The mobile provider can use their towers to locate you via the ...


3

I suspect this internet usage requirement have more a data-collection reason than validation. It can work without internet connection, and I don't think scanning other people's QR-code would be an issue. The QR-code on your app should have your account number and timestamp. It can even store tickets' serial numbers for offline usage, and only create the QR-...


3

In my understanding this means, that the security relevant implementations should be centralized or included as isolated plugins/libraries. This ensures, that security relevant functionalities can be easily maintained and updated. E.g. when you have your crypto methods distributed all over the app, it is much harder to keep an overview and update them ...


3

No, it’s not as insecure as 1FA. 2FA is about making life inconvenient for an attacker, not for yourself. With 1FA, anyone anywhere in the world can access your bank account if your username and password leak or can be guessed. 2FA means that the attacker has to have your phone, or another way to access your text messages if your second factor is SMS (which ...


2

More frequently in the last years, the suggested secure solution to this problem is called remote attestation. In short, this means running the security-critical parts of your application in a separate area of the CPU that guarantees its integrity (through key escrow on the hardware) and allows a remote server to confirm it. As far as I know, there's no ...


2

There's a bit of an incorrect assumption at the heart of this question, namely: The type of authentication used by the service you're exposing doesn't really impact the security of services around it. If you open a port in your firewall so that external traffic can reach your REST service, the type of authentication between clients and that service doesn't ...


2

The typical assumption to make with physical security is that if someone has physical access to a device and it is not off and encrypted, then they can access all of the unencrypted data and run arbitrary code on the device. You can try to make it more difficult to exploit, but a dedicated adversary will likely succeed nevertheless. You also need to ...


2

Even in that particular scenario, it's still two factors: a PIN to unlock the phone and access to the device. This combination protects the bank against a range of threats that regular passwords do not. Stealing the phone is not enough to impersonate you. Knowing or guessing the password for the bank website (through phishing, an interception or man-in-the-...


1

There is no single threat model for "mobile security", any more than there is a threat model for "workstation security". Your threat model depends on your circumstances. If your starting point is that the attacker has root access to the underlying operating system then you've pretty much lost. There are things that you can do to make it ...


1

A hash of the passenger account number, IMEI and time stamp won’t work, because the bus driver’s app has no way to independently verify the account number or IMEI for the phone on which the scanned image is being displayed. What you need to do is include in the hash a random key that changes very frequently, which both the customer’s app and the driver’s app ...


1

The app should consume an RSS feed (https call) from the server but there is no need to have authorization in place. The output does not depends on the user. In this case I'd consider the need for an app at all... But that's not important. I was trying to look around for ways to have some form of security for my server to be sure that the caller is my ...


1

On your phone, yes, 2FA that makes use of your phone is a little silly. But, 2FA is not meant to protect from an attacker who has your phone. The whole idea of using a phone as a 2FA device, is the assumption that only you will have your phone, or at least only you will be able to unlock it or view codes on it. Breaking that assumption obviously breaks the ...


1

The apps do not share information. They use an ad network to display ads to users. Many apps will use the same networks, and those networks are also used by websites, so the network knows the user's behaviours on the apps and the websites that use them. That way the network shows relevant ads to users. The apps and websites don't actually know what ads are ...


1

I found it rather important to say that not all apps are purely created with Java and XML, there are people who like to convert their website into an android app, in fact that's just a copy of their website displayed on 5" screen., not only because it's cheaper but also because it saves them time. Some suggestions, Is it a converted app? (in case it is ...


1

On top of all the other answers mentioned, a "simple" way to protect against hacking is simply not having the logic inside your app. In the app, you only want to do two things. Read out data Display data The moment you try to process data on the device, you're doomed, and the app will be hacked. Instead, send all the raw data to a server (obviously this ...


1

Others have answered regarding software protections, but an attack can occur at even the hardware level. For example if a phone has an accelerometer IC that is on the PCBA, most of these sensors would transmit over a standard SPI or I2C bus with the raw data and no sort of encryption. It could be possible for an attacker to remove the existing sensor and ...


1

You're right. The mobile app developer is incorrect. There is NO reason to share the SecretKey. In fact they should not ship it with the application. TL;DR; There's an engineering principle that applies to security here - KISS or keep it simple, sir. Reading AWS documentation and request security, it's clear they go though elaborate hoops to keep the access ...


Only top voted, non community-wiki answers of a minimum length are eligible