密码肯定可以啊，你app里把密码做一次哈希，服务器只认哈希过的密码不就得了，除非反编译或者抓包研究一下，不过你这个本来就是小需求估计也没人看

【 在 M8V 的大作中提到: 】
: 我的内网有一批文件，为了让外网的app能够访问，我用NGINX做反向代理，这样app就能访问了。
: 可是呢，现在想只让app访问，别的通过IE或者一些工具比如curl，wget等不能访问，怎样实现这样的要求？
: 用密码认证的好像不行啊，只要知道密码，不是我的app也能通过认证。
: ...................
--
FROM 123.123.62.*

api key加https，标准套路
--
FROM 59.40.0.*

挂个假证书什么都交出去了
【 在 redshift (redshift) 的大作中提到: 】
: api key加https，标准套路
--
FROM 61.135.169.*

https只能保证网络传输过程中的安全，不能保证端的真假，假的下载客户端秘钥，和真的没区别。
【 在 redshift 的大作中提到: 】
:哪来那么多假证书？要那么容易弄个假的，https还玩个屁啊
:【 在 Loveni 的大作中提到: 】
:: 挂个假证书什么都交出去了
:...................
--
FROM 123.66.160.*

现在讨论的是某种方案对这个问题是否是对症下药且有疗效。
----再就是1.0版的U盾都可以Copy伪造。


附上HTTPS的工作原理，自己琢磨吧：
HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的简单描述如下：
1.浏览器将自己支持的一套加密规则发送给网站。
2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
3.获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
4.网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。
5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256
其中非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。
【 在 redshift 的大作中提到: 】
: 那啥也防不住把你客户端逆向了，难道还插个优盾？有那么高的安全需求吗
--
修改:dhcn FROM 123.66.173.*
FROM 123.66.173.*