问题描述
我当前正在使用，
base64_encode()来编码用户密码，这很好，因为它允许我简单地使用 base64decode()来将密码解码为一个单词，然后将密码发送给该电子邮件在那里丢失密码.
I currently use,
base64_encode() to encode a user's password, this works well because it allows me to simply use base64decode() to decode the password to a word and send to there email if they lose there password.
尽管我一直在阅读密码，但很多人似乎都说您应该使用 sha1()来对密码进行编码.我全心全意提高系统的安全性，但是如果我转换为使用 shal()，那么我将无法向该用户发送丢失的密码.
I have been reading up on password though and a lot of people seem to say that you should use sha1() to encode a password. I am all for improving my system's security but if I convert to use shal() then I will not be able to send a user there lost password.
您使用什么?你能给我一些建议吗?有没有办法将密码转换为可读的密码来向用户发送电子邮件?
What do YOU use? Can you give me some advice? And is there a way to decod to a readable password to email a user?
当我键入此问题时，我只是想提醒一些论坛，当被请求时不会向您发送密码，而是发送一个特殊的链接来重置您的密码，我猜这是因为它们无法解码您的密码， ?
As I typed this question I just remebered that some forums do not send you a password when requested but instead send a special link to re-set your password, I am guessing that this is because they are unable to decode your password maybe?
//what I use now
$password_encoded = base64_encode($password);
//what I am considering using
$password_encoded = sha1($password);
推荐答案
请，为了您的用户，请勿以 any 可逆格式存储密码！不管是Base64编码还是三重DES 168位加密-如果它是可逆的，则与您完全不对其进行编码一样安全.
Please, please for the sake of your users do not store their passwords in any reversible format! It doesn't matter if it's Base64 encoded or triple-DES 168-bit encryption - if it is reversible, it is exactly as secure as if you didn't encode it at all.
No 网站将通过电子邮件向用户发送密码.我们唯一能做到与远程安全接近的事情就是向用户发送一封电子邮件，该电子邮件具有唯一的一次性使用链接，使他们可以设置新密码.
No website that has any interest in protecting itself or its users (or has a lick of sense) will send a user their password via e-mail. The only thing we can do that's even remotely close to secure is to send users an email with a unique, one-time-use link that lets them set a new password.
- Store a hash (bcrypt or PBKDF2) of the password which has been salted
- Throw away the original password as soon as you've hashed it. Excise it from memory.
- Always require the user to create their own new password over an SSL channel
说实话，尝试与其他人相处只是疏忽大意.让我们使用在安全性讨论中使用的非常常见的方案:
Trying to get by with anything else is honestly just negligence. Let's use a very common scenario used in security discussions:
用户Frederic的电子邮件已被盗用.这可能是因为他的计算机处于未锁定状态或使用了弱密码.无论如何，未经授权的人都可以访问他的消息.理想情况下，这仅意味着陌生人阅读的一些令人尴尬的情书.不幸的是，未经授权的人发现论坛将通过电子邮件以纯文本形式发送Frederic的密码.像大多数用户一样，弗雷德里克(Frederic)对包括他的网上银行在内的所有东西都使用相同的密码.他的用户名列在他的银行的电子邮件中.现在情况非常不幸.
User Frederic's email is compromised. This could be from leaving his computer unlocked or using a weak password. Regardless, an unauthorized person has access to his messages. Ideally, this would mean nothing more than some embarrassing love letters read by a stranger. Unfortunately, the unauthorized person discovers a forum will email Frederic's password in plain-text. Like most users, Frederic uses the same password for everything, including his online banking. His username is listed in an email from his bank. Now the situation is very unfortunate.
用户与您建立基于凭据的关系时，他们就会信任您.这种信任的部分原因是，您会将这些凭据作为您和他们之间的安全秘密保存.
Users are placing trust in you when they create a credentials-based relationship with you. Part of that trust is that you will keep those credentials as a secure secret between you and them.
许多周围的问题和想法在SO上都得到了很好的回答:
A lot of the surrounding issues and ideas have been answered very well on SO:
- Difference between Hashing a Password and Encrypting it
- Why is challenge-response approach a poor solution for forgotten passwords?
- Non-random salt for password hashes
这篇关于用PHP编码密码的最佳方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！