首页   注册   登录
 xylophone21 最近的时间轴更新

xylophone21

V2EX 第 65655 号会员,加入于 2014-06-19 16:32:42 +08:00
今日活跃度排名 15947
谁知道深圳这个阿尔法巴智能驾驶公交具体在哪里?
深圳  •  xylophone21  •  2017-12-04 22:40:59 PM  •  最后回复来自 Android2MCU
11
关于百度漏洞的问题
Android  •  xylophone21  •  2015-11-02 10:52:53 AM  •  最后回复来自 xylophone21
7
天猫的退货政策真的这么奇葩吗?
问与答  •  xylophone21  •  2014-12-15 19:16:56 PM  •  最后回复来自 xylophone21
18
xylophone21 最近回复了
好用的定义是什么?
@47042 思路类似,原厂是怎么防止你刷 Recovery 的,你就怎么防止别人刷。不过你可能需要 fastboot 或者更底层 boot 的源码,这可能有点困难。
自己编个 Recovery,验证自己的签名。原厂的 Recovery 就是这么玩的,只不过你没有它签名的私钥而已。
第一感觉这个方案很奇怪,关注一下听听大家的说法
170 天前
回复了 qwertyzzz 创建的主题 程序员 问个规范问题
你这应该是无用户概念的场景,这种场景下只能尽力而为的做认证,常规的方法从安全到不安全:
1. 设备出厂时加密预制证书,服务端校验证书(这个应该不适合你)
2. 设备出厂时加密预制唯一 ID,服务端从数据库查 ID 校验+TLS,换取 token (这个应该也不适合你)
3. 直接使用设备的唯一 ID,如 UUID 加一个签名校验+TLS+服务端监控异常的 UUID
4. 在 3 的基础上,不换 token 了,直接使用 UUID+签名校验+TLS+服务端监控异常的 UUID

另外,顺便问一下大家 3 和 4 的安全性到底差异在哪里?
虽然 token 能改但 UUID 不能改,但 UUID 换 token 的过程如果被抓,结果是一样的,偶尔使用一次比经常使用安全多少?类似 RefreshToken + AccessToken 的方法,究竟比只有一个 AccessToken (过期等于 RefreshToken )安全在哪里?
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2258 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 14ms · UTC 15:53 · PVG 23:53 · LAX 08:53 · JFK 11:53
♥ Do have faith in what you're doing.