flask

or php 一个脚本文件（如果不要很复杂的权限控制的话）

比如钉钉这种，如果一个用户有上 w 或者 10w 的会话，他的设备就已经卡死了

chrome 1.1.1.1 DoH 挺好

@Marathonk

鼠标轨迹、风险 IP 数据库、浏览器指纹等等

@iyaozhen

如果存储 1w 份 FG 内容的文档，是不是安全的

@GGGG430
咨询一下，那允许为 NULL 是什么场景。

国内加载地址： https://recaptcha.net

@thet 速度怎么样。看了看免费每月 1G 流量？

@3dwelcome #245..

跑题了啊喂。

我再再再换个说法，好吧？『在不考虑或者基本确认客户端（调用方）调用环境相对安全（ pin,cacertpem)的前提下，仅 https 并没有 md4/5sha1/256/512(sortedString+key)签名的必要』还有争议么？

@3dwelcome #242

---
所以引申出来的是，不能考虑『外在因素』，就是上面说的，客户端环境你能保证安全吗？显然并不能。客户玩了命的作死没有什么方案可以达到『足够安全』的标准。

因此引申出来的是『客户要有保障包括但不限于自身环境安全、运维、运营、审计』的『基本安全』的能力

---
https 本身就是依靠协商出来的密钥进行 aes|des/3des(已不推荐)等算法进行加密通信，只要一次性密码不被泄露就是安全的

在起码保证客户端（调用方）的基本环境安全（ pin，cacert.pem) ，出网的数据包(aes encrypted)可以认为已经安全了。并没有什么外在因素能攻破已经和服务器建立的通信。对不？


---
补充个题外回答，注意是题外。

微信证书是微信自己做的自签名 CA 颁发的，不存在『吊销』的说法，所谓『吊销』从库里删掉你的序列号就行了。
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
36:xxx:05
Signature Algorithm: sha256WithRSAEncryption
Issuer:
commonName = Tenpay.com Root CA
organizationalUnitName = Tenpay.com CA Center
organizationName = Tenpay.com
countryName = CN
Validity
Not Before: **** GMT
Not After : **** GMT
Subject:
localityName = Shanghai
countryName = CN
organizationalUnitName = \U4E0A

@1iuh #240

可说是捏 我认为但凡有『其他因素』考虑，就没有安全。我就人为的作死看谁拦得住我。

@3dwelcome #237

你这又绕回来了啊。

按你说的，让你去搞个接口，用这个方案你是不是敢赔钱？你敢我就敢。这不成了抬杠了吗？

何时强调过『 100%的安全』直说『足够』呢。

我再再换个说法好吧？不要考虑任何因素，就说 RSA 算法这个本身，数学上，是不是足够安全？是，那就对了，不是，请反驳。

@1iuh #235

这就是我的本意 ，就安全来说，已经是足够的。

-t, --time int Seconds to wait for stop before killing it (default 10)

@3dwelcome #232

刚换的 KEY 我又泄露了

@timedivision #231

所以是看公司或企业要进行怎么选择。

我是对的，你是对的，所有人都是对的。没有错的（技术性概念问题搞错除外）方案，只有合适的方案，合适的方案就是对的方案。

@3dwelcome #228

然后刚换的 KEY 我又泄露了。

@3dwelcome #228

怎么定义『短期』。1 天？ 1 小时？ DV 证书重新签发 1-3 分钟。

@Rheinmetal #224

我能想到的只有『没有业务唯一标记的业务』无法防止。否则其他场景像支付下单，你要传调用方本地订单号可防重放，关闭订单传订单号可防重放，但是像浏览器端的 event 日志，那的确没法防，因为请求进来就直接入日志库的。


@3dwelcome #225

这就不对了，那 HTTPS 出来以后还有 http2 呢，TLS 还有 1.0/1.1/1.2/1.3 呢。方案是不停进步的，出了 TLS1.3 也没必要全球废止 TLS1.0 对吧？

如果要『扯中间环节』那就一定要说密钥保全，这又是『客户端环境安全』的问题，我就故意泄露密钥、私钥。绕回来还是『无绝对』。但是这依然不能证明帖子标题是『不足够安全』的，我还是明白不能。


@timedivision #226

所以到底应该怎么定义『足够安全』合『绝对安全』。首先『绝对安全』是不存在的，也没必要也不可能做到『绝对安全』。所以为何标题就『不够安全』，我认为就标题的安全防护策略、手段在所隐含的『安全缺陷』在『签名(mdX/shaX(sortedString+key)』都能找到对应的。这并不能成为帖子标题的方案就是『不够安全』的理由吧？

@3dwelcome #221

『安全』应有『度』，要比极致请参考 210 楼

> 真要说安全大可以硬件加密狗+DNA 验证+虹膜+人脸+物理快递安全设备+面对面认证+指纹授权。一次 HTTP 请求等 10 年，但是这不是『根本没必要』吗？

即便用了上述所有手段就『真的『绝对』安全了吗』？但是也不能因为『无法保障绝对安全』就不做任何措施

在世界公认的 RSA&ECC 保护下已经有了这个『度』适应的安全保障。已经『够了』。

下班回家，离门 10 米自动开门，进屋自动开灯全凭身上一部手机和人脸。都『足够的安全』了。但是如果要说的话，这安全吗？装门干啥？有啥门是一锤子解决不了的？要密码干啥？银行就不能被抢了？我一定会懊悔为什么没装两个门，为什么没给家里装防弹玻璃，为什么没把密码设置成 100 位锁在银行保险柜里。

这不都是因为已经『足够安全了』吗？

就像有人在反复强调客户端的问题，我的观点是：针对于客户端，你任何的安全措施都没用，就像上面所有安全措施加一起，我就愣把密钥给出去，开源放到 github 上你凭什么保护？对客户端来说，也是需要他自己具备『安全自保能力的』。

核心论点是：足够的方案措施