V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  acess  ›  全部回复第 34 页 / 共 110 页
回复总数  2188
1 ... 30  31  32  33  34  35  36  37  38  39 ... 110  
2020-11-25 13:48:13 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty 我感觉你似乎有点误解。我并没有问 50 元扳手攻击这种问题(虽然我的想法和 50 元扳手攻击也差不了太多了)。

但是,如果你要问我,我能保证我的电脑系统完全干净么?我没有信心回答“能”——这并不是因为我把电脑物理上随随便便给了陌生人使用,而是因为我并不是个“清教徒”式用户,很多时候我也会“从网上乱下东西”(比如 V 站一直在抵制的,盗版 /破解)。

即便我说了类似“大概可以吧”,这样的答案,也是觉得“如果不这么想,那电脑就压根不能用了,因为每时每刻都有被害妄想(笑)”。

“有人直接 [物理上] 给你在 PC 上安装监视系统怎么去防护?”
很多时候并不需要物理上进行这个动作——当然,即便不是物理上这么做,这个问题大概也还是无解,甚至是没有什么意义。
2020-11-25 12:29:16 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty
首先我没有假定攻击者拥有无限的资源……实际上放我自己身上,我肯定愿意用带有现代 KDF 的产品,以“输密码时卡上几秒”的代价,换取安全性显著提升(按我的理解,就是等效于密码被追加了好几个难记的随机字符,有了 KDF,我不用记忆它们也能达到一样的效果,更不用提对跨站撞库的防御),很显然是值得的。
不过,我也不知道一个现代的 KDF 在典型情况下到底能增加多少强度。

其次,我觉得“安全性”这个概念不止涉及保密性吧?可用性其实也是安全的一个范畴。比如勒索病毒把文件加密了,这很显然是安全事件,但是未必涉及泄密(虽然有些勒索黑客现在确实在用泄密作为要挟条件)。

“反过来也是一样,如果有人知道主密钥,拿不到数据库文件也没辙。”
确实是这样。但是我觉得有不少情况,比如电脑中键盘记录木马这种情况,都已经拿到主密钥了,这可能已经是整个系统被攻陷的情况(对于个人用户来说,管理员特权也许不是特别重要,就像 xkcd 1200 ),顺带着拿到整个数据库也就不是难事了。
2020-11-25 12:19:41 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty (稍微搜了一下,比特币官网的情况,貌似是最后一个 web 钱包被下架了,在这之后才连带删掉整个 web 钱包分类。最后一个 web 钱包是 Coin Wallet,不过下架的理由好像主要是没有告知的收费,貌似还不涉及“远程加载代码”这个问题)
2020-11-25 12:12:32 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty (啊,好尴尬……发完帖子才发现,其实网页钱包现在已经从比特币官网的推荐列表里删去了……不过我还不知道具体理由。稍微搜了一下,下架 btc. com 的理由貌似是 HSTS PKP 时间不够长)
2020-11-25 11:55:04 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty 回到楼主这个作品上……

其实网盘云备份,就不是黑箱了么?同样是黑箱不是么。要说封号,网盘同样可能封号,无非就是封号的缘由(以及几率)可能不太一样。

理论上微信小程序也许可以被腾讯篡改——这里我又要拿比特币类比了,比特币官网在推荐钱包软件时,有一个扣分项,就是“远程加载可执行代码”(案例就是类似 blockchain. info 、btc. com 之类的 web 钱包)——看上去微信小程序在这一点上就不幸中招了。
“远程加载可执行代码”为啥会成为扣分项,我觉得不难理解,应该还是因为“确认公开的源码是否对应实际执行的代码”这个问题吧,理论上网站如果被黑或者作恶,随时可以偷换成恶意代码。
但是呢,即便是讲究“去信任化”到极致的比特币,好像也没有在官网上直接“下架”这种有扣分项的钱包。虽然这确实是一个扣分项,但这个扣分项好像也并不至于那么致命吧。

最后,包括我自己在内,看到楼主这个帖子,可能很多人脑内第一个浮起来的概念是“国内 /国外”,哪怕想起“经过剪贴板可能不安全”都不是第一反应。
2020-11-25 11:42:26 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty
简而言之,根据我的认识,KDF 是很有意义的技术,尤其是可以防止大规模、跨网站的撞库;但并不能因此神化它(不过我并没有说你有意在神化它)。

“成千上万倍”,这种叙述可以给人直观印象;但实际上,它真的有化腐朽为神奇的、不可思议的效果么?我感觉,未必。

