一次性密码算法(基于数学、基于时间和基于操作)

发布于 2024-12-21 23:54:08 字数 785 浏览 1 评论 0原文

我正在尝试开发一个网站和相应的帮助程序(安装在用户计算机上)。网站和程序会互相通信(主要是AJAX),但如果有其他网页可以向程序发送请求,将会带来很大的安全风险。我想提出一个解决方案,使向我的程序(安装在用户计算机上)注入欺诈请求变得极其困难。我的想法是使用一次性密码,但我的安全知识有限,因此询问您的想法。

我想出了这个一次性密码算法(伪):

function otp(seed, counter, unix_timestamp, action)
{
    for(i = 0; i < counter; ++i)
    {
        seed = sha256(seed + i);
    }
    str = seed;

    str = sha256(str + unix_timestamp/60);
    str = sha256(str + action);
    otp = substr(str,0,4); //Convert the first for bytes to an int.
    return (int)otp;
}

它应该具有以下属性:

  • 只能使用一次,(在每个 otp 生成上,“计数器”都会增加 => 新种子)
  • 将被更改分钟(取决于时间)。
  • 绑定到一个动作(登录,...),它依赖于一个特定的动作。
  • 可以轻松地单独生成并稍后同步。

如果每个请求都包含 OTP 代码和计数器值,这安全吗?如果不是,您有什么建议来实现这一目标?我真的想要上面提到的所有这些属性。

提前致谢。

I am trying to develop a website and a corresponding helper program (installed on the user computer). The website and the program will communicate with each other (AJAX mostly), but it will be a large security risk if any other web page can send requests to the program. I want to come up with a solution which makes it extremely hard to inject fraud requests to my program (installed on the user computer). My thoughts are about to use one time passwords, but I have limited security knowledge and therefore ask you for your thoughts.

I have came up with this One-Time-Password algorithm (pseudo):

function otp(seed, counter, unix_timestamp, action)
{
    for(i = 0; i < counter; ++i)
    {
        seed = sha256(seed + i);
    }
    str = seed;

    str = sha256(str + unix_timestamp/60);
    str = sha256(str + action);
    otp = substr(str,0,4); //Convert the first for bytes to an int.
    return (int)otp;
}

It should have the following properties:

  • Can only be used once, (On every otp generation will "counter" be increased => new seed)
  • Will be changed every minute (It depends on time).
  • Bound to an action (login, ...), it depends on a specific action.
  • Can easily be generated separately and later be synchronized.

If every request contains OTP code and counter value, is this secure? If not what are your tips to accomplish this? I really want all those properties I mentioned above.

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

浅忆 2024-12-28 23:54:08

你的做法原则上是明智的。但请记住,多次调用哈希函数是没有意义的 - 要么在第一次通过时是安全的,要么根本不安全。
此外,您现在仅使用种子来实际验证请求(潜在的攻击者会知道其他任何内容),并且种子生成中的任何弱点都会成为身份验证中的弱点。

我不知道SHA256的具体缺点。但是,您的问题通常相当常见,并且更容易用标准术语描述和解决。您想要验证对程序的请求。您的远程程序需要安全地确定请求的真实性。这个问题最容易通过公钥加密来解决。例如,制作一个 GnuPG 密钥对,将私钥保存在您的网站上,并使用您的程序分发公钥,并对任何命令进行签名您使用私钥发送到程序。客户端程序正常接收请求,只需要通过一次调用 GnuPG 来验证其真实性。

Your approach is sensible in principle. Keep in mind, however, that multiple calls to your hash function are pointless - either it's secure on the first pass, or it isn't at all.
Also, you are right now only using the seed to actually authenticate requests (anything else would be known to a would-be attacker), and any weakness in seed generation becomes a weakness in authentication.

I am not aware of the specific shortcomings of SHA256. However, your problem in general is fairly common and is much easier to describe and solve in standard terms. You want to authenticate a request to your program. Your remote program needs to securely determine the authenticity of a request. This problem is most easily solved with public-key cryptography. For example, make a GnuPG key pair, keep the private key at your website and distribute the public key with your program, and sign any command you send to the program with the private key. The client program receives requests normally and only needs to verify their authenticity via a single call to GnuPG.

浪漫之都 2024-12-28 23:54:08

已经存在一个标准,称为 HOTP (RFC 4226)。您应该使用它而不是重新发明轮子,因为它已经过比我们更有密码学经验的人的审查。

你还没有说出你的对手是谁;如果他们是自己机器上的用户,您应该记住,实际上不可能阻止他们破坏您想要发明的任何方案。

There already exists a standard for this, called HOTP (RFC 4226). You should use that rather than reinventing the wheel, as it's been vetted by people with more experience in cryptography than us.

You haven't stated who your adversaries are; if they are the user on their own machine, you should bear in mind that it is literally impossible to prevent them from compromising any scheme you care to invent.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文