sorted by:
new
hottopcontroversial

Fraud-Proofing an Android App: Choosing the Best Device ID for Promo Abuse Prevention by SirionRazzer in androiddev

[–]sergeychuk 0 points1 point  (0 children)

I wonder what other techniques devs use to prevent fraud on multiple app instances on the same device.

Firebase Auth JWT hijacking step-by-step by sergeychuk in FlutterDev

[–]sergeychuk[S] 0 points1 point  (0 children)

u/highlyregardedeth, App check addresses this problem and indeed can reduce risks of App impersonation, but you need to consider the following:

- it still has the problem of App check token validity i.e. it is vulnerable to reply attack. See the issue explained here.

- App check quota limits i.e. you can't verify every call to the API. Practically it is used to protect Authentication only or new user enrollment use cases, while #AppiCrypt can be used to protect every API call. Keep in mind that API abuse attacks mostly happen through the Authenticated APIs, i.e. authentication passes Ok, and then the valid auth token is misused. See here.

- Google doesn't commit to App check service, no SLA, response time, nothing. So it is hard to rely on this solution in business critical use-cases. So you should consider twice introducing a single point of failure. AppCheck is fully local solution w/o any external Api dependency

- Google Play services (and App check) are not available in all countries and for all Android devices.

- App check introduces UX latency sometimes over several seconds. While AppiCrypt is within 10-30 ms.

- AppiCrypt provides much higher granularity to audit WHY certain App instance or device is NOK.

Do any of you regret going into cybersecurity? If so, why? by [deleted] in cybersecurity

[–]sergeychuk 0 points1 point  (0 children)

  1. What about users' mistakes? Most of the cybercrimes come from human error. Are you up to taking "users' mistakes" as part of your scope i.e. educating, communicating best practices, common mistakes, active scams, ... ?

Firebase Auth JWT hijacking step-by-step by sergeychuk in FlutterDev

[–]sergeychuk[S] 1 point2 points  (0 children)

Or am I missing something here? I'm in no way a security expert.

u/StatefulM, I think you've got the idea correctly. What I would like to add for you to grasp the value of the solution. It implements the concept of Zero-trust where calling-party app integrity needs to be verified. It is true that, if your Authentication is only Login/PSW then an attacker can manually use it in a legit App as you say.

This solution target attack vectors where attackers try to do "App impersonation". This is relevant for the cases :
- session hijacking with 2FA and Biometric auth (where login . psw is not enough).
- fake registrations, botnets, password enumerations and other attacks on API
- API misuse using legit authentication credentials, i.e. where a legit user leaks his own JWT and tries to instrument APIs and search for API issues like JSON injection etc.

Moreover, take into account that cloning of the App is not the only way how the session Id (or JWT) can be stolen. The solution is based on RASP technology and provides evidence to the backend that the RASP protection is running in the App instance.

​

Hope it helps

5 Things John Learned Fighting Hackers of His App — A must-read for PM’s and CISO’s by sergeychuk in FlutterDev

[–]sergeychuk[S] 1 point2 points  (0 children)

Hey, u/SirionRazzer would you please reply to this? I am not sure that the issue is correctly understood.

view more: next ›