小编Rya*_*yan的帖子

我有一个脚本来验证用户是否通过 grep 登录到私有 npm 注册表（通过“npm login”）：

//registry-sub-url:_authToken=

... 在：

~/.npmrc

但是，随着用户凭据过期（由于标准密码过期规则），这会随着时间的推移而失效。

更重要的是，我创建的帮助脚本无法区分成功/失败的npm login调用，因为脚本总是以0状态退出。

问：（1）我们如何验证是否npm login成功？(2) 如何识别npm token何时过期？

我觉得我完全错过了 Wildfly 中新的 JCEKS 密钥库格式的要点。也许你可以让我直截了当。

我们配置 Wildfly 的方式（以及大部分互联网指示我们，例如）：

• 我们将标准密钥库条目放入标准 Java 密钥库（“keystore.jks”）文件中，并带有密码（“jks_pw”）
• 然后，我们使用密码、salt 和轮次计数（“jceks_s_n”）创建一个 JCEKS 密钥库（“keystore.jceks”）。
• 然后我们将“pks_pw”放入“keystore.jceks”
• 然后我们将 JCEKS 密码/等（“jceks_s_n”）作为纯文本添加到我们的 jboss 配置（standalone.xml）中，定义一个条目
• 然后，我们向 jboss https 连接器 (standalone.xml) 添加对保管库存储的 JKS 密码的引用，如“password="${VAULT::jks::jks::1}”。

这一切到底完成了什么？？？

如果我们只使用 JKS 文件和嵌入在 standalone.xml 中的密码，系统很容易受到：

• 攻击者获得了 standalone.xml 和 JKS 文件的副本，在这种情况下，所有秘密都是已知的。
• 攻击者获取 JKS 文件的副本，在这种情况下，攻击者可以使用暴力破解或查找表攻击。

如果我们以描述的方式使用 JCEKS 容器，系统很容易受到：

• （相同）攻击者获得了 standalone.xml 的副本，即 JKS/JCEKS 文件，在这种情况下，所有秘密都是已知的。
• （相同）攻击者获得 JKS 文件的副本，在这种情况下，攻击者可以使用暴力破解或查找表攻击。

如果我们将实际证书放在 JCEKS 文件中，这将有点有意义，在这种情况下，在第二种攻击情况下，蛮力和查找表攻击会更难，但到目前为止我还没有找到使用方法直接使用 https 连接器的 JCEKS 格式的密钥库。

真的，我太在意这个的唯一原因是我们显然有使用“保险库”的安全要求，但这似乎毫无意义。

更新：值得注意的是，通过使用保管库，您在 jboss 配置文件中使用了保管库的“隐藏”密码，但我无法弄清楚这意味着什么。显然，您的掩码密码 + salt + rounds 可以解锁 JCEKS 密钥库（source），所以我不确定掩码到底能完成什么。这似乎是第三级重定向。我必须错过一些东西......

使用Yubico PIV工具和YubiKey PIV管理器,我可以将客户端TLS证书加载到PIV插槽中,并将其用于Firefox中的身份验证.这很棒.然而...

有没有办法阻止出口PIV的私钥？据我所知,PIV管理密钥只保护设备不被修改,但没有做任何事情来保护包含的内容不被导出.

如果这是准确的,YubiKey似乎并不像PIV 2FA设备那样,因为2因素假设"你拥有的东西",我插入设备的任何机器(或在后台运行的软件)都可以功能齐全的软拷贝.

我在Yubico论坛上交叉发布了这个问题.

以下是我演示问题的方法:

1. 通过"YubiKey PIV Manager"(my-cert.crt)导出证书
2. 通过"YubiKey PIV Manager"从YubiKey删除证书
3. 通过"YubiKey PIV Manager"导入的证书(my-cert.crt)
4. 重启Firefox(加载了OpenSC)
5. 我仍然可以通过PIV进行身份验证