自适应http与https，密码加密传输 #21
Conversation
| <script src='//fastly.jsdelivr.net/npm/js-md5@0.7.3/build/md5.min.js'></script> | ||
| <script> | ||
| function md5zme() { | ||
| document.getElementById('password').value = md5(md5(document.getElementById('password').value)) |
There was a problem hiding this comment.
两层甚至3层md5对于前端密码hash而言跟1层都是差不多不安全的
https://cmd5.com 这样的彩虹表早就算出了许多常见密码排列组合的hash
建议直接hmacsha256
提请四叶信安底层壬上壬上海贵族 FSF EFF 精神会员杨博文阁下 @yangbowen 立即评估如何在前端层正确地hash提交给后端的明文密码
|
我看这样改了后，存放在OneDrive中的密码就是明文了。 |
|
我建议你在仔细看一看，这么做之后，配置里存的是明文密码的md5，传输的是明文密码md5再md5，框里输入的是明文密码 |
再看了一眼，原来是套了两层，我先merge一下，后续有更改再说。 |
我认为客户端 hash 一遍，传给服务端，服务端再 hash 一遍，确实已经是比较不错的做法了。 除了就是， MD5 不推荐，以及加盐很有必要。对常见密码的现有彩虹表是一个非常实际的威胁。而且在撞库的情况下，一个如此快速的 hash 算法意味着用户必须使用密码熵很高的密码（64位以上）才够安全，实际上密码熵通常是远远达不到的。 最后，“客户端发送（可能被 hash 的）秘密以向服务器验证身份”本身有不小的安全不足之处，具体来说就是攻击者截获了传输的信息的话直接重放该验证凭据（不论它是明文密码还是 hash 过的还是加盐的）就可以冒充。因此比它进一步改进的话就是 challenge-response 这样的验证方式。 |
|
TL;DR: 没有银弹，能用就行 |
所以大多数php小子都是无脑两层
然而大多数实践都是服务端数据库里加盐，而不是服务端把数据库中存的每用户的盐传给客户端再让客户端自己hmac
php人最常用的是bcrypt，因为有自带的
然而带pm们缓解replay attack大多只是加了个只有客户端能生成的基于当时时间的随机数来保证客户端每个请求是唯一的，我也不知道这是不是掩耳盗铃
现实中的challenge：2FA 短信验证码 人脸识别 手持三件套，然后服务端还是存着您的明文密码（您也不知道贵司收集了您的个人信息后还是否对密码上心，很有可能两者都是无加密/混淆的，简简单单拖个库恶俗狗狂喜户籍满天飞）
经典CSRF |
|
奇怪的知识增加了 |
|
安全领域的水是真深啊 |
|
经典phper转golang兽的印记 |
不。基于 PAKE 的协议应该是目前的顶尖水平，但是使用率非常低。我听说的只有暴雪战网是用 SRP 这个 PAKE 协议的，绝大部分场合都是直接用 HTTP/HTTPS 传输明文密码或密码的散列。但是 SRP 很老了，有些设计也不那么好。更新更好的 OPAQUE 目前还是 draft 。但总之 PAKE 才能提供传统方式不可能兼顾的一些安全性要求。事实上，
对称加密（AES）、散列（SHA-256）、非对称加密（RSA）、数字签名（RSA、DSA）这些传统的密码学原语全都不具有同时实现以上两项要求所需的数学结构， PAKE 是基于 离散对数 的原理发明不同于 TLS 所使用的那些的新的计算方式的。 |
是的，这也是属于非 PAKE 的传统方式不可能顾及的问题。它甚至不在于 在服务端加盐，意味着在以下情况下，攻击者能够对密码展开有效的（不受登录尝试次数限制的）穷举：
且在以下情况下，攻击者直接能够冒充合法用户进行登录：
在客户端加盐，意味着在以下情况下，攻击者能够对密码展开有效的穷举：
且在以下情况下，攻击者直接能够冒充合法用户进行登录：
顺带一提，对于以上所有情况除了 |
|
所以
然而事实核查：截止2023年3月，以
哪儿两项？保护低熵密码和防止replay attack吗？
https://en.wikipedia.org/wiki/Discrete_logarithm#Cryptography 进一步指出
那tls又用的啥？ECDH？可tls不是一系列可用加密算法（包括ECC系列）的组合标准吗？ |
为什么？
盐不是每用户设置的吗？不论是仅服务端知晓（服务端加盐）还是服务端客户端都知晓（客户端加盐） 如果在服务端和客户端都每用户加两种不同值的盐，是否能够同时避免上述两种模式的缺陷？还是反而会同时具有两种模式的缺陷？
于是共同造就了以2FA 短信 活体 三件套为代表的challenge-response模式的不同本地化实现特色形态的信安现状：
|
通过 TLS 信道进行身份验证的情况下，若下层 TLS 信道未受攻击，则 TLS 已经对重放攻击提供了防御措施，主要是 TLS 会话密钥的产生。我前面说的是当 通过明文信道进行身份验证 或 通过 TLS 信道进行身份验证，但该信道被攻破 的情况。 我不太懂您说的
服务器端 hash 防 1 不防 2 。 challenge-response 防 2 不防 1 。而且您无法同时实现这两者因为 challenge-response 要求验证者（服务器）掌握相同的共享秘密。
通常的上网冲浪中使用的 TLS （例如你我现在与 https://github.com 通信所使用的 TLS ）使用了对称加密（AES-128）、散列（SHA-256）、非对称加密（RSA）、数字签名（RSA或ECDSA）、密钥分发（DH或ECDH）中的若干个。 事实上， TLS 也有 TLS_SRP 的 ciphersuite ，以及将来也会有 TLS_OPAQUE 。但用于 TLS 的情况下是类似于 TLS 客户端证书那样的用法，我几乎没见过哪个网站用 TLS 客户端证书。想来网站设计者大概也会更多想自己设计用户验证的 UX 而不是交给浏览器。 |
客户端加盐的情况下，客户端必须知道盐才能完成计算；可是在客户端完成计算前验证不可能完成，所以服务端必须向尚未验证其身份的客户端展示盐的值。因此，攻击者只需要作一次失败的登录尝试，就可以知道这个用户的盐是多少，就可以开始计算针对这个用户的彩虹表，并在将来攻破数据库之后快速（早在服务端管理人员反应过来之前）破解该用户的密码。
我不晓得。
能避免，但仍然达不到 PAKE 的安全等级。不加盐相当于加空的盐，所以不存在加了盐反而更不安全了。 但是您在别人的 repo 上 spam 无关信息，真的好吗？ |
你说得对，但是您访问的页面不存在。
在目前这个现状当中，安全起见，用户应该假定网站对自己的密码不上心（假定网站就直接明文存储了自己的密码），而网站应该假定用户对自己的密码不上心（假定用户设置了很弱很好猜的密码）。 |
tls的确自带防范基于网络层mitm抓包然后重放的replay attack，然而客户端层面可能本就不安全，经典高权限的chrome扩展监听所有请求然后上报给俄罗斯带黑阔（21年鸡血神密友上海贵族 @Juicpt 神被黑事件）
经典中国特色CNNIA 12306根证书 和360浏览器根证书计划 https://www.zhihu.com/question/306156963
经典老程序用着静态编译嵌入的还受到 https://en.wikipedia.org/wiki/Heartbleed 影响的远古版本openssl 1.0.1a
经典鸡生蛋问题，我说的nonce主要是指为了防范csrf中的replay attack用的csrf token，如百度贴吧的
为什么？如果攻击者知晓了某用户的密码hash和salt，那他不就可以模仿客户端的网络协议传输
这是replay attack的推广？
这也是为什么事实上
带数据巨头都是明文存储着您的手机号身份证三件套的，否则他们不可能对您的challenge结果进行验证
如果我的
pake在数学上使用什么工具作为构造他的安全性基础的形式化论证跟这个工具能实现什么没有必然联系，不然为什么用于密钥分发的dh就不能实现pake呢？
tls的密码学武器库中给用户提供了什么工具和用户能否在浏览器环境中使用他们也没有联系，那几个浏览器垄断寡头们真的实现了这些吗？建议检查 https://chromestatus.com 并前往 https://crbug.com 提issue
|
也就是我所举的例子
本质上还是鸡生蛋问题
避免哪些？所有杨博文阁下于 #21 (comment) 中所提到5大诉求吗？
那杨博文阁下也可以选择立即自愿加入充斥着
的邪恶组织v2ex与各路泰国第几的计网信安中级高手们进行全自动抬杠： https://www.v2ex.com/t/909154?p=1#r_12582291
而 |
来丶音游圈垃圾话： 你说的对，但是《你说的对》是由你说的对自主你说的对的一你说的对的全新你说的对。你说的对发生在你说的对个被你说的对「你说的对」的你说的对，在你说的对，被你说的对选中的你说的对将被你说的对「你说的对」，你说的对你说的对。你说的对将你说的对一位你说的对的为「你说的对」的你说的对，在你说的对的你说的对中你说的对你说的对、你说的对的你说的对们，和你说的对一起你说的对，找回你说的对——同时，逐步你说的对「你说的对」的你说的对。 你说的对 但是《Linux》是由Linus自主研发的一款全新开放源代码操作系统内核。使用该内核的系统运行在一个被称作「ext4」的文件系统，在这里被Kernel选中的人将被授予「Terminal simulator」，引导Shell的力量。你将扮演一位名为「Root」的神秘用户，在自由的使用中邂逅不同开源协议、各有千秋独特的桌面环境和各种软件们，和它们一起服务器运维，找回丢失的软件包的同时，逐步发掘「/dev/null」的真相。 你说得对，但 #21 (comment) 中对此登录可见的讨论串的长截图中就有着数月前杨博文阁下的身影
而当下流行的0信任模型 https://en.wikipedia.org/wiki/Zero_trust_security_model 也就是对这种恶俗互联网信安现状的无米线推广 |
不能。在 hash(hash(password, salt)) 这种方案当中，服务器数据库存储 hash(hash(password, salt)) ，但客户端必须传输 hash(password, salt) ，所以攻击者知晓了 hash(hash(password, salt)) 也必须做一轮穷举才能冒充用户。
是的。在上面说的方案当中，如果攻击者取得了客户端传输的 hash(password, salt) 那么重放这个值就可以冒充了。
是的。身份证系统和 PLMN 完全可以实现得好得多，并杜绝相当一部分现实中的攻击，假如他们不是那么垄断僵化的话。
建议您立即单击 F12 找到当前连接使用的 ciphersuite 信息
建议阅读 https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Protocol 这部分。 |
能避免凭借服务端数据无需穷举即可冒充，也能避免凭借通信内容太容易（指使用通用的彩虹表）穷举到用户的明文密码。不能避免凭借通信内容即可冒充。
顺便咱觉得就语言交流来讲您的智能程度以及类人程度并比不上 ChatGPT ，更像一个智能程度不高但并不会经常错误理解人类语言的 chatbot 。
这个咱倒是暂时没有这样的打算。 |
您举的例子是服务端客户端分别两层hash，这是十分常见的场景（如同本pr的 #21 (comment) 对此也有阐述
然而利用2G 3G设计缺陷的伪基站降级攻击都算是有技术含量的了（攻击者至少需要采购硬件并在受害者附近部署）
用户由于短信和呼叫都被静默转发走因此他完完全全不知道验证码和异地登录（攻击者也可以使用用户所在省市（现在网络平台主动开示用户ip归属地后更容易知道了）的ip代理（灰产大量出售的家宽代理）登录以避免触发异地登录的额外验证和警告）的通知
建议直接curl或是wireshark抓十万甚至九万包进行深度包检测 $ curl -v https://github.com -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 20.200.245.247:443...
* Connected to github.com (20.200.245.247) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS header, Certificate Status (22):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.2 (IN), TLS header, Finished (20):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2459 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [78 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* TLSv1.2 (OUT), TLS header, Finished (20):
} [5 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
* start date: Feb 14 00:00:00 2023 GMT
* expire date: Mar 14 23:59:59 2024 GMT
* subjectAltName: host "github.com" matched cert's "github.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x55eee275e550)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
> GET / HTTP/2
> Host: github.com
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [57 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [57 bytes data]
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
< HTTP/2 200
< server: GitHub.com
所以造成了十几年来的刻板印象之https比http更慢，事实上对于
所以现在最新的tls1.3如何根本上避免了这种在tls握手阶段mitm拦截并重发伪造的握手包以要求双方使用已知不安全的ciphersuite的降级攻击？ 截止2023年3月，我仍未能完全理解早在21年就由 奥利金德c#头子 @CFPABot 作者osu!std中级高手 @Cyl18 所完全剖析了的tls forward secrecy
因此即便服务端被拖裤后攻击者也无法从静态的数据库中得知客户端登录时的网络请求是什么样，除非他又去做爬在网线上的mitm监听服务端<->客户端流量
|
那么从杨博文阁下指明的这5大诉求来看，实际上对用户而言比较透明（用户仍然只需要使用传统的账密模式登录）的 服务端客户端都加两次盐 方案反而比时下流行的各种迫真challenge-response实现之2FA TOTP 短信验证码 生物识别 身份证号等特色贵物能够抵御更多的攻击场景
继 https://t.me/s/n0099official/1763
https://t.me/s/n0099official/1683 https://t.me/s/n0099official/1715 https://t.me/s/n0099official/1727 https://t.me/s/n0099official/1738
https://t.me/s/n0099official/1746
ChatGPT：变人——抖音百家号营销号文风配合VALL-E TTS服务读稿车轱辘话： https://www.v2ex.com/t/919096
进一步的，杨博文阁下也可以选择借自musk收购twitter数月来的数字难民大潮自愿加入由 |
避免在使用http服务时使用https加载资源文件
密码加密传输，避免在http被抓包或是https中间人攻击
使用多次md5的中间值进行传输匹配，传输的内容与密码本身，配置文件中的md5都不同，避免撞库