В Rails обычно используют уже существующую библиотеку. Аутентификацию легко сделать неправильно, и проблема решалась столько раз, что редко стоит усилий, чтобы решить ее снова. Если вы заинтересованы в написании собственной реализации, я опишу, как работает современная аутентификация.
Наивным методом аутентификации пользователя является сохранение его пароля в базе данных и сравнение его с паролем, который отправляет пользователь. Это просто, но невероятно небезопасно. Любой, кто может прочитать вашу базу данных, может просмотреть любой пароль. Даже если вы включите контроль доступа к базе данных, вы (и ваши пользователи) уязвимы для всех, кто их взламывает.
Правильная форма - использовать криптографическую хеш-функцию для обработки пароля при его выборе, а затем при каждом его отправке. Хорошая хеш-функция практически необратима - вы не можете взять хеш и превратить его обратно в пароль. Поэтому, когда пользователь входит в систему, вы берете введенный пароль, хэшируете его и сравниваете с хэшем в базе данных. Таким образом, вы никогда не сохраняете сам пароль. С другой стороны, если пользователь забывает свой пароль, вы должны сбросить его, а не отправлять ему.
Даже это, однако, уязвимо для определенных атак. Если злоумышленник завладеет ваши хэши паролей и знает, как вы хэшируете свои пароли, он может провести атаку по словарю: он просто берет каждое слово в словаре и хэширует это слово, сохраняя его с оригиналом. Эта структура данных называется радужной таблицей. Затем, если любое из хэшей словарного слова соответствует хэшу пароля, злоумышленник может заключить, что пароль - это словарное слово, которое хэширует этот пароль. Короче говоря, злоумышленник, который может прочитать вашу базу данных, все равно может войти в учетные записи со слабыми паролями.
Решение состоит в том, что перед хэшированием пароля его объединяют (обычно сцепляют или xor'd) со значением, называемым солью, которое уникально для каждого пользователя. Это может быть случайно сгенерировано, или это может быть метка времени создания учетной записи или что-то подобное. Тогда злоумышленник не может использовать радужную таблицу, потому что каждый пароль по сути хэшируется немного по-разному; ему придется создать отдельную радужную таблицу для каждой отдельной соли (практически для каждой учетной записи), что будет непомерно дорого в вычислительном отношении.
Я повторю совет других ответчиков: это не простые вещи, и вам не нужно делать это, потому что это было сделано раньше, и если вы делаете это самостоятельно, у вас очень хорошие шансы сделать ошибку и непреднамеренно ставит под угрозу безопасность вашей системы. Но если по какой-то причине вы действительно действительно хотите написать ее самостоятельно, я надеюсь, что я предоставил (неполное!) Описание того, как это делается.