blocks|key|2827989|text|是的，因为您的数据库仍然在那里，用户系统及其数据库在没有注册表的情况下不会比使用注册表更难破解。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2827990|即使你很好地保护了你的“数据库数据输入门”，你的数据库仍然不是100%25防攻击的。如果有人仍然设法通过你的防御，看到了你数据库中的一切，并且所有的密码都是纯文本的，那么你的用户的帐户仍然是被攻破的。通过散列它们，至少你花费了攻击者更多的时间，同时保护你的用户的和。|offset|length|style|BOLD|2827991|entityMap^0|0|3L|1|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Yes, because your database is still there and a user system and its database are no more difficult to compromise without a registration form than with one.

Even if you protect your "database data input gates" very well, your database still isn't 100% attacker-proof. If someone still manages to slip through your defenses and sees everything in your database, and all the passwords are in plain text, your users' accounts are still compromised. By hashing them at least you're costing attackers more time, and at the same time protecting your users.

blocks|key|1675560|text|是的，因为，例如，有权访问数据库的人可以很容易地冒充其他用户。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675561|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Yes, because, e.g., people having access to the database can easily impersonate other users.

blocks|key|2828068|text|那么，入侵者能够冒充另一个用户会有什么后果呢？将这些后果与添加散列和加盐的难度(不是很大)进行权衡。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2828069|您可能要考虑的一个风险是，如果用户在多个站点上使用相同的密码，那么他们的安全性仅与最弱的站点一样安全。即使您自己手动分配密码(并且不允许用户选择)，它们可能会继续在其他站点中使用相同的密码。|2828070|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Well, what would be the consequence of an intruder being able to impersonate another user? Weigh those consequences against the difficulty (which isn't very great) of adding hashing and salting.

One risk which you may want to consider is that if a user has the same password on multiple sites, then their security is only as safe as the weakest site. Even if you're manually assigning the passwords yourself (and not allowing the user to choose it) they may go on to use the same password in other sites.

blocks|key|1675607|text|绝对一点儿没错。这是你必须尊重的对你的用户最重要的义务之一--非常小心地对待他们的个人数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675608|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Absolutely. It's one of the most important obligations to your users you have to honor - to treat their personal data very carefully.

blocks|key|4237221|text|是的，因为总是有危及数据库安全的风险。请记住，许多人在许多站点、即时消息等中使用相同的密码，因此您不仅要为系统中的信息冒风险。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4237222|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Yes, because there is always risk of compromising database. Remember, that many people uses the same password for many sites, IMs etc so you are making risk for not only information in your system.

blocks|key|4237272|text|人们不仅仅在你的网站上使用相同的密码。如果攻击者获得了密码，后果将不仅仅是您的站点。该用户的电子邮件、银行帐户等也可能被泄露。做一件勤奋的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4237273|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

People use their same password for more than just your site as well. If an attacker gets the passwords, there are more consequences than just your site. That user's email, bank accounts, etc may also be compromised. Do the diligent thing.

blocks|key|1675664|text|在某些司法辖区/行业中，以纯文本形式存储登录凭据可能违反数据保护法。如果你在美国做类似的事情，在一个与医疗或财务记录有丝毫关系的系统上，你得到了审计，即使没有被入侵，如果最坏的情况是你的客户和供应商拒绝与你做生意，直到你的系统通过审计，你将是幸运的。也可能会被处以高额罚款。即使您的系统不能处理敏感数据，如果它是供经常使用这些数据的人使用的，他们可能会重复使用也用于访问受监管数据的密码，这至少会让审计师非常紧张，并使他们的客户非常不愿意与您合作，即使您在技术上是合规的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675665|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In some jurisdictions/industries, storing login credentials in plain text could be a violation of data protection laws. If you're doing something like that in the US on a system that has even the slightest bit to do with medical or financial records, and you get audited, even if there's been no breach, you'll be lucky if the worst that happens is your clients and suppliers refuse to do business with you until your systems pass audit. There could be hefty fines as well. Even if your system doesn't work with sensitive data, if it's intended for use by people who routinely work with such data, the possibility that they may reuse passwords that are also used to access regulated data would at the very least make an auditor very nervous, and make their client extremely reluctant to work with you, even if you were technically in compliance.

blocks|key|2828304|text|你为什么不散列密码呢？它可以保护您、您的员工和您的用户，而且几乎不需要任何成本。用户有权期望您的系统管理员/DBA/任何人看不到他们的密码，并且您的管理员有权避免不必要地暴露这些信息。在任何内部/外部技术安全审计中，审计人员首先要做的一件事就是检查数据库中的任何密码列，并确定它们是否经过哈希处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2828305|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Why wouldn't you hash passwords? It protects you, your staff and your users and it costs almost nothing to implement. Users have a right to expect that your system administrators / DBAs / whoever cannot see their passwords and your administrators have a right not to be exposed to that information needlessly. In any internal/external technical security audit one of the first things the auditors will do is home in on any password columns in the database and determine whether they are hashed or not.

blocks|key|4237413|text|如果您为每个用户生成密码，并且不允许用户更改密码，那么您可以不对它们进行散列处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4237414|但是：|4237415|4237416|您必须向审计系统的每个人解释为什么您没有散列密码。|unordered-list-item|4237417|您必须有某种方法来证明系统管理员没有查看用户的密码，然后以用户身份登录。|4237418|许多程序员会认为您不知道自己在做什么。|4237419|如果系统在某一时刻发生更改，或者代码被复制到另一个系统，该怎么办？|4237420|<+code+>F29|4237421|我认为这就像过了一条路。|4237422|4237423|你总是两边看，即使绿灯说可以过马路。|blockquote|4237424|4237425|4237426|(更快的做法是从两方面看，然后向任何观看的孩子等解释为什么在这种情况下你不需要这样做)|4237427|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|15|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|16|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|17|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|18|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|19|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|S|3|T|5|U|7|1B|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|10|$]]

