我看到您的方法存在各种问题（没有特别的顺序，很可能不是完整的列表）：

• 看起来您正在部署没有 SSL/TLS 的应用程序。如果是这种情况，您不能依赖客户端，因为 MITM 可以用他/她选择的任何东西替换您的（安全）客户端实现。

  没有 SSL 就无法创建安全的 Web 应用程序，因为客户端会通过不安全的通道加载您的应用程序。如果您的应用程序是通过安全通道部署的（不确定是否angularjs支持离线部署），请忽略它。

  如果您使用 SSL，这可能会减轻所有其他攻击场景，因为它可以防止 MITM 和重放攻击。唯一可能成为问题的是身份验证，因为您不使用客户端证书。但是通常会话令牌对于 Web 应用程序来说就足够了，因为服务器已经过正确的身份验证（假设您使用了正确的实现）。

• 您希望防止重放攻击，但仅对请求使用时间戳。如果攻击者能够足够快地记录和回复请求，服务器将认为该请求有效。根据您的实际数据，这可能是也可能不是问题。

  为了防止这种攻击，请添加一个请求计数器或将最后一个请求的时间戳存储在服务器上（并且需要比存储的时间戳更大的时间戳）。

• 除了您的实际 HMAC 之外，您并没有对您的密码进行加盐，这样具有数据库访问权限的攻击者对您的应用程序和您的用户密码来说是致命的。我强烈建议您添加密码。

  此外，通常的做法是多次散列密码以增加针对散列的字典攻击所需的工作量。

• 从你写的内容来看，你并不清楚你是否将消息/请求内容包含到你的 HMAC 中。但我假设您知道 HMAC 仅验证生成它的数据的完整性这一事实。

• 您不会对 HMAC 使用真正的随机密钥。鉴于当今的计算能力，弱密码很可能会导致可破解的 HMAC，因为可能的哈希值很容易计算。散列多轮可能会有所帮助（如果攻击针对多个用户，则加盐），但最后安装一些暴力预防至关重要（每小时的最大非法请求数或类似数量，然后阻止源 IP）。

  但是，我个人永远不会仅根据用户密码信任任何东西。

因此，就个人而言，我建议不要使用自己的加密货币并坚持使用 SSL/TLS。虽然这基本上意味着每个受客户信任的 CA 都可以认证 MITM，但我认为这种风险远低于 MITM 通过向用户提供恶意 web 应用程序、重放请求或破解 HMAC 的秘密来证明自己的风险。