在应用程序中硬编码密码有什么不安全的地方？ [关闭]

Question

我需要为我的 ASP.NET MVC 应用程序的单个页面创建一个基本登录名，我正在考虑是否应该花几个小时尝试了解身份库、SALTing 密码等，或者我是否可以这样做以下。

所以我使用Password Depot 来创建一个随机密码，例如

g5\oLH*aFZn=mL5GKS@5&P%*

它说的是什么

预计破解密码时间：7.37*10^30年。

然后我会将其存储在应用程序中以提供给客户。登录将很简单

    [HttpPost] 
    public ActionResult TryLogin ( string pwsdAttempt )
    {
        if ( AdminController.CheckPassword(pwsdAttempt) )
        {
            Session["loggedIn"] = "true";
            return Json(new { correct = true });
        }
        else
        {
            return Json( new { correct = false });
        }

    }

检查pswdAttempt 与g5\oLH*aFZn=mL5GKS@5&P%*（或随机生成的密码最终是什么），这将通过 SSL。

这有什么潜在的问题吗？如果是，是什么，为什么？

Answer 1

是的，您应该花时间研究安全性。这不需要太多时间，而且有标准框架可以为您完成繁重的工作。

你写的时候是什么意思

然后我会将其存储在应用程序中以提供给客户。

?

您的方法有几个问题。

安全性真的很差

首先，您编写的任何一段文本（无论是代码、字符串，或者在您的情况下是密码）然后被编译，总是可以被逆向工程和检索。有些语言更难，有些更容易。获取一个示例 Java .class 文件并“反编译”它，您将与原始文件非常接近。

这意味着可以从应用程序中检索您的密码。不是一个好主意。不太安全。

您永远不应该以明文形式存储密码。你应该总是把它哈希和加盐。引用维基百科

盐是随机数据，用作单向的附加输入 “散列”密码或密码短语的函数。主要功能 盐是为了防御字典攻击而不是列表 密码哈希和针对预先计算的彩虹表攻击。

实际上，如果您是开发人员，那么您应该让安全专家来处理安全问题。这就是为什么首先存在安全框架的原因。依靠他们。不要重新发明轮子，尤其是安全轮子。

管理不善

这是否意味着您必须重新编译和重新部署才能更改密码？

糟糕的用户体验

另一个方面当然是用户体验。为什么要硬编码密码？您不希望您的用户选择他们自己的密码吗？当您使用它时，您不想要多个用户吗？您也不希望用户使用他们已经拥有的帐户，例如Active Directory 中有什么东西？

进一步阅读

• Salted Password Hashing - Doing it Right