Mitigate fraud with App Attest and DeviceCheck

RSS for tag

Discuss the WWDC21 session Mitigate fraud with App Attest and DeviceCheck.

View Session

Posts under wwdc21-10244 tag

6 Posts
Sort by:
Post not yet marked as solved
1 Replies
843 Views
In the WWDC 2021 session Mitigate fraud with App Attest and DeviceCheck it is said that: App Attest is supported on devices that have a Secure Enclave, but there are cases, such as app extensions, where isSupported will still return false. The documentation shows that the following Macs have a Secure Enclave: MacBook Pro computers with Touch Bar (2016 and 2017) that contain the Apple T1 Chip Intel-based Mac computers that contain the Apple T2 Security Chip Mac computers with Apple silicon I'm using a 2018 15" MacBook Pro containing a T2 Security Chip for testing, however, DCAppAttestService.shared.isSupported always returns false in native macOS or Catalyst apps. DCDevice.current.isSupported also returns false. The documentation for DCAppAttestService shows availability on "macOS 11.0+" and "Mac Catalyst 14.0+". It appears to have been added in the macOS 11.3 SDK included in Xcode 12.5. DCDevice shows availability on "macOS 10.15+" and "Mac Catalyst 13.0+". Although both APIs are available on the listed OSes, I only ever see isSupported == false. Are App Attest or DeviceCheck functional on any Macs? If so: Are there more specific Macs that support the feature (e.g., Apple Silicon Macs only)? Are there any additional steps that need to be taken to use them (e.g., changes to entitlements, provisioning profiles or distribution through the Mac App Store)? In native macOS apps, it doesn't actually appear to be possible to add the App Attest capability in Xcode under "Signing & Capabilities". If not, I think it would be good to update the documentation with this limitation since I'd expect them to work based on the availability being "macOS 10.15+" or "macOS 11.0+" for DeviceCheck and App Attest, respectively. I imagine most others would make the same assumptions.
Posted
by
Post not yet marked as solved
1 Replies
786 Views
We see appAttest (available iOS 14+) provides us 3 key features: if app instance is not modified, device is genuine apple device and payload is not tempered with. We also have deviceCheck Api (iOS 11+) which return 2 bits per device, as mentioned in documentation we can create different payloads for validation and different for updating the 2 bits. Apart from returning those bits in validation request, does this DeviceCheck APIs also validate 2 of the 3 above features i.e. app is not modified and the device is genuine apple device? If yes, what response from apple server to look for in successful validation of above 2 features and what response to look for in fraud cases or failure cases? Does isSupported in case of DCDevice.current hints the device is a simulator ? Can we get exhaustive list of cases where isSupported is false? Does DCDevice.current.generateToken fails only in case of modified app instance? Can we get exhaustive list of cases where above can throw error? Can modified app instance also able to generateToken?
Posted
by
Post not yet marked as solved
1 Replies
343 Views
Hello, We detected some fraudulent activity in one of my app. The user purchases the in-app product, makes use of the service, and then returns it immediately. And he repeats this process every day. We have done some actions to prevent this, but this process continues by using clone app creators. How is the return process going, is there no control in this regard? Normally, if a user buys the same product for the second time, I think that he should not return it anymore.
Posted
by
Post not yet marked as solved
1 Replies
272 Views
Hi there, I wonder what are some common reasons for the Order ID to be in valid... (Other than fake, randomly generated Order IDs, of course.) I have a customer sending me a receipt of a non-consumable item, but when I tried to look up the order using https://api.storekit.itunes.apple.com/inApps/v1/lookup/{order-id}, the response code is 1, indicating the Order ID is invalid. I was able to use the same method to fetch one of my own purchases (because what indie app dev doesn't buy their own stuff?) so I believe the method to look up by Order ID is tried and true. It doesn't seem like the user was faking a screenshot of the order. On the receipt screenshot, the customer purchased the item using Store Credits. Is it likely that the transaction was later marked as fraudulent by Apple, and therefore invalid? Just seeing if anyone has info on this. Thanks!
Posted
by
Post not yet marked as solved
0 Replies
140 Views
Hi, Is there a default timeout for the attestKey method? From doc: If the method’s completion handler returns the serverUnavailable error — typically due to network connectivity issues — it means that the framework failed to reach the App Attest service to complete the attestation Br, Johan
Posted
by