V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  dingyaguang117  ›  全部回复第 6 页 / 共 73 页
回复总数  1459
1 ... 2  3  4  5  6  7  8  9  10  11 ... 73  
LZ 已经掌握了股市的精髓,韭菜长大了就该割了
2022-10-23 09:17:27 +08:00
回复了 dingyaguang117 创建的主题 问与答 蓝牙鼠标延迟、卡顿是 mac 系统问题还是鼠标问题?
确定了是 Wifi 干扰,慢速下载会卡。
2022-10-23 09:14:31 +08:00
回复了 oygh 创建的主题 V2EX 888888
看了下,再过几天,就是加入 V2EX 10 周年了,时间过得真快啊
2022-10-21 09:24:40 +08:00
回复了 fox0001 创建的主题 奇思妙想 Type C 有无可能取消公母?
要能卡住,就要求两边都有一块凸起。但是设备接口凸起,这是多难受的设计。影响设备形状、难看不说,到处磕磕碰碰,还容易划伤人。

很难想象手机接口是一块凸起
2022-10-14 10:27:59 +08:00
回复了 Philosophy6 创建的主题 问与答 买了房,瞬间一下子感觉有压力了
工作才三年,后面会升职加薪,压力不大~
2022-09-25 18:09:32 +08:00
回复了 IBMall 创建的主题 剧集 Netflix 剧版《三体》第一季杀青,首支片花曝光
第一季感觉没啥看点,仅有的应该就是呈现下游戏中的三体世界了吧
@LxExExl rsshub 的 chrome 插件
@xiaokongwu 合肥呀
去年让转 LRP ,我没转,现在有点后悔
为什么我买的时候是 6.15 , 后来 15 年调整过一次之后就是 4.9 了
2022-09-03 18:52:23 +08:00
回复了 wenzaiquan199 创建的主题 问与答 为安全问题,早上公司热烈讨论
@twl007 另外并没有说过不信任 HTTPS ,是不能绝对信任。有更高的安全需求的场景,应该在应用层做额外的安全措施。

有些行业场景下,升级的安全举措是监管强制要求做的,你不做就是不符合安全标准,是不可以展业的。
2022-09-03 18:39:56 +08:00
回复了 wenzaiquan199 创建的主题 问与答 为安全问题,早上公司热烈讨论
@twl007 理由就是 plain text 传输只要攻击者做了 HTTPS 中间人就是无差别攻击,做了任何形式的二次加密就是为了抵抗无差别攻击。(当然最好的方式是用 bcrypt 这种计算量大的, 撞密码不友好 hash 算法,但是只限于密码这种无需解密原文的场景)

就算别人是针对你的网站做了逆向,也是增加了相当的难度。而且我觉得你是低估了逆向的难度,看个爬虫教程就能让破解了,是开发者能力不足。

如果觉得微博垃圾,也可以看看 Facebook 登录的加密。更不要说券商、银行等金融机构了。
2022-09-03 00:49:31 +08:00
回复了 wenzaiquan199 创建的主题 问与答 为安全问题,早上公司热烈讨论
@twl007 我并不是推崇微博的技术,我只是反对把 HTTPS 当银弹。

安全是个体系——这句话应该为啥感觉是我应该说的呢。HTTPS 是体系,RSA over HTTPS 是奇技淫巧?
2022-09-03 00:43:52 +08:00
回复了 wenzaiquan199 创建的主题 问与答 为安全问题,早上公司热烈讨论
@twl007 为什么我看到最高赞的回答恰恰是支持我的观点的 😂

This is an old question, but I felt the need to provide my opinion on this important matter. There is so much misinformation here

The OP never mentioned sending the password in clear over HTTP - only HTTPS, yet many seem to be responding to the question of sending a password over HTTP for some reason. That said:

I believe passwords should never be retained (let alone transmitted) in plain text. That means not kept on disk, or even in memory.

People responding here seem to think HTTPS is a silver bullet, which it is not. It certainly helps greatly however, and should be used in any authenticated session.

There is really no need to know what an original password is. All that is required is a reliable way to generate (and reliably re-generate) an authentication "key" based on the original text chosen by the user. In an ideal world this text should immediately generate a "key" by salting then irreversibly hashing it using an intentionally slow hash-algorithm (like bcrypt, to prevent Brute-force). Said salt should be unique to the user credential being generated. This "key" will be what your systems use as a password. This way if your systems ever get compromised in the future, these credentials will only ever be useful against your own organisation, and nowhere else where the user has been lazy and used the same password.
2022-09-02 13:38:12 +08:00
回复了 wenzaiquan199 创建的主题 问与答 为安全问题,早上公司热烈讨论
@twl007 要是 HTTPS 就够了要那么多安全等级标准干什么,一个标准就够了
2022-09-02 13:34:59 +08:00
回复了 wenzaiquan199 创建的主题 问与答 为安全问题,早上公司热烈讨论
@twl007 拦截篡改你也得知道改哪儿才行。
2022-09-02 09:19:18 +08:00
回复了 fox0001 创建的主题 Linux [请教]是否能够不分发私钥,实现多人共享 ssh 验证?
@fox0001 jumpserver 就挺好
2022-09-02 08:55:50 +08:00
回复了 fox0001 创建的主题 Linux [请教]是否能够不分发私钥,实现多人共享 ssh 验证?
有一些开源的跳板机系统,权限管理带 webui 的
2022-09-02 08:48:49 +08:00
回复了 wenzaiquan199 创建的主题 问与答 为安全问题,早上公司热烈讨论
@Chihaya0824 只需要套一层非对称加密就行。因为 HTTPS / TLS 中验证公钥是基于证书链的,在不受信任的电脑上会很容易被中间人攻击。但是自己分发公钥就不一样了,可以固定写在源码里,也可以单独下发。别人想中间人攻击得改你的源码(下发响应),无疑是增加难度的。 使用标准 HTTPS 别人一旦针对 HTTTPS 做中间人,所有网站都跑不掉。你自己专有的加密逻辑,工攻击者需要专门针对你的代码逻辑进行攻击。

具体实践可以参考微博登录,就是使用了 RSA 加密后传输。
2022-09-02 00:47:15 +08:00
回复了 dzdh 创建的主题 Go 编程语言 在 TLS 上 Go 比 Nginx 厉害这么多吗?
Qps 相差 40 倍,带宽却几乎差不多。顺着这个往下查就行了
1 ... 2  3  4  5  6  7  8  9  10  11 ... 73  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3116 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 13:45 · PVG 21:45 · LAX 05:45 · JFK 08:45
Developed with CodeLauncher
♥ Do have faith in what you're doing.