lesismal's repos on GitHub
Go · 2036 人关注
nbio
Pure Go 1000k+ connections solution, support tls/http1.x/websocket and basically compatible with net/http, with high-performance and low memory cost, non-blocking, event-driven, easy-to-use.
Go · 889 人关注
arpc
More effective network communication, two-way calling, notify and broadcast supported.
Go · 103 人关注
go-websocket-benchmark
Go · 42 人关注
nbio-examples
Go · 11 人关注
llib
Go · 6 人关注
pipe
Go · 5 人关注
cbuffer
Go · 5 人关注
go-net-benchmark
Go · 3 人关注
go-http-server-benchmark
Go · 2 人关注
noleak
1 人关注
conc
Better structured concurrency for go
1 人关注
Developer-Books
编程开发相关书籍整理分享,持续更新...
Go · 1 人关注
perf
Go · 0 人关注
awesome-go
A curated list of awesome Go frameworks, libraries and software
0 人关注
cli
GitHub’s official command line tool
0 人关注
emoji-cheat-sheet
A markdown version emoji cheat sheet
0 人关注
engineering-blogs
A curated list of engineering blogs
Go · 0 人关注
gevent-benchmark
Go · 0 人关注
gin
Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.
Go · 0 人关注
go
The Go programming language
Go · 0 人关注
gopkg
Universal Utilities for Go
0 人关注
guide
The Uber Go Style Guide.
Go · 0 人关注
gws
High-Performance Go WebSocket Server & Client
0 人关注
http-parser
http request/response parser for c
Go · 0 人关注
kcp-go
A Crypto-Secure, Production-Grade Reliable-UDP Library for golang with FEC
Go · 0 人关注
kitex-benchmark
0 人关注
lesismal
HTML · 0 人关注
lesismal.github.io
Go · 0 人关注
melody
:notes: Minimalist websocket framework for Go
Go · 0 人关注
mempooldebug
lesismal

lesismal