If you generate the password for each user and do not let the user change the password, then you can make a case for not hashing them.

However:

<ul>
<li>You will have to explain to everyone that audits the system why you are not hashing the passwords.</li>
<li>You will have to have some way of proving that a system admin did not look at a user’s password then logon as the user.</li>
<li>A lot of programmers will think you don’t know what you are doing.</li>
<li>What if the system is changed at some point, or the code gets copied into another system.</li>
</ul>

I think of this like crossing a road.

<blockquote>
 You always look both ways even if the
 green man says it is OK to cross.
</blockquote>

(It is quicker to look both ways, then explain to any watching children etc why you don’t need to in this case)

blocks|key|2828400|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2828401|我也很好的保护了数据库，数据输入门。|blockquote|2828402|2828403|2828404|我敢打赌，在计算史上，每一个被攻破的密码文件的每一个系统设计师/管理员都有同样的想法。|2828405|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|J|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|K|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|M|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|N|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|O|7|@]|8|@]|9|$]]]|I|$]]

<blockquote>
 Also i protected the databases data input gates very well.
</blockquote>

I bet every system designer/administrator for every compromised password file in the history of computing thought the same thing.

I am building a project, which has a pretty basic login system. There will NO REGISTRATION system available, the users will be added manually. Also i protected the databases data input gates very well. So after all, do i still need to hash and even salt the users passwords?

And if your answer is yes, the next question is why?

Do i really need to hash passwords?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在建设一个项目，其中有一个非常基本的登录系统。将没有可用的注册系统，用户将手动添加。另外，我很好地保护了数据库、数据输入门。那么，我是否仍然需要对用户的密码进行散列甚至加盐呢？如果你的答案是肯定的，那么下一个问题就是为什么？

问我真的需要散列密码吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我真的需要散列密码吗？EN