我读过关于使用MySQL AES_ENCRYPT/AES_DECRYPT（双向加密）比使用PHP不太安全 - 哈希（）（单向加密）。PHP和MySQL的安全性：单向加密Vs的双向加密
http://bytes.com/topic/php/answers/831748-how-use-aes_encrypt-aes_decrypt
这是真的，它是更安全的是“而不是发送用户他的密码，只要送他一个链接，他可以点击重置了密码，而不是”？最重要的是，如果我使用MySQL AES_ENCRYPT/AES_DECRYPT（我非常喜欢...），我该如何定义可以被MySQL接受的密钥？例如，关键的长度是重要的？或者我可以简单地使用'123123 @ 123123'作为我的钥匙？
谢谢！
有两个概念，散列和加密之间的根本区别：
加密可以逆转，散列不能（至少是这样的想法）。
如果恶意用户获得访问密码在数据库中，并且知道你习惯了加密密钥，他们将能够收回说密码。如果他们被哈希，他们将无法做到这一点。
这就是为什么密码应该总是被哈希（和盐渍），从来没有加密。
举例来说，是关键重要的长度是多少？或者我可以简单地使用'123123 @ 123123'作为我的钥匙？
AFAIK MySQL的AES_ENCRYPT可以采取任意长度的密钥;但很明显，短键将使它更容易被黑客猜解它（即：尝试所有可能的组合）
如果您正在使用对称加密您的服务器上存储密码，你必须解码存储的密码来测试它反对用户提交的密码。这意味着密钥也必须存储在服务器上。这意味着任何侵害你的Web应用程序的人都可以检索并解密每个用户的密码。 （并使用它们来危害用户使用相同密码的其他帐户。）
散列密码意味着您不能将密码泄露给攻击者，因为您甚至不知道自己是什么。您仍然可以通过使用相同的算法和salt对提交的密码进行哈希处理来检查提交的密码是否与原始密码相同，因此您仍然可以知道提交的密码是对还是错，而无需知道密码是什么。
使用散列密码并不代表你不能告诉他们密码是在“恢复密码”选项时，用户。但是，你真的不想那么做，特别是在电子邮件这种不安全的机制上。一次性，时间限制的重置密码链接服务于相同的目的，并且潜在的损害较小。
对于密码，单向散列几乎总是要走的路。单向哈希意味着除用户之外的任何人都能够知道他们的密码的可能性要小得多。
如果你选择了单向路线，那么你就需要设置一个密码重置的方法。如果这样做是正确的，那么对于大多数目的应该是相当安全的。为了获得更好的安全性，您可以添加安全问题（如，“你最喜欢的颜色是什么？”），用户在收到电子邮件中的密码重置链接之前必须回答。
至于AES_ENCRYPT/DECRYPT的键 - MySQL将接受函数参数key的可变长度，但不管如何，它将使用128位密钥，所以您最好传递至少128位的值。
双向加密本质上不太安全，因为真正的数据存储在某个地方。也就是说，你有一个密码“你好”。然后你哈希它，你会得到5d41402abc4b2a76b9719d911017c592。这对普通人来说是没有意义的，他们不知道如何在不知道正确的加密算法的情况下解密它。他们不能使用这个，因为只使用原始密码。您通过散列并将其与哈希（也存储）进行比较来检查密码。 5d41402abc4b2a76b9719d911017c592哈希是69a329523ce1ec88bf63061863d9cb14，所以它们不匹配。即使用户知道哈希密码，他也无法从中获取任何信息。
因此，您可以存储加密的数据，但是如果您在解压时解密，那么任何人都可以使用它。
与给他们输入密码相比，发送用户链接的安全性是一个不同的问题。如果您通过电子邮件发送密码，它将以纯文本形式打印出来供所有人查看（并使用）。给他们一个链接，允许他们输入一个新的密码意味着没有人会看到这是一个更安全一点，但如果有人犯下欺诈可以访问该链接无论如何这将导致问题。
关于AES，我一眼就找不到太多内容，但看起来无所谓加密。所以如果你使用AES_DECRYPT（AES_ENCRYPT（'x'，'b'），'b'）;它会返回'x'。你必须跟踪关键。
单向加密意味着你只能加密。 （例如，您需要对密码进行加密并存储结果，每当用户进行身份验证时，都会对用户输入和比较的内容进行加密，在这种情况下不需要解密功能）。加密方式，既有加密和解密功能。在PHP中，这是通过mcrypt_encrypt()和mcrypt_decrypt()函数完成的。
感谢您的回答，什么是128位...？ – laukok 2010-10-09 16:15:23