我之前提到“KDF 和几个随机字符效果差不多”——我的这个叙述同样是不准确的。“合法用户只需要支付一次运算代价”,这个我还是知道的。


提比特币,是基于我之前提到的一个理解:“之所以会有 KDF,根本上是因为人类很难设置、记忆熵值够高的密码”。比特币用 12 个单词的助记词,即可表示 128bit 的熵,在我看来还是很有启发意义的,虽然实际上比特币钱包还是放弃了让用户记忆这 12 个单词(本来“助记词”这个名字就是“辅助记忆”的意思,不是么),转而引导用户把它抄写下来,所以还是绕回了问题的原点、没有很好地解决这个问题。
2020-11-25 01:07:46 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty 我会想到这个暴论,主要是因为我看过对于比特币脑钱包的批评。
比特币的账本全部是公开透明的,就好像一个天然公开的“账户密码数据库”,而且没有加盐、没有 KDF——传统的比特币脑钱包就是把人脑想出来的密码简单地哈希一遍,然后就直接用作私钥了,接着,从私钥得到公钥、地址这个计算也没啥成本。
攻击者只要暴力穷举,找到私钥,就可以直接把币转走。

所以说,解决这个问题的对策,就是用轮次足够多的 KDF 加盐?

很显然这样就跑偏了,不是么。
如果我没理解错,KDF 对于攻守双方是平等的,想要 KDF 增加多少强度,用户自己在正常使用的时候也要付出等同的计算量代价。换句话说,引入 KDF 后,每次输入密码时,机器“卡”了多久,就代表密码被 KDF 增强了“这台机器能够在这么长的时间内,能够穷举破解出的密码”这么多的强度。

KDF 的轮次不可能无限地往上加,于是,通过 KDF 得到的强度提升也很有限。
换句话说,再怎么折腾 KDF,也不可能让本质上就不安全的脑钱包安全到哪里去。


现在比特币的钱包一般都是用一个助记词来作为随机种子生成私钥,最常见的 BIP39 助记词是 2048 个单词表里随机抽取的 12 个单词,用来编码表示 128bit ( 132bit 里有 4bit 被用作 checksum 了)的熵。

不过说实话,比特币貌似也并没有解决这个问题……而且 BIP39 助记词里也是用了 KDF 的(大概是因为除了 12 个单词本身之外,还是一个可选项 passphrase,也是人脑想出来的附加密码)。

现在主流的钱包会引导用户把助记词写到纸上,和柯克霍夫原则里的“密匙必须易于沟通和记忆,而不须写下”,也是背道而驰吧。
2020-11-25 00:33:26 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty KDF 这个东西,我记得在哪里看到过,本来就是因为人脑想出来的密码熵值不够高(具体熵值有多少,貌似也是根据具体情况的,取决于破解者猜测密码的能力,“会不会编字典”,好的字典能大大缩小搜索范围),现实中想让人类想出熵值够高的密码又太难,所以就有了这么个既不打扰用户,又能弥补“人脑想出的密码熵值低”这个缺陷的技术。
所以……我就有了一个暴论:如果可以直接用靠谱的办法生成随机密码,然后人脑可以直接记下它,那(从个人使用角度考虑,而不是从“宏观”的视角来看)效果和用了 KDF 也差不多。
(如果一个密码在多个地方被重复使用,那问题就很大了……不过,能想到用密码管理器的人,让他不要犯这种低级错误,貌似也不难吧)
2020-11-25 00:26:53 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty 我第一次看到加盐这个概念时,也非常折服,印象中大概是“即便被拖库也仍然能保证安全”,但是后来仔细想了一下,现实中好像还是蛮鸡肋的——都拖库了,可能有价值的数据本来就已经一波带走了,说不定服务器后端什么的都被注入了恶意代码,被攻击者实时视奸着呢?
打个可能不恰当的比方,就好像 WinPE 破解 Windows 登录密码一样……即便不去破解出明文的登录密码,实际上系统里有啥,绝大部分也已经都一览无余了。
不能说这样没意义,意义还是很大的(我记得 Windows 账户密码实际上也确实被用来加密凭据,包括证书私钥、浏览器登录密码之类的),但是好像没有我这个外行一开始想象得那么神奇。
2020-11-25 00:20:09 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty
首先,即便这个楼主开源了,可能还是有很多人不愿意信任他——恕我直言,(以我这个半吊子自己的感觉来看)我觉得这很大可能上并不是出于什么缜密的思考,而是出于某种(尤其是,很可能是经过刻意策划,宣传灌输进去的)偏见。至于受这种偏见影响会不会有害,这个其实是另外一回事(很多广告打得响的东西,说不定其实质量真不差)。这就是我为啥要提政治……我觉得几乎没人能在这方面完全免俗吧。

