在Rails中，人们会普遍使用pre-现有的库。认证是很容易做到错，问题是解决了这么多次，这是很不值得再解决它的努力。如果你有兴趣写自己的实现，那么我将介绍如何认证的现代作品。

In Rails, one would generally use a pre-existing library. Authentication is easy to do wrong, and the problem's been solved so many times that it's rarely worth the effort to solve it again. If you are interested in writing your own implementation, then I'll describe how modern authentication works.

验证用户的幼稚的方法是存储密码的数据库，并将其与用户提交的密码。这很简单，但令人难以置信的是不安全的。任何人谁可以阅读你的数据库可以查看任何人的密码。即使你把数据库访问控制，你（和你的用户）是脆弱的人谁他们周围黑客。

The naive method of authenticating a user is to store their password in a database and compare it to the password the user submits. This is simple but unbelievably insecure. Anyone who can read your database can view anyone's password. Even if you put in database access controls, you (and your users) are vulnerable to anyone who hacks around them.

适当形式是使用密码散列函数时，如果选择它，然后每次提交时间来处理密码。一个好的哈希函数几乎是不可逆的 - 你不能把一个散列并把它放回密码。因此，当用户登录时，你把密码提交，散列它，并将其与数据库中的哈希值。这样一来，你永远不存储密码本身。缺点是，如果用户忘记了密码，你必须重新设置它，而不是发送给他们。

Proper form is to use a cryptographic hash function to process the password when it is chosen and then every time it is submitted. A good hash function is practically irreversible -- you can't take a hash and turn it back into a password. So when the user logs in, you take the submitted password, hash it, and compare it to the hash in the database. This way, you never store the password itself. On the downside, if the user forgets their password, you have to reset it rather than send it to them.

即使这样，但是，很容易受到某些攻击。如果攻击者得到你的密码哈希值的保持，并且知道如何散列密码，那么他就可以做一个字典攻击：他只是需要每一个字在字典和哈希这个词，与原来的保持它。此数据结构称为彩虹表。然后，如果任何的字典字散列匹配密码散列，攻击者可以得出这样的结论密码是字典字即散列到该密码。总之，谁可以读取你的数据库中攻击者仍可以登录到弱口令帐户。

Even this, however, is vulnerable to certain attacks. If an attacker gets hold of your password hashes, and knows how you hash your passwords, then he can make a dictionary attack: he simply takes every word in the dictionary and hashes that word, keeping it with the original. This data structure is called a rainbow table. Then, if any of the dictionary word hashes match a password hash, the attacker can conclude that the password is the dictionary word that hashes to that password. In short, an attacker who can read your database can still log in to accounts with weak passwords.

的解决方案是，一个密码散列之前，它被结合（通常串连或XOR运算）用一个值称为是唯一给每个用户的盐。它可以是随机生成的，或者它可以是一个帐户创建时间戳或一些这样的。然后，攻击者不能使用彩虹表，因为每个密码基本上是哈希略有不同;他必须创建一个单独的彩虹表为每一个不同的盐（几乎每个帐户），这将是令人望而却步计算成本。

The solution is that before a password is hashed, it is combined (usually concatenated or xor'd) with a value called the salt which is unique to each user. It may be randomly generated, or it may be an account creation timestamp or some such. Then, an attacker cannot use a rainbow table because every password is essentially hashed slightly differently; he would have to create a separate rainbow table for every single distinct salt (practically for each account), which would be prohibitively computationally expensive.

我会附和其他回答者的建议：这不是简单的东西，你不需要做，因为它已经做过了，如果你自己做你站在一个很好的犯错误的机会在不经意间影响您的系统安全。但是，如果出于某种原因，你真的，真的想自己写一个，我希望我所提供的它是如何做的（不完全！）轮廓。

I will echo the advice of the other answerers: this is not simple stuff, and you don't need to do it because it's been done before, and if you do it yourself you stand a very good chance of making a mistake and inadvertently compromising your system's security. But if, for whatever reason, you really, really want to write one yourself, I hope that I have provided an (incomplete!) outline of how it's done.