V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 1 页 / 共 56 页
回复总数  1111
1  2  3  4  5  6  7  8  9  10 ... 56  
@murmur #4 年过 35, 又很多人说:劝人 IT ,天打雷劈。除了失业,多数人还一身 IT 职业慢性病。
压力和收入是早来还是晚来放到一辈子人生的尺度上,在不同的时代各具优劣。比如 10 年前,如果搞 IT 先攒够第一桶然后赶上互联网红利、房地产红利,划算,但是当下的经济周期区间就未必了

@MIND222 如果分数能有机会,建议军医。原因:
1. IT 或者其他前沿那些想在做出成就的赛道竞争压力大,成绩不具备优势,所以不建议
2. 相比于普通医学方向,军队国防生本身的待遇不差,有军队管教只要跟着别掉队就行,技能点上也是长期价值的投资,年轻时候辛苦点,稳定无忧
6 天前
回复了 dumbbell5kg 创建的主题 MySQL 请教一个 MySQL 的问题
先搞清楚要对比的是什么, 如果是 count(*) 对比 count(user_id) 是有可比性的, 但 select * 对比 select user_id, 每条 700B vs 每条数据最多 8B, 单说拷贝 100w 条数据的量就性能差别巨大了所以二者根本没有可比性
只考虑孕妇、不考虑孩子吗?随便搜了下对孩子的影响:

增加儿童恶性肿瘤的几率
引发儿童哮喘
影响儿童听力发育
影响儿童身高
诱发厌食
影响儿童智力发育
婴儿猝死综合症
...

女人不懂事那自己爱吸就吸,孩子面前谁抽烟都不行!

提前客气地给客人说清楚,忘了就再提醒,平常语气沟通,不用纠结什么客气不客气的
别惯着这些坏习惯
@iseki
什么情况必须获取原始口令?密码和 OTP 是有区别的,你要说 OTP 我没意见。其他系统的密钥本身,我暂时想不到必须用原始明文口令的。
我的出发点是,实现各种密码存储需求本身要应对的业务,并不需要以来明文本身,历史问题是历史问题,但这里说的是方案本身的优劣,历史改造甚至都不在我考虑范围内
所以这根本不是说法的问题,是逻辑本身的问题,如果你一定要用“现在已经有哪些使用了明文、所以避免不了用明文”来讨论,那确实没什么可讨论的了,这不是我在讨论的问题
@lesismal #222 不要看它当前是什么方式,站在当前实现的方式的角度考虑问题则任何现状都有它局限于历史和版本等问题导致的合理性。应该撇开历史现状,看理论和实现方法上,哪种方式可以做到更好。是否把旧系统改造升级是项目自己的管理的问题
@iseki LDAP 我没太了解过,但如果它需要明文的密码,这应该也是历史遗留问题,因为本质上是不需要明文的。另外,“必须把用户输入的原始口令发送过去”—— 这里的原始口令要看是哪种,如果是密码、那是历史实现问题和现在的兼容性、修改成本问题,如果是 OTP 这种单次验证码,则没关系,单次的验证码明文也可以、不怕泄露
@morebuff 感谢支持!欢迎使用! 666
首先应该清楚:他俩可不是普通人啊

所以,为什么要用普通人对比做标题
> 明文向后端传输虽然不好

你看, 你也认为明文不好了

> 但有时这是工程上成本刚好可以接受的方式

如果是项目初期/上线前, 这个成本真的不多

> 一来我刚才说了,很难设计一个有足够收益的非明文传输方案

数据隐私本身不重要的网站, 明文与否都还好, 即使泄漏了也没关系. 我自己注册一些不重要的网站的密码都非常简单, 单手输入满足大小写之类的就用了, 也不怕泄漏, 重要信息的网站就复杂些而且那些站多数有二次验证之类的额外安全措施, 所以也不怕

> 二来就是有时候后端的某些设施只能接受明文

密码这个功能点上来讲, 明文不是必需, 所以如果哪家说必需明文, 那我怀疑这是别有用心...

