移动app与服务器端进行身份认证

Question

昨天面试问题，app与服务器端如何进行身份安全认证！我的回答是用户登录成功，后台通过jwt生成token给app，然后前台每次请求都带上token，在后台验证token！

面试官说:如果token泄露了被恶意用户获取了，不就可以伪造身份请求了！

我问面试官怎么做安全:
他的大概意思是:app每次请求服务器都会带上一个不同的加密字符串与用户的id绑定。就像一个身份证号绑定一个人！
他的意思我没有理解！
问题:1. 面试官的意思是具体怎么做？
2、app与服务器端最安全的身份验证该如何实现？
求大神解答

Answer 1

既然token能窃取，那加密字符串不一样能窃取？token和加密字符串的安全等级能差多少？
目前市场上80%的app都不是HTTPS的！意味着都会被窃取！
但是服务维护的代价也相应的会低很多，这是价值和代价的博弈。

1、HTTPS,尽可能的保证网络传输过程保密。
2、oauth2身份认证。
3、接口token， Token Bucket桶，限制API的调用次数。
4、UDID的绑定、网络信息、使用习惯的大数据监控判断

好了，不装逼了，没啥价值的东西，弄那么多安全措施干什么？
一句话，就是干！

Answer 2

1. 不清楚

2. 没有最安全，只要用户凭证泄漏，那么就可以伪造请求，因为http协议是无状态的，而看上去有状态的http是cookie来提供的，但是如果cookie泄漏，服务端依旧认为这个恶意用户和真实用户是同一个

Answer 3

没有绝对的安全，另外设置一个签名算法，可以尽量避免别人恶意请求等

Answer 4

jwt已经是比较完善的加密了 签名已经很难破解了 至于截取你的加密方法 相当难了吧 我只能说面试官不完全了解jwt

Answer 5

面试官的问题可能不仅于此，问题可以延伸：
1.jwt相对于后台简单地生成一个uuid之类的随机字符串，安全在哪里？从jwt的实现机制上说明它的安全性；
2.既然任何形式的token都有可能泄露，如何防范呢？如XSS、CSRF参考文章

Answer 6

先将（token + 随机串）利用非对称加密算法加生成一个签名，然后与随机串明文一起传到服务器，服务器再用私钥解密从签名获取随机串比较，比较两个随机串来确定token是否合法; 当然要避免请求被拦截重放，需要记录每次请求的随机串

Answer 7

加上参数签名sign,这样即使token和sign都被抓包到了,也能确保数据不会被篡改

Answer 8

我的看法:

面试官也是半调子

面试官提出了问题, [app与服务器端如何进行身份安全认证]

楼主给出了回答: [使用jwt]

然后面试官提出反对并给出了一个典型的签名解决办法......

这是一回事吗? 问的不是身份认证吗?

至于面试官提出的反对疑问, 并没有最根本的解决办法. 用现实生活举例:

你的钥匙被偷了, 怎么办呢? 你如果第一时间知道, 可能会立即更换门锁, 以减少损失. 那你的钥匙可能不被偷吗?

用这个思路想一想 token 这个机制, 是不是没有办法确保绝对的安全

所以, 只能在其他方面保证, 例如说, 服务器提供 换门锁 这个功能. 但是这个需要客户端知道自己的 token 丢失, 对于大部分人来说, 这可比一个人知道自己的钥匙被偷了要难多了.

token 这个机制对比钥匙来说, 有个时效性的概念. 用以被动的解决被窃问题, 哪怕 token 被盗用了, 也只是在这个时间段以内.

Answer 9

首先肯定一点，题主的思路是可行的

1. jwt生成的token是通过自定义secret加密的，即便token泄露，没有secret也无法解密，

2. jwt可以设置token的过期时间，token并不能永久有效

3. jwt是目前比较成熟的解决方案了，大公司也在用。像安全性这样的问题最好还是使用一些普遍的成熟的解决方案，有时候你的顾虑未必是真的顾虑，你认为的安全未必算得上是安全

Answer 10

我的理解是，你所谓的面试官问你的问题，可能是想问类似csrf token令牌的那种一次性闪存类验证机制，而且我认为他讲的是传统的token令牌机制，表述问题的时候可能没表述清楚他想要哪种，然后你跟他说用jwt token，可能也是回答的不是很清楚，比较模棱两可，就像大家都知道数据库读写分离啊，分表分库啊，让你详细讲讲不一定都能讲清楚，再或者他没用过这个。

总结就是，你俩一个人在讲传统的token令牌机制，一个在讲jwt协议的机制，但没有一个人解释的很清楚，让对方听明白。其实你俩说的方案都差不多。。。