lesismal

lesismal

V2EX 第 497905 号会员,加入于 2020-07-06 13:49:58 +08:00
今日活跃度排名 1744
美国宣布全面禁止竞业协议
程序员  •  lesismal  •  11 天前  •  最后回复来自 ChrisFreeMan
2
github 被人 at 说币安空投,是诈骗吗?
程序员  •  lesismal  •  145 天前  •  最后回复来自 lesismal
2
4C-2G 来战 [ Golang Websocket 百万连接测试 ]
程序员  •  lesismal  •  165 天前  •  最后回复来自 lesismal
34
nbio 近期的一些功能更新,来骗点 star
  •  1   
    Go 编程语言  •  lesismal  •  2023-04-18 14:04:25 PM  •  最后回复来自 lesismal
    2
    吃八分饱长寿与充电 85%能保护电池
  •  1   
    硬件  •  lesismal  •  2022-05-06 13:22:14 PM  •  最后回复来自 julyclyde
    22
    lesismal 最近回复了
    > 对于题主的不信任 https

    @mayli 我可是完全没说过这话啊兄弟, 你和其他很多楼一样, 几乎完全没 get 到我说的是什么...
    > 你不猜你怎么知道哪些厂为啥不加密?这两家都是你主导的还是你认识主导这个需求的人?

    @LuckyLauncher 我都是在按照逻辑讲安全的, 因为一些人举例子 github 说大厂用明文所以就该用明文所以我举大厂的反例

    > 你不过也只是在按照你的方向猜测罢了

    我不是靠猜测, 都是按道理按逻辑在讲. 我举例子反驳他们 github 的例子, 虽然我没有说原因, 但我相信不用猜测——因为大厂不用明文的原因就是为了更高的安全强度, 这些不需要认识他们主导这个的人
    12 小时 32 分钟前
    回复了 yfixx 创建的主题 健康 你们有过心跳很快的经历吗
    这种事情还是听专业医生的靠谱
    @livin2 #186 对, 对于老项目是这样的. 但对于新项目可以避免这些
    @LuckyLauncher

    > 电商领域有没有可能考虑的不是安全性而是反爬机制

    都重要

    > 你看看他们的风控就知道了,以前淘宝的风控被诟病成人类都无法使用。

    这反到可能是因为他们反扒导致功能上频繁让用户验证导致用户诟病, 如果只是设计正常的登陆反倒可能不至于被诟病, 我用淘宝不多, 所以也不能确定是怎么回事

    > 当然这只是我的猜测,至于厂商为什么选择加密只有他们做加密的人知道了,可能亚马逊和淘宝选择加密的理由还不一样。

    不要随便猜了, 就不能看下我这么多发言的内容吗, 但凡大家能用冷静分析的态度来思考这个问题, 而不是一开始就拒绝观点, , 也不至于这么多人还坚持明文了...

    我琢磨可能是因为, 很多人自己这样用了习惯了, 所以这是属于舒适区, 人的天性就是难以从舒适区里出来
    加上经济学上的"沉没成本效应", 因为自己学习领会了一些 https 和加密相关的知识, 就使用这些知识点头疼分析头脚疼分析脚, 只管自己处理的环节, 从而忽略了整体流程上的完整安全
    @qq135449773

    > 二次验证防止的是未经授权的用户登陆操作,防止的不是密码泄露。

    我也没说二次验证是防密码泄漏啊,就是因为密码(不论明文不明文)都可能泄漏,所以才要二次验证这些额外的打补丁。但不是说有了二次验证密码就可以不在乎了,否则还要密码干啥,都走 SMS/EMAILS 之类的 OTP 登陆更省事了但用户又说你强行要我私人手机号了。。

    > telegram 和 whatsapp 这类东西,包括微信,做扫码登陆,因为他们本来主打平台就是移动端,只是顺便做的其他平台而已,所以才敢这么做,至于安全与否完全只是顺便而已。

    是不是顺便我不知道,但安全问题,如果安全级别要求高,我们不应该用“顺便”的方式来思考

    > 给密码再加密一层,密码是安全了,返回给用户的 session 你也要加密返回给用户吗?

    例如 JWT 吧,它确实是 server 加密后返回给 client 的,你的用法或者理解是不是有什么误会


    > 像 CDN 、WAF 这些做 tls offloading 的东西,还有一些其他公有云设施,这种东西你只能默认信任。
    > 假设你以上所有东西都 ok ,你怎么确保你公有云 instance 的云盘或者云数据库不会被未经授权的读取?

    同样的,你的这些观点就像我回复其他人的以及 append 里讲的一样,不要只关注我所说的一两个 part
    用别人服务默认信任、别人也应该尽量提供保障,这个我没有否定过
    重要的是,各个流程链条上,各自尽量做好自己环节的事情,三方厂商做好自己这一层,出了问题它是要赔钱的,我们不能确保三方一定不出问题,所以自己方负责的链条也做得安全强度更高,有错吗?

    > 所以就不要自己骗自己了。

    这句话我建议你先送给自己,然后好好看下我、以及与我持相同相近观点的各个楼层或者其他地方的知识点
    @bullfrog 要是想聊技术问题, 就正经拿出你的技术观点聊, 这种戏谑的例子跟帖子内容基本没有关系, 习惯了这种不去真正思考只喜欢戏谑的思维方式, 只会成为兄弟你技术进阶的阻碍. 当然, 如果家里有矿无所谓技术进阶, 那你随意, 我也不 care 这些
    @wanguorui123 #100 完全同意, 就是应该在各个层级尽量做好. 好些坚持明文的在这用自己做了五十步的安全笑别人百步, 我感觉他们就是因为明白了一些算法本身, 然后只思考整个环节中的一两个环节从而忽略整体, 可谓是头疼医头, 脚疼医脚, 不管全身
    > 就拿我司我们 org 的习惯来说吧。如果你要做一项比较大的功能改动(你说的前端加密就已经是比较大的改动了),一般需要先开一个 wiki page 把改动写在文档里。

    @msg7086 我现在明白一件事了, 因为你门大部分人的项目, 本来就选择了明文, 如果用户和业务量非常大, 即使改造方案没问题, 但也是担心规模效应, 所以确实成本大. 但我们并没有局限于旧项目改造, 新项目如果从一开始就应该使用非明文方案. 如果你们团队一开始就明文了, 那说明最初负责技术的人本身他就不够严谨

    > 从我读你帖子和回复的内容来看,我并没有看到( 1 ) HTTPS+明文这样的设计会造成很大的经济影响(例如大规模密码泄露,账号被盗等等),( 2 )你设计的解决方案会产生什么样的经济影响(例如原本 v 站大量账号被盗,经过你事故分析,确定是明文传输造成的,如果做了你这个方案,账号就不会被盗了等等)。

    你有没有想过, 很多黑产搞到东西, 但每年我们看到的新闻有多少? 被你知道的泄漏了的只是冰山一角, 你没看到不代表明文就安全了, 也不代表改造后就没带来更全的安全性.
    另外, 黑产最高级别是社工, 从企业到政府国家之间的渗透, 很多技术上安全做得非常严谨的仍然被渗透过就是通过社工, 比如后端开发假装失误把日志里打印出了明文的用户信息并且盗取出售, 事后即使企业发现了整改了, 后端内鬼也只是说不小心失误了, 你不能保证所有项目所有流程都严谨, 即使流程都严谨, 也不能保证执行过程中完全没有疏漏.

    前阵子那个压缩算法开源项目贡献者潜伏成维护者然后投毒热度刚过, 不要没被烧伤就不知道疼, 不要好了伤疤就忘了疼
    > 你就不能推进网站后端采用 bcrypt 或更安全的验证算法,推进网站后端 log 脱密记录?

    @viruscamp
    bcrypt 本身也是非明文的方案之一, 我没有抵制过使用 bcrypt, 是否采用 bcrypt 的阻力有两个, 一是团队有没有人懂安全, 二是 bcrypt 性能, 所以 bcrypt 也就回到了大家都比较认同的安全级别问题上了. 对于 FIN Tech 相关的安全级别要求高的, 用 bcrypt 即使登陆的时候慢那么一点点也无所谓, 但是对于安全级别要求不那么高的并且并发量在线量大的, 可能就不会采用 bcrypt

    至于后端 log, 这个我相信多数团队都有要求, 但是你没办法避免开发人员或者有心之人假装无心 log 打出来了, 再采用明文的项目里, 这额外需要严格的研发流程把控, 而如果本来就没采用明文, 就不需要这个额外的流程把控, 你觉得哪种更划算?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   899 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 21:19 · PVG 05:19 · LAX 14:19 · JFK 17:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.