codehz

codehz

V2EX 第 187268 号会员,加入于 2016-08-16 18:42:57 +08:00
今日活跃度排名 9756
Java 、Idea、Android Studio 用户请暂缓升级到 macOS 14.4
  •  4   
    Apple  •  codehz  •  3 小时 49 分钟前  •  最后回复来自 codehz
    109
    Log4J 远程代码执行漏洞
    信息安全  •  codehz  •  2021-12-10 01:36:54 AM  •  最后回复来自 Jooooooooo
    1
    Windows 11 小组件完全魔改指南(insider 版)
  •  5   
    Windows  •  codehz  •  2021-10-05 20:29:46 PM  •  最后回复来自 huhuime
    7
    Chrome 在 Web Worker 里渲染文本可导致网页崩溃(win10 专属)
    Chrome  •  codehz  •  2021-05-11 09:51:50 AM  •  最后回复来自 gam2046
    1
    WSL 2 原生图形支持来了(内部测试版)
  •  2   
    分享发现  •  codehz  •  2021-04-08 09:32:42 AM  •  最后回复来自 clevercoolbear
    32
    yori,一个提升 windows 命令行使用体验的 shell(cmd 替代)
    Windows  •  codehz  •  2020-11-29 01:05:30 AM  •  最后回复来自 Kasumi20
    15
    一个新的玩具,在 js 里套娃 c 编译器
    分享创造  •  codehz  •  2021-01-24 18:31:32 PM  •  最后回复来自 codehz
    9
    2020 年,网页终端渲染器比较: hterm vs xterm.js
  •  1   
    前端开发  •  codehz  •  2020-02-04 22:55:51 PM
    codehz 最近回复了
    3 小时 49 分钟前
    回复了 codehz 创建的主题 Apple Java 、Idea、Android Studio 用户请暂缓升级到 macOS 14.4
    @StruggleYang 经过测试,14.4.1 已经修复了这个错误,不是给 java 开后门,整个错误都修了
    实践中,编译器会给你生成一个 double checking lock
    啥,4k 你用 100%来看,和 1080p 用 100%不是一样的效果的吗。。。
    nomodule 的兼容性是指:支持 nomodule 的浏览器就不去加载这个 script
    不支持 nomodule 的就会自动加载(因为不认识的 attribute 被忽略)
    要讨论这个问题,得先设定一个威胁模型吧,不如就来一个直接拉满的模型:
    攻击者方面
    1. 攻击者完全了解该协议。
    2. 攻击者可以访问大量常用密码字典(并且有足够多的时间离线破解)。
    3. 攻击者可以窃听客户端和服务器之间的所有通信。
    4. 攻击者可以拦截、修改和伪造客户端和服务器之间的任意消息。
    5. 没有相互信任的第三方。
    最后攻击者的目标是冒充客户认证,这里不考虑“在线”暴力破解的情况,也不考虑注册过程中客户被冒充的情形。

    这个模型下,所有基于固定密码的 web 认证方案都是无效的,因为攻击者只需要伪造登录页面就可以直接偷到正确密码。( WebAuthn 是终极解决方案)
    那我们可以弱化其中一个攻击条件,假设 webapp 已经事先作为 pwa 部署到用户设备上了,因此攻击者无法篡改登录页面(*),这种情况下,可以继续讨论前端加密的意义。

    1. 首先排除单纯的摘要算法,因为只要把摘要本身认定为登录密码即可冒充用户
    2. 我们可以考虑单纯的预先共享密钥的方案,也就是对称加密,这条基本上也可以 pass ,因为攻击者也能拿到预共享密钥(什么,你说一次一密?那攻击者伪造一个假的给客户端不就可以了)
    3. 至于非对称加密的方案,尽管这次攻击者拿不到服务端私钥,没办法直接偷到密码,但是由于第二条,攻击者可以离线破解密码
    。。。剩下的方案,基本也就是排列组合,在上面那个威胁模型下能起到的作用顶多是减缓攻击者的破解速度

    那有没有完美的算法解决这个问题呢?答案是有的,只要从一开始,就不发送任何关于密码的信息给服务器即可
    通过零知识证明,客户端和服务端分别向对方证明自己拥有密码,但服务端却无需得到密码的原文(或者任何衍生信息)
    将零知识证明用到认证领域的协议就是(非对称的) PAKE ,一个常见的具体协议是 OPAQUE 协议。协议内容在这里不细说,可以在 https://blog.cloudflare.com/opaque-oblivious-passwords 里看到细节,但在理论上它是能抵御前面所提到的所有威胁的。
    9 天前
    回复了 YugenFring 创建的主题 程序员 kotlin 可以完美平替 Java 吗?
    不是完美平替,企业的例子我不知道,mc 模组里,fabric 的模组,无法在 mixin 中使用 kotlin (原因是 kotlin 的标准库会有冲突)
    @houshuu 但其实没什么用,这次的问题是随机概率触发的,上面有人就没触发过。。。
    合理的方案是在不破坏互操作性的前提下(例如不能出现旧版本无法打开项目的情况),进行灰度升级
    全屏实现其实挺复杂的(因为跳过了窗口混合的过程),对老游戏可能可以 dxhook 一下,但虚拟机的估计没那么好做。。
    除非 vmware 用的是无缝窗口模式,那种也许可以骗过去。。。
    @daveh
    这个修改也只是另一个性能优化 https://bugs.openjdk.org/browse/JDK-8283326

    SafeFetch is important - mostly when writing hs-err reports, but it is also used in low level utility functions like `os::print_hex_dump()` and `os::is_readable_pointer()`. It is also used (JDK-8282306) as part of call stack printing. At the moment it is implemented via dynamically generated stub routines
    @daveh 没错是改成 static 了,但还是用信号的啊 https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_static_posix.cpp
    只不过把 safefetch 本身的代码用汇编写成直接一个 mov 或者 ldr
    https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S
    不是很懂为啥要杠这一点
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5385 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 06:53 · PVG 14:53 · LAX 23:53 · JFK 02:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.