@iseki
@zanpo 兄弟你根本就没看懂 OP 我说的是什么, 你们好些位这都相当于是盲人摸象管中窥豹, 只考虑 https 或者某个 part, 请先看下我帖子和 append 或者更多楼层的回复
@msg7086 虽然可能 block 我了, 但说不定你 logout 能看到, 所以补几句吧, 你让我举例子, 我说黑产黑了的很多没曝光出来你又说我假大空, 那你可以看下 github 的例子, 可以看下 #158 cdn 脱裤的例子, 淘宝亚马逊以及#174 微信的推荐设计

自己脑袋一热也不认真分析下我的回复, 就无脑喷我, 只会限制你提升自己的技术层次, 这跟我所理解的原因(病因)八九不离十, 就是舒适区和沉没成本, 另外一个词就是"聪明反被聪明误", 因为自己懂了一些, 所以拒绝接受不一致的. 但技术需要冷静分析, 论坛上讨论技术我多数时候是一就是一二就是二, 不喜欢模棱两可去赞成别人, 所以我的观点如果和你不一样的时候, 你可能会觉得我带着情绪, 但不是, 技术的东西是实在的, 谁也不给谁发工资, 不需要看脸色
@viruscamp 跟前面好多层一样, 兄弟你这也是没 get 到
@viruscamp

我已经发现了, 讲的原则逻辑和道理各位基本都不怎么看, 所以我举例子请教各位, 淘宝亚马逊不用明文, 是为什么?

github 日志输出明文的问题暴出来大家也"多数人"认为这是问题, 为什么? 我这里说"多数人"而不是说"所有人"认为这是问题, 因为我发现可能并不是"所有人"认为这是问题, 比如各位坚持明文的
> 谁出钱谁说了算。你出钱吗?你不出,所以你说了不算。

公开的技术讨论, 各自公司自己的事情自己负责, 你看见我什么时候说过我说了算了要求你们所有人都要按我说的做了?
但是, 我公司的项目就是我说了算, 你也管不着

> 你自始至终都没有对 Before 和 After 做过具体的案例分析,帖子里基本就是一些假大空的呐喊,什么坚持明文啊什么舒适区啊什么天性啊。怎么不上点干货呢。

哦哦, 和着我说的技术逻辑安全逻辑安全原则和举例子之类的, 都算是假大空是吧? 我说了那么多逻辑原则例子你思考吗?你不思考还狡辩解释那么多层然后被逼的我说你舒适区有错吗?

> 这么高一层楼 200 来个回复,说句实话,非常给你面子了,因为讨论的过程还算礼貌,v 站大多数人也不愿意说脏话。

怎么的, 有些个小孩子上来就说"你水平低"之类的, 你见我说几句脏话了吗? 聊个技术还怕别人喷, 那就不要出来聊

> 换到激进点的论坛里,就不知道是你保卫家人在先,还是管理员看不下去直接 ban 号在先了。

自己说不过了, 就改成威胁别人要骂人了是吧? 我不 care 低素质的人, 你随意

@Livid 我感觉这是在威胁骂家人了

> 帖子内容太过贫乏,甚至激不起我一点讨论技术的欲望。有句话叫,非蠢即坏。

蠢和坏也是要以事实逻辑为依据, 我每一个点都有对应的解释, 如果你看不懂然后以为我蠢, 那你也随意, 你嫌烦的话可以直接 block 我

> 看你讨论过程,好像也不像是坏,那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的,有一种老子说的才是对的,你们不同意那一定是你们都是傻逼。那这就没法聊下去了。

你看看你这两层的回复, 谁在假大空?

@msg7086
> 对于题主的不信任 https

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

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

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

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

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

都重要

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

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

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

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

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

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

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

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

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

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

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


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

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

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

这句话我建议你先送给自己,然后好好看下我、以及与我持相同相近观点的各个楼层或者其他地方的知识点
1  2  3  4  5  6  7  8  9  10 ... 56  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1036 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 19:35 · PVG 03:35 · LAX 12:35 · JFK 15:35
Developed with CodeLauncher
♥ Do have faith in what you're doing.