如何为Google身份验证器生成正确显示OTP上方显示的颁发者的QR码?

Mar*_*bak 22 qr-code google-authenticator

所以,我知道这里的文档,在这里找到:Google Authenticator密钥URI格式

当我从该页面关注此示例时:

otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example
Run Code Online (Sandbox Code Playgroud)

我将它拼接成Google Charts网址,因此:

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example
Run Code Online (Sandbox Code Playgroud)

它将显示有效的QR码,如果我在手机上使用我的Google身份验证器应用程序进行扫描,它将开始生成有效的OTP.

但是,在手机的显示屏上,对于QR码创建的条目,我获得了OTP,在其下面,我得到了"示例:alice@google.com".我想要的是在OTP 上方显示"示例" ,在OTP 下方显示"alice@google.com" .我不禁注意到,所有专业制作的应用程序都是这样做的.例如,Google,Wordpress,亚马逊等.公司名称位于OTP 之上,用户名显示在OTP 下方.是的,这纯粹是一个整容问题,但我想做对.

任何人都可以给我一个线索吗?

kra*_*etz 32

从信息安全的角度来看,推荐使用 Google Charts 的回应绝对是糟糕的。这本质上是与没有法律义务保密的第三方公司共享 TOTP机密以及您的用户名 ( alice@google.com) 和发行者 ( Example),并通过GET请求执行此操作!这样做不仅违反了多因素身份验证的每一个假设,而且很可能违反了您组织的信息安全政策。它使 MFA 增加的任何价值无效,因为在密码泄露的情况下保护您免于破坏您的帐户的唯一因素本身就是被破坏的。

只需使用任何二维码生成器,只要它在本地处理您的数据即可。

切勿使用在线 QR 生成器获取 MFA 机密

在 Linux 上,我建议使用python-qrcode库,它可以在控制台上使用 UTF-8 字符打印您的二维码。

pip install qrcode
Run Code Online (Sandbox Code Playgroud)

然后:

qr "otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example
Run Code Online (Sandbox Code Playgroud)

在此处输入图片说明

  • 这篇文章启发我为此创建一个 php 库。可以在这里找到 - https://github.com/MincDev/php-otpauth.git。 (2认同)

Ale*_*lex 24

我使用本地qrencode安装使用不同的方式:

qrencode -o- -d 300 -s 10 "otpauth://totp/YOUR_IDENTIFICATION?secret=YOUR_SECRET" | display
Run Code Online (Sandbox Code Playgroud)

通过这种方式,我可以从笔记本电脑上重建丢失的身份验证密钥库.

  • 这比使用在线生成器安全得多。 (4认同)
  • 注意下面大卫托马斯的回答(这真的应该是这里的评论),包括“发行者”和 https://gist.github.com/ragusa87/f9d82ca631df0d4d32a0 这个脚本。 (2认同)

Mar*_*bak 15

刚想通了.

事实证明,我需要编码'oauth'中的所有特殊字符,即'$','%','='等.

因此,使用与以前相同的Google Charts网址,但对这些字符进行编码,如下所示:

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/Example%3Aalice%40google.com%3Fsecret%3DJBSWY3DPEHPK3PXP%26issuer%3DExample
Run Code Online (Sandbox Code Playgroud)

它工作正常.

  • 被否决是因为虽然这可能会解决问题,但这违反了通过与未知方共享您的秘密来添加额外安全层的整个要点。没有人应该这样做。 (15认同)