V2EX › summertimesad 的所有回复 › 第 11 页 / 共 33 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 7 8 9 10 11 12 13 14 15 16 ... 33

❮

❯

2024-06-06 14:28:40 +08:00

回复了 vincent13 创建的主题 › 职场话题 › 降薪 30%，纠结要不要接

@vincent13 还有 Booking 也可以看看，我记得前几个月他们在招 Junior 的工程师；
途径：LinkedIn 、公众号

2024-06-05 23:55:28 +08:00

回复了 vincent13 创建的主题 › 职场话题 › 降薪 30%，纠结要不要接

可以考虑看看 kong ，他们在 v 站招聘后端工程师，没说是 senior 级别，那我想以你的背景应该可以试试；
另外虽然这个岗位使用 go ，不过于你而言 j2g 应该比较容易吧

2024-05-31 08:55:39 +08:00

回复了 lijiayuan 创建的主题 › 职场话题 › 垃圾 offer 选择求建议

选 1 ，这环境下还考虑什么外包影响不影响的啊

2024-05-29 09:13:10 +08:00

回复了 jayjoe 创建的主题 › 职场话题 › 有人了解 CoinMarketCap 吗

老哥脉脉上看到的这个吧？约面了吗？
上上周投了简历没反应

2024-05-28 14:00:56 +08:00

回复了 Light1226 创建的主题 › English › 100 天英语突击计划

建议重点：围绕自己的生活/工作写 100 个中文情景对话；再根据 12 楼的方法去做，每天俩小时。
能够做到随时把自己想说的话用英语说出来就算毕业了。
加油，我也在练习！

2024-05-23 19:00:21 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@jianchang512 是的，脱裤的例子不对

2024-05-23 18:58:43 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@javalaw2010 感谢讨论。
这两点都是建立在传输通道不安全的基础上得出的结论，就是不光 http 不安全，也不放心 https 的安全性，认为都有可能被入侵而拿到传输的密码明文。
既然大家都认同 https 是安全且极难入侵的，那么我的观点的前提就不成立了。

第一个问题：能登陆，都拿到明文密码了，反过来就不行了（这也是 hash 存储的目的）；而前端 hash 的目的是防止在传输通道拿到明文，我前面说的脱裤的例子是错误的，无法证明这个手段和目的的合理性。

2024-05-23 18:42:02 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

我的“前端需要 hash 传输密码”的观点，是建立在传输通道不安全（非源头，如 web 、iOS 等）的前提下，因为当时使用 http 的服务还有不少，加盐 hash 是为了防止传输通道被入侵时拿到明文密码；而在 https 是安全且极难入侵的传输通道的前提下，那我的观点的前提就不成立了。感谢普及 https 安全性的 v 友。

此外我有个问题希望和大家讨论一下：
密码是否应该在整个服务的流转过程中都是安全且不可接触的呢？
换句话说，如果服务端接收且打印了（或其他形式）明文密码，而这个信息可以被普通权限的开发者或员工接触到的话，作为用户是否可以接受呢？

2024-05-23 17:51:34 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@abelyao 无论你的还是我的，都是个人观点，可以给出论据来讨论，直接傻叉的话这话并没有分量。

我入行才 9 年多，也不算久，说 14 年入行也不是为了说明自己资历老就是对的，而是说明一下刚入行的时候就接受了这个观点的影响

2024-05-23 17:45:53 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@Trim21 没细看，太长了，只看了第一页的一半大概

@dode 嗯，个人观点

@ntedshen 感谢代码分析
另外贞操锁钥匙别外面这个比喻不太恰当，如果仅仅 hash 的话这么说没毛病，毕竟大部分用的 hash 函数都是 md5 ；
而加盐哈希，每个服务的盐不同，相同的密码得到的摘要也不同，更像是每个服务都有自己的贞操锁

2024-05-23 17:31:23 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@zero47 嗯，是的；
不过还有日志打印密码的骚操作。。。这个素养还真不是每个程序员都有的啊；基于此，那么在架构设计时确定前端 hash 后传输，也可以防止这些情况的发生。

2024-05-23 17:26:43 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@mohumohu 挺有意思的，如果 Google 和 GitHub 也认为明文传输是合适的，那你们对；
而我坚持自己的观点。

2024-05-23 17:19:29 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@mohumohu 本帖的第二个问题被忽略了，大家都在讨论明文传输的问题

@june4 前端可以扩展到 Web 、iOS 、Android 等等

2024-05-23 17:15:22 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@FTLIKON 我没说过 MD5 是加密算法啊。

2024-05-23 17:00:55 +08:00

回复了 summertimesad 创建的主题 › 程序员 › 请 [吸词] 的作者出来解释一下密码明文传输的问题

@FTLIKON
@YogiLiu
@javalaw2010
@povsister
@zero47
个人不赞同 https 就可以明文传输密码的观点。
从我 14 年入行时就接受了密码必须 MD5(加盐更好)后传输，服务端也不存明文密码，防止被脱裤的观点。

@YogiLiu 是的第二个，“如果你想表达的是这个插件每到一个新的网站就会把你的「吸词」账户信息发给这个 URL ”

@povsister 非重要网站一般是通用一套

@Jirajine 确实，难以认同 HTTPS 就能明文传输的合理性

1 ... 7 8 9 10 11 12 13 14 15 16 ... 33

❮

❯