IPv6+https+高位端口+备案域名+域名访问打不开+私下正常使用，在实践中基本安全，虽然并不严格合规

想知道为何域名不备案还要用国内服务器做后端

IP 证书自动续期比较难做，曾经能用的方法也挂了

现在的问题也不仅仅是私域的搜索聚合就能解决。很多平台的内部搜索功能很差，明明存在的东西、完全匹配的关键词就是搜不到。考虑到这些平台不缺优秀人才，怀疑是故意的。

@Internet0User 脱库的消息哪里有报道么

@Jiaan 这个可能是光猫禁止了 loopback ？（部分型号可能有开关）顺便一提，IPv6 自然就没有这个问题。

政策面推广 IPv6 的意愿看起来没变化，但运营商因为利益或者某些内外部考核可能不是很愿意

底层机制不同肯定不等价。对用户来说是否等效关键在于用途是什么。比如希望不改变原本 A/B 平面 IPTV 的同时保证外部访问内网设备 IPv4/v6 的端口，这么配置跟桥接差不多。但如果对转发性能有要求、不信任光猫的安全性、需要自己控制 IPv6 分配等部分光猫没有的高阶功能，那效果还是会有区别。

根本原因是有基于域名的通信，不是做了解析本身

不经常打开 Web UI ，但是 BT 、Syncthing 、rsync 、相册一直在提供服务

看到现在还是觉得，HTTPS 内密码只能就来解决“有坏人但又不完全坏”的场景，例如：
1. 后端人员出问题原则上什么都可以拿到。但是也许有人看到明文 log 心生歹意，但是密文 log 就不去细想。
2. 中间人出问题原则上什么都可以篡改、窃取，但是也许有中间人只会拿明文 log ，不会分析前端加密、不会篡改前端直接拿到明文。

换言之，这种方法可以增加安全性，但增加的是非常狭窄的场景。同时，给工程增加复杂性、营造虚幻的安全感也可能会降低安全性。因此，不同厂商可能会有不同的取舍。

NAS 与移动硬盘最大的区别就在于实时在线。这样就能满足数据同步、随时调取数据、PT 上传等需求。
如果没有这种需求，在可以远程启动的前提下关机也是一种折中的选项。

对于非专业用户，手机号+验证码还是最方便，国内还能顺便落实实名制。毕竟来一句密码忘了/验证器删了/Key 掉了还得用其他方法来验证。
对于专业用户，Yubikey 这种推广的麻烦点还是在于成本，基于设备本身安全芯片的 Passkey 可能会应用更广。

@ShuWei 增加复杂度有时也会降低安全

@maggch97 关键在于要说明对安全的提升有多大。如果只有十分细微的提升，虽然也是好事，但是这样场景数量太庞大，会给工程带来不必要的复杂度。而增加的复杂度又会反过来增加风险。

尝试总结一下

用户端：
恶意软件/人员有很多手段获得密码，很难想象一种只有 HTTPS 内明文才能获得密码的场景。（安全的增益太细微）

中间人：
当前移动端安装根证书很难，PC 端需要权限。如果有本事装上，那同样有很多手段获得密码。
既然是中间人，那自然可以篡改网页，从你手里明文获得密码再加密发给网站，双方都无感知。（只有当中间人坏但又不完全坏时才有意义）

服务端：
服务端的安全性根本在于维护人员的水平。维护人员安全意识淡漠，到处都是漏洞，单单密码加密意义不大。
无论前端有无加密/散列，服务端数据入库都需要再做处理。只依赖前端加盐的安全性还是很有疑问。
在某些特定场景，例如网友说的内部人员打 log 出密码。如果是密文可能懒得研究，如果是明文可能会心生歹意。在这种
情况下，加密也许存在一定意义。

关键要讲清楚，前端加密的目的是什么，要防止什么样的攻击/泄露。对于用户侧的攻击，找不要有意义的场景。对于服务侧，因为会有很多环节，加一层防止意外泄露还算有那么点道理。

个人看下来：
对于用户侧，如果恶意软件/人士已经掌握足够权限，那再 HTTPS 内再加密也没意义。关键是要找到一种场景，HTTPS 内再加密能防住、HTTPS 防不住，且这种场景有考虑的价值。我暂时没还想到。
对于服务侧，经手数据的很多环节都是能看到 HTTPS 内明文的。最典型的就是内容分发，通常 CDN 的本质就是可信中间人。如果数据流转的环节需要再加强防御，那 HTTPS 内再加密还有点意义，据要结合具体场景分析。就拿 CDN 举例，如果 CDN 是坏人，只加密密码，用户隐私、Token 等信息都是明文，那一样可以窃取信息、拿下账户、伪造信息，那加密的意义也就不是很明显。