0zero0 最近的时间轴更新 0zero0 最近的时间轴更新 |
0zero0最坏的时候，也是最好的时候 V2EX 第 40096 号会员，加入于 2013-06-03 20:31:43 +08:00 |
北京 成都 武汉
0zero0 最近回复了
18 天前 回复了 Apple2023 创建的主题 › iPhone › 百度地图打车 vs 高德地图打车 |
缺德地图打车真的是能不用就不用，前几天因为滴滴在小地方没有办法选车型，看到高德上面可以选（ 6 座商务车）就用的高德，结果根本打不上，这也就算了，打不上目标车型高德会自己给你加一些你没选的车型（比如出租车），然后它给加的车型接单了，我一看非目标车型，在几秒内就取消了，结果司机还是来了，我把我的高德订单取消记录给司机看，**司机说我不管，来都来了，你不坐也要给空驶费**，我真的是 cnmd ，要不是旁边老人小孩在，我就跟他理论了，最后还是给了 20 的空驶费，就当是喂了狗。
20 天前 回复了 0zero0 创建的主题 › WATCH › AppleWatch 有办法通过语音快速唤醒体能训练中的项目吗？ |
@bigjie910 嗯，你这里的快捷指令起到了 IFTTT 的作用，不过就我个人而言可能更习惯人工主动语音唤醒——相对灵活一点。
28 天前 回复了 0zero0 创建的主题 › WATCH › AppleWatch 有办法通过语音快速唤醒体能训练中的项目吗？ |
@polobug 为什么会不需要？现在我个人的绝大多数训练记录都在 Apple watch 上，每天也都会坚持锻炼
38 天前 回复了 foxkiller 创建的主题 › Apple › 大家的七月 Apple Fitness 挑战是啥？ |
锻炼 2110 分钟，回想起来 5/6 月的挑战都没有完成……
41 天前 回复了 luffy 创建的主题 › 程序员 › 域名续费哪家比较便宜可靠 |
@lankunblue [转] 是指将你的域名从一个域名服务商（比如 GoDaddy ）切换 /转移到另一个域名服务商（比如 Cloudflare ），为了省点续费的钱或是其它原因
42 天前 回复了 luffy 创建的主题 › 程序员 › 域名续费哪家比较便宜可靠 |
3 个月前刚从 GoDaddy 转到了 Cloudflare ，并续费到了 2029 年
42 天前 回复了 0zero0 创建的主题 › WATCH › AppleWatch 有办法通过语音快速唤醒体能训练中的项目吗？ |
@lzgshsj 嗯，一般启动的时候忘了，要么就是刹车停住手动点开，要么就是等一会等它自动识别出来之后点击确认。但是后面这种方式虽然可以记录之前的运动时间，但是心率啥的是没有的，这算是一点小缺憾。
69 天前 回复了 Moyudawang 创建的主题 › 信息安全 › Android 手机使用随机 Mac 地址连接公司 Wifi，公司还能知道我是谁吗？ |
什么公司的 guest wifi 可以随便连？连个简单的短信验证码认证都没有吗？
另外就是如果你用了别人的网，你通过这个网做的操作很难不暴露。
另外就是如果你用了别人的网，你通过这个网做的操作很难不暴露。
73 天前 回复了 luffy 创建的主题 › 程序员 › 如果你是面试官，你会想出什么题 |
@ElmerZhang 针对社招人员用这种方式是最靠谱的，针对校招的就是计算机基础 /算法刷题那些了。
但是不靠谱的面试官不管对谁都是校招那一套，以难倒人为目标，没有想清楚面试的目的。
但是不靠谱的面试官不管对谁都是校招那一套，以难倒人为目标，没有想清楚面试的目的。
75 天前 回复了 kabob 创建的主题 › SSL › 启用了 https 的网站登录时密码加密有意义吗？ |
@GuuJiang @Buges @GeruzoniAnsasu
按个人理解简单总结一下当前的讨论情况：
1. 如果网站用户的期望是即便 A 网站被搞了（不管是被黑客入侵 /拖库，还是被内部开发 /测试或是其他人员非法利用，亦或是什么其它的方式），也不要影响到该用户在其它 B/C/D 网站的 [密码安全性] ，这种情况下，在前端就把密码进行 [hash] 处理对于该用户来说是 [有一定意义] 的。因为这种情况下，在后面的网络传输以及该网站后端拿不到用户的明文密码，不论是网站流量被解密监听还是该网站被黑了或是出现日志配置错误等问题，其它人正常情况下都很难还原出用户的明文密码（在不考虑超级彩虹表反向映射的情况下）。
但这么做（在前端就把密码进行 [hash] 处理）的好处，也基本上就这么多了——而且主要集中在那些会在密码中掺杂生日、名字拼音等隐私信息的用户上。如果不想让别人知道这些信息，最好的办法还是用密码管理器对各网站都生成并使用随机密码（虽然在实际使用上很难完全做到），一个是各网站密码不同，另一个是不暴露隐私信息。
如果网站被黑了，或是该网站后端有人通过日志等方式直接拿到了 hash 后的密码，他通过分析网站的登录接口最后还是可以进行登录并拿到用户的权限，对于该网站内用户权限的安全性并无实质性帮助。
2. 按 stackoverflow 以及本主题上面的回复来看，很多大网站并没有采用在前端对密码进行 hash 处理的方式，一方面是这样做对安全实质性的提升帮助不大，另一方面也是他们对用户的密码还有一定的企图心（也许真像上面回复中提到的“打算倒闭后拿用户密码再去其他网站撞一波库”）。
按个人理解简单总结一下当前的讨论情况：
1. 如果网站用户的期望是即便 A 网站被搞了（不管是被黑客入侵 /拖库，还是被内部开发 /测试或是其他人员非法利用，亦或是什么其它的方式），也不要影响到该用户在其它 B/C/D 网站的 [密码安全性] ，这种情况下，在前端就把密码进行 [hash] 处理对于该用户来说是 [有一定意义] 的。因为这种情况下，在后面的网络传输以及该网站后端拿不到用户的明文密码，不论是网站流量被解密监听还是该网站被黑了或是出现日志配置错误等问题，其它人正常情况下都很难还原出用户的明文密码（在不考虑超级彩虹表反向映射的情况下）。
但这么做（在前端就把密码进行 [hash] 处理）的好处，也基本上就这么多了——而且主要集中在那些会在密码中掺杂生日、名字拼音等隐私信息的用户上。如果不想让别人知道这些信息，最好的办法还是用密码管理器对各网站都生成并使用随机密码（虽然在实际使用上很难完全做到），一个是各网站密码不同，另一个是不暴露隐私信息。
如果网站被黑了，或是该网站后端有人通过日志等方式直接拿到了 hash 后的密码，他通过分析网站的登录接口最后还是可以进行登录并拿到用户的权限，对于该网站内用户权限的安全性并无实质性帮助。
2. 按 stackoverflow 以及本主题上面的回复来看，很多大网站并没有采用在前端对密码进行 hash 处理的方式，一方面是这样做对安全实质性的提升帮助不大，另一方面也是他们对用户的密码还有一定的企图心（也许真像上面回复中提到的“打算倒闭后拿用户密码再去其他网站撞一波库”）。
Select Language