iphone - verificación - no puedo desactivar autenticacion de dos factores

¿Cómo puede mi servidor autenticar de forma segura la compra en la aplicación de iPhone? (4)

Mire el diagrama de Apple para el modelo de compra del servidor .

En el paso 9, ¿cómo puede saber el servidor que realmente está hablando con un iPhone que tiene derecho a la compra, y que Eve no está reproduciendo un recibo obtenido deshonestamente?

El recibo puede ser válido, pero eso no prueba que el remitente sea la parte autorizada.

¿Hay alguna noción de un certificado de dispositivo en el iPhone que pueda usarse para firmar el recibo?

¿Hay alguna forma de vincular el recibo al dispositivo o vincular el recibo tanto a la cuenta de iTunes como al dispositivo, para que el servidor pueda validar?

UDID ya no funciona

La respuesta de Beniot es genial, sin embargo, en estos días, como menciona Joe D''Andrea, UDID está en desuso y la última vez que lo intenté, una aplicación que utilizó la llamada para obtener el UDID no pasó la validación durante la carga a iTunes.

Recibos de tiempo limitado como alternativa a los contadores de recepción

Para agregar a la respuesta de hloupyhonza, además de tener un contador de "solicitud de descarga" para un recibo en particular, puede limitar la validez del recibo por tiempo. Encontré cualquier cosa entre 12 y 24 horas razonable.

Este método también le permite al comprador usar la compra en cualquier otro dispositivo que posea, siempre que inicie sesión en la App Store con la misma identificación de Apple. Nota: Cada vez que se realiza Restauración de compras, Apple devuelve un recibo completamente nuevo (con los detalles del recibo original), lo que permite restaurar las compras más allá del límite de tiempo establecido para un recibo en particular.

Evitar los pirateo "fuera de la estantería"

Para evitar soluciones de piratería "en Google" típicas (mis datos muestran que esto constituye casi todos los intentos de piratería de IAP), utilizo una suma de comprobación (elija su algoritmo favorito, no importa a menos que quiera hacerlo hermético) de la siguiente concatenación:

cadena de datos de recibo json
Una clave secreta compartida
Código de estado de éxito de validación.

La aplicación verificará la suma de comprobación devuelta por nuestro servidor de validación. Sin embargo, esto no es hermético, ya que el hacker puede recuperar la clave compartida del binario de su aplicación. Pero ha impedido todos los ataques "estándar" hasta el momento y eso es suficiente para mi uso.

Creo que si no puede leer la ID de Apple del usuario, su única protección contra la piratería sería realizar un seguimiento (desde el lado del servidor por supuesto) de la cantidad de solicitudes de descarga por transaction_id y limitarlas si superan cierto valor.

Entonces, si lo limita a decir 50, eso le da un margen razonable al usuario para implementar la aplicación y sus contenidos en múltiples dispositivos y restaurarla varias veces, pero hace que sea difícil para quien quiera distribuir una versión pirateada con un recibo válido para un número ilimitado restaura Por supuesto, pueden simplemente distribuir una versión con todo su contenido, pero eso no es nada que pueda hacer al respecto y, al menos, no están gravando sus servidores.

No creo que pueda vincular el recibo al dispositivo.

Tengo entendido que puede instalar una aplicación en múltiples dispositivos sin costo adicional. Al vincularlo al dispositivo, significa que si, por ejemplo, actualiza / cambia su teléfono, deberá volver a comprar todas las aplicaciones.

Enfoque Vulnerable Proporcionado por Apple

El servidor puede autenticar una compra haciendo lo siguiente :

La aplicación iPhone recibe un transactionReceipt después de la compra. Haga que el iPhone base64 codifique (Puede usar este complemento de código abierto para NSData ) y envíelo a su servidor. (Incluso podría enviarlo tal como está y hacer que el servidor base64 lo codifique antes de la validación).
Haga que su servidor envíe una solicitud JSON con los receipt-data clave única con el transactionReceipt codificado en base64 a https://buy.itunes.apple.com/verifyReceipt usando HTTP POST. (Para obtener instrucciones sobre cómo hacer esto en varios idiomas del lado del servidor, consulte este sitio )
El servidor responderá con un objeto JSON con dos claves: status que es un número entero y receipt que es el recibo repetido.

Si el estado es cero, el recibo es válido debe ser aceptado, un valor distinto de cero significa que el recibo no es válido.

Adiciones seguras al enfoque de Apple

Sin embargo, hay algunas implicaciones de seguridad. Un usuario podría usar el recibo de otro usuario ya que los dispositivos no están vinculados a los recibos, o un usuario podría usar el recibo de otro producto ya que el servidor no verifica la identificación del producto del recibo. Para asegurarse de que esto no ocurra, también debe hacer lo siguiente:

Cuando obtenga el recibo por primera vez en la aplicación, envíelo inmediatamente a su servidor junto con el UUID del dispositivo a través de un canal seguro como HTTPS o un socket SSL. No lo guarde en ningún lado, déjelo en la memoria.
En su servidor, almacene el UUID y el par de recibos en una base de datos.
Cuando un dispositivo envía un UUID y un par de recibos, verifique con su base de datos que el recibo no se haya utilizado aún, y asegúrese de que el recibo sea realmente para su producto al verificar la identificación del producto del recibo . El recibo es solo un objeto JSON, por lo que su servidor puede leer los contenidos decodificando el recibo desde base64.
Devuelve una respuesta al dispositivo a través del canal seguro indicándole si la compra es:
- Autenticado como nuevo (no estaba en DB y era válido)
- Autenticado en el pasado (Mismo UUID y el par de recibos ya estaba en DB)
- Denegado debido a una identificación incorrecta del producto
- Denegado debido a que ya usó el recibo con otro UUID.

Como el recibo solo está en la memoria del dispositivo, y su aplicación usa el UUID del dispositivo ( puede ser falsificado por dispositivos liberados , consulte los comentarios) y todas las compras de su producto se registran con el UUID del dispositivo en su servidor de forma segura ; un usuario no podría usar el recibo de otro usuario para verificar la compra, ni podría usar un recibo de otro producto, ya que lo verificará.

También puede validar otros campos del recibo si desea verificar otros detalles de la transacción. Por ejemplo, si su producto es una suscripción, también querrá ver la fecha de la transacción.

Además, los usuarios no pueden pretender ser su servidor teniendo el dispositivo en una red privada con un host del mismo nombre que el suyo, ya que no tendrán su certificado SSL.

Consideraciones de fallas

Como puede ocurrir una falla entre cuando el dispositivo del usuario recibe el recibo y lo verifica con su servidor (por ejemplo, si el usuario pierde conectividad, o su servidor está inactivo por mantenimiento), también debe dejar que el usuario "vuelva a autorizar". La nueva autorización debe obtener el recibo de la tienda (utilizando una transacción restaurada ) y volver a enviarlo al servidor como si fuera una compra nueva. Esto rara vez necesita ser usado, pero debe estar disponible para evitar que el usuario tenga que volver a comprar el producto en caso de falla de la red.

Consideración de dispositivos múltiples

Esto significa que si un usuario desea usar una aplicación en más de un dispositivo, deberá comprar el producto varias veces. Este podría ser el efecto deseado, pero es probable que deba informar a sus usuarios antes de comprar, ya que es probable que puedan usar el contenido en los dispositivos que tienen asociados con su cuenta.

Si el recibo también contiene la información de la cuenta de iTunes, la autenticación podría usar eso para permitir a los usuarios compartir contenido entre todos sus dispositivos (pero no los de sus amigos).