blocks|key|892180|text|我认为使用像SHA-256这样的适当散列函数的加盐散列是最好的。可逆的密码不如不能反转的密码安全。如果没有外部Perl模块，您可以使用内置的SHA1()函数，它不如SHA256好，但比ENCODE/DECODE好。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|892181|此外，您还必须考虑从代码到数据库的路径，这是可以嗅探到的。您可以通过散列代码或加密数据库连接来避免这种风险。最好在代码中完成，因为即使在加密连接时，仍然存在配置查询日志从而将明文存储在某个日志文件中的风险。|892182|entityMap|0|LINK|mutability|MUTABLE|url|http://search.cpan.org/~dido/SHA256-0.01b/SHA256.pod^0|6|7|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I think a salted hash with a proper hash function like <a href="http://search.cpan.org/~dido/SHA256-0.01b/SHA256.pod" rel="nofollow noreferrer">SHA-256</a> is the best. Passwords that are reversible are not as safe as those who cannot be reversed. Without an external Perl module, you can use instead the built in SHA1() function, not as good as SHA256, but better than ENCODE/DECODE.

Additionally, you have to consider the path from your code to the database, which can be sniffed. You can avoid that risk by hashing in the code or by encrypting the database connection. Better to do it in code, because even when encrypting the connection there is still the risk about query logs being configured thus storing plaintext on a log file somewhere.

blocks|key|58043|text|通常，我更喜欢将密码保存为无法恢复的散列，而不是可以解密的加密项。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|58044|通过从访问者提供的字符串(当然还有一些盐)计算哈希，我可以判断用户是否提供了两次相同的密码，而不存在允许我的应用程序解密提供的密码的安全风险，这可能是恶意的。|58045|我的感觉是，当您希望数据可恢复时，encode()和decode()可能是很好的解决方案，但是对于存储的密码，不可恢复的散列(使用Crypt::MD5)是更好的方法。|58046|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Generally, I prefer to keep passwords as hashes that can't be recovered, rather than as encrypted items that can be decrypted.

By computing a hash from a visitor-supplied string(plus some salt, of course), I can tell whether the user provided the same password twice, without the security risk of allowing my application to be able to decrypt the provided password, possibly maliciously.

My sense is that encode() and decode() are probably good solutions when you want the data to be recoverable, but that unrecoverable hashes (using Crypt::MD5) is a better approach for stored passwords.

blocks|key|57977|text|如果您只需要密码来验证自己/用户，则单向存储(如md5)更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|57978|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|$]]

If you only need the password to authenticate yourself/the user, a one way storing (like md5) is better.

blocks|key|3279086|text|好吧，由于有一个DECODE()函数，我认为不是，因为您可能希望以散列形式存储密码，以防止任何获取您的数据库/密码文件的人随意读取密码。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3279087|我推荐使用经典的加盐哈希方法。|3279088|entityMap^0|8|8|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

Well, since there's a <code>DECODE()</code> function, I'd say no, for the simple fact that you probably want to store the password in hashed form, to prevent anyone obtaining your database/password file from casually reading passwords.

I'd recommend going with the classic salted hash method.

blocks|key|892203|text|一些应用程序要求用户的密码是可检索的，而在系统中，如果忘记了用户的密码，用户的密码会被随机重置为某个值(因为无法解密，因为您使用的是散列)。在这种情况下，编码和解码都可以，但是为什么不使用内置的AES_ENCRYPT和AES_DECRYPT函数呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|892204|此外，无论是散列还是加密，都建议使用Salt值。这在两种情况下都是有益的。|892205|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|$]]

Some applications require the user's password to be retrievable, as opposed to a system where the user's password is randomly reset to something, if forgotten (because it cannot be decrypted, because you're using a hash). In this case, encode and decode are OK, but why not use the built-in AES_ENCRYPT and AES_DECRYPT functions instead? 

Also, keep with the suggestion of using a salt value, whether you hash or encrypt. It's beneficial in both scenarios.

blocks|key|4124332|text|我不确定这些函数是做什么的，但对于LAMP堆栈网站中的密码，我肯定也会使用salt字段。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4124333|您的用户表将包含：|4124334|4124335|name|unordered-list-item|4124336|pass|4124337|salt|4124338|4124339|然后，在明文密码和salt的连接上使用某个编码函数对明文密码进行编码。此结果将进入pass字段。盐也被储存起来了。这样，您就可以在用户登录时验证明文密码。盐可以是任何东西，长度越长，随机程度越高越好，但我不认为它是那么敏感。|4124340|这极大地提高了安全性，因为现在您的用户不再使用5个字母的密码，他们使用5%2Blen(+salt+)大小的密码，并且如果salt足够大，任何彩虹数据库都不会包含您的散列。|4124341|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|X|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

I'm not sure what these functions do, but for passwords in a LAMP stack website, I'd definitely use a salt field as well.

Your user table would have:

<ul>
<li>name</li>
<li>pass</li>
<li>salt</li>
</ul>

The plain text password is then encoded using some encode function on a concatenation on the plain text password and the salt. This result goes into the pass field. The salt is stored as well. That way you can verify plaintext passwords when the user logs in. The salt can be anything, the longer and more random the better, but I don't think it's that sensitive.

This improves security vastly, because now your users don't use 5 letter passwords anymore, they use 5+len(salt) size passwords, and if the salt is big enough, no rainbow database will ever contain your hashes.

blocks|key|892222|text|如果你能解密一个密码，你的安全是有缺陷的。你应该总是用盐来散列密码，MD5很流行，但也有更好的散列方法，比如SHA和SHA-256。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|892223|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|$]]

If you can decrypt a password, your security is flawed. You should always hash the password with a salt, MD5 is popular but there are superior hashing such as SHA and SHA-256.

I am developing on a LAMP(erl) stack and know of several ways to store obscured passwords. I'd like to hear from those who feel they have a best practice, given MySQL 4.1.1 and Perl 5.8, and the reasons why it's the best.

One option I have read about, using the MySQL ENCODE() and DECODE() functions, sounds pretty good to me... your thoughts?

Is ENCODE() and DECODE() the "best" way to handle an application password field in MySQL?

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

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

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

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

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

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

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正在一个LAMP(erl)堆栈上开发，并且知道几种存储模糊密码的方法。我想听听那些认为自己有最佳实践的人的意见，比如MySQL 4.1.1和Perl5.8，以及为什么它是最佳实践的原因。我读到过一种选择，使用MySQL ENCODE()和DECODE()函数，听起来很不错……你的想法是什么？

问ENCODE()和DECODE()是处理MySQL中应用程序密码字段的“最佳”方法吗？
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ENCODE()和DECODE()是处理MySQL中应用程序密码字段的“最佳”方法吗？EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ENCODE()和DECODE()是处理MySQL中应用程序密码字段的“最佳”方法吗？
EN