安全永远在招人，一直都是供小于求，不缺 HC。
我今年投了很多家，也面了很多家，要么有 offer 要么就觉得自己太菜配不上，倒是没遇到故意砍的。
顺便吐槽一下腾讯，流程太慢太长了，中间没有任何反馈，体验很糟糕，希望有所改进。

对的，这个玩意 IOS8 之后就没法用了，好像新版 android 也有防御吧

很多，steam 里一大堆像素风游戏，有动作类剧情类等，应有尽有。

Dead game

看一下是不是装的其他服务暴露出了端口被攻击了，照理来说有密码也改了端口应该没那么容易，最好再看下日志确认一下。

“让人类保持理智，确实是种奢求。”

我支持楼主，做安全的都对技术有些热情和执着，而且以你能打 defcon 的实力来讲，出去一线拼一下也能活得很滋润，最重要的做的是喜欢的事情，这个对你有莫大的吸引力。 上面的人都看重你公务员的铁饭碗和舒适，却没考虑到你自身的爱好和梦想，燕雀安知鸿鹄之志？

但是行动之前望三思，虽然安全岗会比公务员做的事情要有意思，但很多时候杂事也很多，不是所有时间都能搞研究的，而且会比较累一点，可能会带给你更大的健康压力，也会分掉你很多精力去照顾家人，这一点需要重点顾及。


另外，考虑一下 gov security ？ 既是公务员，又是搞安全技术研究的，不过待遇可能没你现在。我不是体制内的也不知道能不能转过去，仅给你提供一个拓展性的思路。

被我发现了，360 的师傅

我出现过你这种情况。收到这种诈骗短信类型的，我转发给朋友，也被封了所有的短信发送，过一段时间后自己就恢复了。猜测你转发的时候也是这样触发了关键字识别被误封了。

@Sapp 我作为一个土生土长的四川人，还真是头一次听说四川一点不冷一点不热的说法。

就不跟深圳这种沿海气候比了，舒适程度哪怕跟北方一些城市相比，四川的冬天比北京天津这些有暖气的地方比起来非常难受，至于东北，我去过哈尔滨，我都觉得哈尔滨的冬天比四川舒服。 大学同学就是天津的，第一年在四川过冬的时候，生了人生中第一次冻疮。

四川的夏天，正式因为没有风，湿度高，在最热的时候像蒸笼一样，38 39 度的温度可以把人蒸熟，而深圳去年夏天最热的时候基本都不超过 35 度。

我没有去过湖北湖南生活过，所以不知道你的对比到底如何，但如果光是和一些气候更加恶劣的地方相比，那四川确实没有那么糟糕，也就一般差劲吧，反正我不愿意去那生活。

#14 @loveour

空气和气候，这个是首要的，四川地区没有太阳，冬冷夏热；

市政建设，深圳的 gov 工作人员比川渝地区态度和意识都好太多了，成都这点还落后很多；

经济发展和医疗水平和其他东西，比如成都地区直到前年冬天，有一天我去的时候污染很重，两三百吧，我就戴了口罩出门，一路上都有人很稀奇地看着我，要知道在北京污染严重的时候，大部分人包括车站工作人员都戴着口罩。光这一点，成都比起一线城市还差很远。

我就是四川的，待过北京深圳成都，还是最喜欢深圳。

楼主主要是没认识到家庭版中，家长的权力是比较大，能够随意删除其他人的权限和账户，这本来就符合家庭版的定义。当然看密码是不可能的。所以选择加入家庭版时一定要慎重，选择能够信任的人。

为什么应该使用密码管理软件
https://medium.com/s/the-firewall/episode4-password-managers-ce5576e96e85

几种密码管理软件的比较
https://medium.com/@QuantopianCyber/head-to-head-evaluation-of-five-password-managers-8faa4851c767

看了第一篇文章对这个重要性应该就有基本认识了，文章有点啰嗦可选择性阅读。

我也遇到过这样的问题，在 V 站上也已经不是第一次出现，看起来这是一个特定情况下会出现的小概率 bug。

https://www.v2ex.com/t/524051

遇到这种事情大家会优先怀疑用户密码是不是记错了，而不是怀疑 Apple。

#18 @opengps 这样是完全错误的做法，全局替换非常容易造成一些安全问题，如果我这样写的话 \' 会变成 \''，会将第一个单引号转义，第二个单引号就逃逸出来了，造成 SQL 语句闭合引起注入。

很多问题都是因为一些程序员所谓的“小聪明”导致的，好的坏的程序员都犯过这种错误。 请严格遵守最佳实践。

@mostkia #7 如果是这样的话，在将这些字符还原的场景下，会带来一些意想不到安全隐患，考虑如下情况：

比如，你有一些数据需要展示出来，如用户名，地址等消息，我注册的时候随便填的数据，比如 <script>alert(1)</script>，你 base64 放到数据库了，展示的时候解码展示，就会造成 XSS。

为了避免上述问题，你还是需要对用户输入的数据进行过滤和限制，这就让你的 Base64 编码失去了最初的意义。 另外，由于你对入库的数据做了编码转换，这会导致一些数据不直观，数据还需要多做处理，浪费性能。

所以为了达到安全的最佳实践，建议不要自己想出一些方法，这会引起其他意想不到的问题。

总的的说，如果某方法简单有效，那么肯定有人已经想到且运用上了。

没搞懂 base64 怎么防注入的，我的理解是你传入后端的时候编码一下，你后端收到数据的时候再解码，然后拼接这个 SQL 语句进行查询，这样除了一些乱码外其他好像没啥作用啊，比如我写这样的语句，1' and 1=1，base64 编码解码后不还是一样的吗，怎么防止注入的？

噢应该可以防止宽字符注入，其他的好像不行。 要不就是我理解错你的意思了。