9

I opened my Amazon iOS app for the first time in several months today, and was able to go straight through checkout (where I was able to view and update my address) without being asked to re-auth. How is it that possible while still being secure, as well as PCI compliant?

  • what's the risk? someone buys something with your account and has it sent to your house? you can return such things. doing something new like adding an address should force a re-auth... – dandavis Jun 1 '17 at 2:55
  • @dandavis you can update the address to an anonymous PO box and order product to it using the user's payment method. The app didn't stop me from doing that. The only time it asked for re-auth is when I clicked to view my account. I find it odd and wondered why it was ok to checkout and update address but not ok to view account information. Download the app if you don't already have it and see for yourself. – Andrew Schmitt Jun 1 '17 at 4:59
  • you can add new addresses without re-auth etc. but to prevent malicious activity amazon will force you to re-auth with your password when ordering for the first time to a new address. – architekt Jun 1 '17 at 6:59
  • @MartinFischer I was able to modify an existing address and it didn't seem to cause any alarm. But maybe I was mistaken – Andrew Schmitt Jun 1 '17 at 10:19
6

There are two specific security measures that help protect against the session-hijacking-and-place-fraud-order attacks that you are worried about:

  1. The authentication tokens can be tied to the device, because the mobile app has easy access regarding the (mobile) account and device-specific ID (UDID) the auth token can be easily revoked if it is used for the wrong device, or in the wrong context. That isn't technically a foolproof restriction because the actual service is happening over HTTP calls (which can be "spoofed" by a malicious user), but this means that actually taking advantage of a stolen auth token will require things like: the auth token, the device UDID (and potentially more identifying information), and detailed knowledge of the API calls used by amazon to place orders. The risk is definitely low.
  2. The other protection is that amazon doesn't just let you change addresses. Even if someone gained access to your account they can't just place an order to themselves. A general security measure amazon has had in place for a long time is that if an order is sent to a new address you must re-enter any stored credit card numbers. This makes it impossible to send yourself stuff if you gain access to someone else's account. You could get around this, of course, if you also had access to their credit card information, but as we all know, at that point in time the malicious user wouldn't bother using your account to place the fraudulent order.

So in short, the actual risk to amazon for doing this is very low, and the potential lost revenue due to making people log back in is (I'm sure) much higher, which is why they let long lasting sessions persist on their servers.

It's worth pointing out that there is more at stake here than simply fraudulent orders. This one is worth a read:

https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/

4

Security is not a binary proposition; that is, things are not "secure" or "insecure", but fall somewhere on a security spectrum.

Thus, someone at Amazon has determined that keeping mobile sessions alive for several months, and not requiring a reprompt for checkout, is secure enough. From their perspective, this probably is a balance between the (very real monetary) cost of forcing users to re-auth and the (very real monetary) cost of users' stolen phones placing fraudulent orders. I suspect they also have additional fraud detection in place that will flag suspicious orders, reducing the cost of a stolen Amazon-authorized phone.

I'm not very familiar with the specifics of PCI-DSS, but I don't think it has any provisions that would apply in this situation.

  • Thank you for your response. You would think something like checkout, and updating the address, would require a simple re-auth at least. A thief can change the address to a PO box and rob the victim easily. What's even weirder to me is that you have to re-auth to view your account, what's the point? Other than to protect modifying the CC data directly? PCI-DSS is always ambiguous, but section 8 does make mention that idle sessions should expire in 15 minutes. They don't make mention as to whether or not this includes native apps on end-user devices. – Andrew Schmitt Jun 1 '17 at 5:02
  • 2
    @AndrewSchmitt: DSS sections 7-9 is about access by merchant including partner/outsourced/etc staff and in particular all of 8 "[does] not apply to accounts used by consumers (e.g., cardholders)." DSS as a whole is intended only to prevent disclosure of card accounts to unauthorized (and presumed malicious) outside parties; it is not intended to prevent unauthorized or mistaken transactions actually done by the known merchant which are handled by other parts of the payment system, mainly chargebacks. – dave_thompson_085 Jun 1 '17 at 7:28
  • @dave_thompson_085 Wow that helps a lot thank you for clarifying. – Andrew Schmitt Jun 1 '17 at 10:22
1

Security is a relative concept. Balance is often found somewhere between convenience and threat-perception (both are subjective domains!).

In general, I'd say Mobile Apps that maintain an authenticated sessions for long periods are not "as secure as they could be" if they expired those sessions more frequently.

However, it's useful to examine the two main threats that session-expiry is a protection against:

  1. Certain (not all) shared use of device scenarios
  2. Session hijacking

Mobile devices being largely personal devices, mobile apps have relatively less threat exposure than say a browser tab on a laptop/desktop system - where another user could (with greater probability) use the system, open a tab from history and find an logged in account.

Other protections exist against session hijacking - such as the use of per-conversation nonces and client-IP-change-detection (controversial). Whether a specific app uses any protection against this or not is an important but often missing detail. :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.