还有,说到开源,其实有个小细节:可重现编译( deterministic build ),这个貌似也就比特币一直在用。如果我没理解错,这个过程是:一样的代码,用同样的软件环境,经过同样过程,编译出一个字节不差的二进制代码,由此证明代码和二进制是对应的。
但是,因为有 Ken Thompson Hack 的存在,再有就是“即便开源、而且源码真的忠实地编译成了二进制,也未必能从代码中找到逻辑 bug”这个问题,好像这个概念本身还是有点鸡肋的。


后面给密码增加熵,我感觉你说的貌似是加盐?怪我表达不当。既然密码管理器就是个人用途,那我觉得好像不涉及撞库之类的问题。我只是觉得,KDF 这个概念本身应该也是可以“驱魅”的。
(我第一次看到 Argon2,是好奇折腾 Ubuntu 的 dm-crypt 、想搞全盘加密的时候。稍微搜了一下,好像设计确实考虑周全,加入了针对侧信道攻击和 GPU 破解的对策,对于后者,我感觉这可能和加密货币抗 ASIC 挖矿算法有点类似?然后说实话,我不知道这类设计到底有多有效,毕竟不少抗 ASIC 的 PoW puzzle 最后还是出现 ASIC 矿机了,效律比 SHA256 的情况差很多,但是仍然是碾压程度的高效)
2020-11-24 22:37:53 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@wevsty 关于 KDF,我有个理解,不知道是否正确:
实际上,密码只要稍微增加几个(可靠随机的)字符(也就是熵值增加),就可以起到和 KDF 类似的效果。
(也许现在的 KDF 不仅增加计算成本,还增加了内存消耗?这样情况又略有不同了)
换言之,KDF 只是一种缓解问题的手段,“成千上万倍”听起来很厉害,实际上未必有那么神奇。
2020-11-24 22:31:50 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
@chenshaoju
"微信小程序没办法在开发工具里方便的查看"
我没有开发过、也没有逆向过微信小程序。
不过就“跳一跳”这个小游戏来讲,我搜索过,看上去逆向并不是不可能,无非就是成本问题。而且反过来讲,就算代码是开源的,也很难说就一定没有暗藏陷阱吧。

还有,其实我本来就不想比较什么国内国外的问题(这貌似还触犯 V 站的忌讳了?也可以理解,毕竟这种事情吵起来没有止境),也不想给国内辩护。
怎么说呢,我也说声对不起吧,让楼主的帖子歪楼了,啰嗦那么多都是纯牢骚……
2020-11-24 21:50:48 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
在信息安全方面,我作为一个用户,一直都感到很无力。就好像“暗云”引导区木马,“引导区木马”这个词听起来像是上个世纪的事情,毕竟现在新出厂的电脑默认都是 UEFI+SecureBoot 了,但是实际上这个东西并没有绝迹,各种“格式化重装还是蓝屏”(估计是只格式化了 C 盘,没重写 MBR 里的引导代码)还是经常出现。

上网,不知道是不是哪里有 XSS 漏洞,不知道是不是点了什么东西账号就会莫名其妙被劫持走,然后发个菠菜广告都是轻的,鬼知道里面的信息被轮了几次。

即便是关掉浏览器,也不知道系统里有没有什么奇怪的 dll,或者其他形式的木马偷偷潜伏在内存里。也许定期重装系统是个好主意,但是到目前为止我还是得过且过,懒得折腾。
2020-11-24 21:43:14 +08:00
回复了 v2lhr 创建的主题 分享创造 为了媳妇,我不得不重构了我的小程序。
挖个坟……其实我有点心疼楼主。在安全 /技术问题上我是个糊涂虫,不过有些话我还是不吐不快。

首先就是开源与信任,虽然我是外行,但是,这方面有篇文章对我影响比较大(里面实际上转述了 Bruce Schneier 的观点),作者是江宏,标题是:
加密货币与区、块、链(三):什么是信任
不知道楼上朋友的看法,比如 @wevsty

其次,人是天生的政治动物,很多人考虑问题都不自觉地会带入政治思维(或者说 tribalism ),非我族裔其心必异(或者反之)。这一点上我也是个小白,所以不胡乱展开了,我提这个只是一种模糊的感觉。

不过最后很遗憾,我也还是不太欣赏楼主的作品。
虽然我也用微信,对微信的信任程度也很高,但是我的手机比较老旧,微信实际上也相对不常用,加载速度让我感觉很慢。