V2EX 第 497905 号会员,加入于 2020-07-06 13:49:58 +08:00
今日活跃度排名 1256
美国宣布全面禁止竞业协议
程序员  •  lesismal  •  9 天前  •  最后回复来自 ChrisFreeMan
2
github 被人 at 说币安空投,是诈骗吗?
程序员  •  lesismal  •  143 天前  •  最后回复来自 lesismal
2
4C-2G 来战 [ Golang Websocket 百万连接测试 ]
程序员  •  lesismal  •  163 天前  •  最后回复来自 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 最近回复了
    > 你前面帖子里说的是老网站用 1 的问题, 所以我只解释解决 1 中用明文的问题的成本, TOTP 这些都是属于密钥本身格式之外的, 不管密钥用明文还是哈希盐, TOTP 之类的这些都可以加, 所以这个成本不应该用来对比密钥格式本身的成本.

    @ZE3kr 我不确定是否有误解你 #13 的 1, 因为你说的是密码, 没说是明文密码, 我快速扫内容以为是按照主题在聊密码用明文相关的. 但是你的 2 中有说 HTTPS+前端加密的 跟 1 一样不安全, 所以 1 中应该就是指明文密码, 否则 1 和 2 就一样了, 我有点迷惑. 另外, 这里 2 中通常不是加密, 密码不会太长当然加密算法也能用, 但通常是 hash 指纹这些
    @night98 #20

    > 3.服务端安全 现在基本上都标配 Bcrypt 了吧

    Bcrypt 可不一定是标配, 这玩意防爆破拿手但是成本高

    同样的, 我就想请教下, 为什么淘宝亚马逊不用明文
    > 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
    > 因为这才是正确的路线。放弃密码,不要用 what you know 而用 what you have 。

    @msg7086 这个正确路线有前提, 要有 app 已经设备认证过然后能扫码. 否则 SMS OTP 或者加上两步验证之类的才安全, 事实上很多大站也确实加了两步验证, 但他们照样也不使用明文, 比如淘宝.

    所以我也请各位再看一下我 append 里面的, 为什么很多大站们不用明文. 不要用 github 用明文来反驳了, github 非金融类的安全级别要求算是偏低的了而且因为这明文被爆料过的
    @msg7086

    > 1.为什么成本没增加。

    一个哈希盐算法, 设计初期就用上的话也不涉及日后把明文升级哈希盐水, 所以就是初期前端的一层包装, 这个成本你给我说有很大, 那我只能表示佩服了

    > 2.增加到什么程度才够?
    > 就比如你说的多加一步加密没有成本,那为什么只加一步加密,为什么不加密两次,加密三次?为什么没有成本的加密只做一次。
    > 如果加密多次也没问题,那么加密五轮就够了吗,还是五十轮呢,或者五百轮?

    清醒点, 这里说的是流程上的明文 vs 哈希盐, 你用什么哈希盐算法是你自己的事情, 里面加密多少次是你自己的事情, 但是对于明文->哈希盐的流程只是一个步骤

    你说这个一轮流程加密多少次, 就是硬杠了
    @ZE3kr #48 标题确实, 我在 append 里有解释了. 因为引用的隔壁帖子, 都是关于 https 载体之上的, 这个帖子起标题时没注意标点符号导致了你的误解, 但是内容上, 并不是在说 https 本身是明文, 我本身也强调了 https 解决中间人

    > 你这里列举的成本就已经比 TOTP 高了

    你前面帖子里说的是老网站用 1 的问题, 所以我只解释解决 1 中用明文的问题的成本, TOTP 这些都是属于密钥本身格式之外的, 不管密钥用明文还是哈希盐, TOTP 之类的这些都可以加, 所以这个成本不应该用来对比密钥格式本身的成本.
    > 如无必要勿增实体

    @pandaidea 这句话是对的. 安全场景不是"无必要"
    > 但是却从来没考虑过,前端加密也好哈希也好,是有可能更不安全的

    @icy37785 因为是跟明文做对比, 所以我认为你这个观点是指 前端加密哈希后可能比明文更不安全? 请教, 什么情况下会比明文更不安全? 因为我暂时想不到例子
    @ZE3kr

    > 首先用了 HTTPS 就不是明文传输密码了。标题本身就是伪命题

    兄弟你应该是没有仔细阅读我帖子的内容, 请先读完再说这观点

    > 老网站用 1 是历史遗留问题,1 升级到 2 必然是有成本的,不如直接升级到 3 和 4 。

    其实成本不高, 主要成本应该是两方面, 一是客户端方面的, 比如原生客户端升级空档期, 而是服务端方面的, 比如用户量巨大不能短时间内全部更新成 hash 盐, 需要停服维护或者新增表项. 服务端的代码修改相对简单, 例如明文和 hash 盐都判断, 两个失败才算失败, 然后更新数据也可以跑任务分批完成所以不影响性能和业务.
    > 而对于“不”注重安全的用户来说,你说的这些又有什么意义呢?人家根本不 care 。

    @cmdOptionKana #11 在普通领域, 五十步笑百步确实没什么意义. 但工程密码安全这个领域一百步就是比五十步要强的, 建议各位看下 #7 @cndenis 说的纵深防御原则, 刚好 CF 上也有介绍, 这里面有 "加密" 的一段:
    https://www.cloudflare.com/zh-cn/learning/security/glossary/what-is-defense-in-depth/
    @cmdOptionKana #5

    > 想做坏事的人拿到这个哈希值可以直接走 api 发给后端,这与明文有啥区别?

    @cmdOptionKana 是有区别的.明文比 hash 具有更多的被窥探可能性,所以说的根本不是后续接口持有你的明文或者 hash 的问题。
    至于拿到这个哈希值可以直接走 api 就更不太符合实际了,实际工程中多数不是每次带上密码明文或者 hash 去做校验,例如 web 前端,登陆认证通过后利用 server 返回的 token 、然后 cookie http only ,这种 token 具有时效性、或者再次登陆时旧的 token 失效。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1162 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 22:57 · PVG 06:57 · LAX 15:57 · JFK 18:57
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.