安全问题通过https从iOS应用程序发送用户名和密码到服务器
根据苹果的build议，我已经设置了应用购买收据validation，将收据发送到我的服务器，服务器又把它发送到苹果的服务器进行validation。 我所有的收据处理都是在服务器端处理的，并且工作正常。 我的服务器发回一个非常模糊的代码到我的应用程序，以确认购买是否有效。 我在应用程序方面使用了一种非常强大的模糊处理方法来掩饰返回代码的内容，使越狱黑客破解它变得越来越困难。
问题是我有我的PHP文件存储在我的networking服务器上的密码保护的文件夹，并担心如何可以被认为是安全的应用程序本身有用户名和密码的embedded在该目录中发送收据到php文件开始。
我的应用程序只使用服务器进行应用程序购买收据validation。 所有其他function都在应用程序本身，所以我不强迫每个用户有一个唯一的用户名和密码的帐户。
我正在使用URLSession通过TLS 1.2 https连接与服务器进行通信，以便部分是安全的，但我想不出一种方法来确保黑客从设备上的应用程序中提取用户名和密码，并直接访问我的服务器文件夹。 有这种能力的人可以很容易地修改php文件，总是返回一个代码，表明有效的购买。
我在应用程序中混淆了用户名和密码，以至于大多数人可能会放弃尝试弄清楚这一点，但是我知道我只是使得提取更加困难，而不是靠近不可能的地方。
对此有何想法？ 几乎所有我在网上find的关于这个问题都是关于不通过http传输用户名和密码，而不是越狱的设备更大的问题。
您正在想象一个黑客颠倒您的混淆二进制文件，试图获取用户名和密码。 这是很难做到的。 简单的方法是检查networkingstream量。
是的，即使没有越狱，TLS很容易被设备所有者绕过。 TLS可以防御外部攻击者，但是它不能防止某些人想要检查自己的networkingstream量。 这是很容易做的，例如见我的博客上的指示，我击败了非常stream行的iOS游戏 。
如果你想停止这个更容易的攻击，你可以尝试实施证书locking 。 在越狱设备上，这仍然可以轻易破解，但是却阻止了许多不想越狱的偶然黑客。
在一天结束的时候，你是正确的，一个坚定的黑客将赢得反对这种types的devise。
所以我想我已经想出了一个相当安全的解决scheme。 非常感谢那些花时间对此发表评论的人，因为你的投入肯定是有帮助的。
首先，虽然我在Obj-C / Swift iOS开发方面有相当多的经验，但是服务器端的东西对我来说是相当新的，但是我学得非常快。 对我来说，看起来像是一个巨大的尤里卡时刻，对于一个REST / Linux / PHP专家来说，看起来相当平常，所以请耐心等待。
总结一下这个挑战：我想将应用内购买收据的json表示从我的应用发送到服务器上的.php文件，以便将其发送给Apple进行validation。 为了保护这个.php文件，我在其文件夹中放置了一个.htaccess文件，要求用户名和密码来访问它。
NSURLSession处理这很好，但要求我把用户名和密码在应用程序…不好。 这就是混淆的对话，让我意识到在硬编码到应用程序时，没有办法保证密码安全。
然后我意识到我可以把文件放在我的public_html文件夹（我的灵感一刻）之外，这就是我所做的。 因此，在public_html文件夹中还有一个index.html文件，现在我有一个非常简单的.php文件，它只不过是在另一个.php文件中调用一个函数，它完成了所有与Apple服务器交互的工作。parsing响应。 当它完成分析时，它将返回一个非常模糊的代码（不是苹果公司返回的公开代码）到简单的.php文件，该文件又将其返回给我的应用程序。
根据该代码，应用程序将决定是否授予对所购商品的访问权限。
使用服务器端的权限我已经限制了public_html目录中的简单.php文件从“world”的读取或写入访问，只保留为可执行文件。 所以如果黑客破解了应用程序，黑客可以很快得到该文件的名称，但是这样做对他们来说应该不会有好处。 我不再需要应用程序中的用户名或密码，并且执行所有工作的“main”.php文件位于public_html文件夹外部的文件夹中，其权限设置为限制读/写/执行从“世界”，即使我认为这是矫枉过正我把一个.htaccess文件在那里，否认所有。
我认为我有一个“相当”的安全解决scheme，应该让一个偶然的黑客窃取一个应用程序内购买非常困难，但是我总是会坦诚地提出build议，以免我错过了一些东西。