@chenshaoju
"国内隐私和数据保护做的确不好,先不说各种黑产,个人数据到处卖也不是什么少见的事情,这都 2020 年了,各种垃圾短信你也没少见吧?"
依我看,你说的这些问题,相比上文讨论的数据安全(保密)问题,范围一下子拓宽了太多。“各种黑产”“个人数据到处卖”“各种垃圾短信”这种事情,我不太了解国外是什么情况,但是,有证据表明国内就一定比国外差很多么?
其实我印象里,一提到国外的信息安全事故,我就想起信用卡信息泄露。比如 metzdowd 密码学邮件列表( bit coin 最初就是在这里发布的)的管理员就吐槽过,信用卡是世界上绝无仅有的,账号和密码是同一个字符串的系统。
连 Google 开发的 Chrome 都把 HTTPS 的描述改成了“您的信用卡信息不会外泄”——我不知道专业人士怎么看,但以我这个半吊子的眼光来看,我只能哑然失笑……
虽然在三五行字里描述实现了公钥密码的 HTTPS 能提供什么好处确实有点难,这很显然是想要让文字变得“通俗”,但是,这牺牲掉了信息的准确性。
即便是用了 HTTPS,在服务器和用户两端,都仍然是可能发生信用卡信息外泄的,比如系统被黑、被植入木马,这个木马甚至只可能是一个不起眼的恶意浏览器插件。而且据我所知 HTTPS 有些时候也并不是从头到尾都完全保密,很多时候为了让 CDN 能够工作,CDN 服务器实质上是进行了“中间人攻击”,完全知晓通信内容的明文。
2020-11-24 16:58:38 +08:00
回复了 qiushui777 创建的主题 Bitcoin 如何安全出售加密货币
有些平台是 KYC 实名验证的,就像币信、比特派什么的,但是他们也只是宣称自己“冻卡率低”,实际咋样就不知道了。
180.163.151.33 这个 IP 地址好像已经是国内的了。
2020-11-08 01:32:53 +08:00
回复了 xixixx 创建的主题 Android Android 如何录制双向通话
LineageOS 中国 SIM 卡也能录。
2020-11-06 18:54:15 +08:00
回复了 chenpingan 创建的主题 Bitcoin BTC 现在适合入场吗
@chenpingan 而且我觉得冷钱包虽然表面上的关键之处是离线,实质上离线还不是最重要最根本的,最根本的是要保持软件(甚至硬件)干净可信。如果钱包软件有后门,那即便是“冷”了一样有 N 种方法能黑掉币,甚至连数字签名都可以拿来夹带泄露信息。
(这其实也算是区·块·链这个概念被批评的一大要点,说到底就是人的问题技术其实解决不了,哎)
2020-11-06 18:50:45 +08:00
回复了 chenpingan 创建的主题 Bitcoin BTC 现在适合入场吗
@chenpingan HD 钱包存在一个固有的弱点,就是泄露单个私钥+泄露主公钥( xpub/ypub/zpub 之类的)=泄露对应的主私钥=泄露这个主公 /私钥下面的所有子私钥。所以用了 HD 钱包最好就别把单个私钥倒来倒去了,老老实实记住助记词就可以了。(而且如果你不搞冷热分离,直接用热钱包,那这个弱点对你来说等于不存在,因为私钥也在联网的机器上,可以直接拿到)
想要规避这个风险,符合 BIP39 (尤其是 BIP44/49/84 )规范的钱包一般提供“账户”(这个“账户”指的是走不同 HD 派生路径推导的不同组别的地址,不是“账户余额”那个“账户”),不同“账户”之间是互相隔离的,所以即便其中一个发生这种泄露了,也不影响另一个。但是很遗憾,Electrum 开发者貌似对这个概念不太感冒。所以,有个最简单粗暴的办法:创建新钱包,不同助记词之间很显然是互相隔离的。
2020-11-06 18:41:42 +08:00
回复了 chenpingan 创建的主题 Bitcoin BTC 现在适合入场吗
@chenpingan Electrum 当然有私钥了……你创建一个标准钱包,右键点地址,菜单里面不就有获取私钥的选项。这些私钥都是从 HD 种子(助记词)派生出来的,知道 HD 种子(助记词)就等于知道了这些私钥。

newbiewallet.ga 这个我没听说过。
1 ... 30  31  32  33  34  35  36  37  38  39 ... 110  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2564 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 00:29 · PVG 08:29 · LAX 17:29 · JFK 20:29
Developed with CodeLauncher
♥ Do have faith in what you're doing.