краевые кейсы для пользовательской системы

Question

Итак, я пишу систему пользователя/аутентификации для веб-фреймворка node.js.

Какие крайние случаи я должен беспокоить из соображений удобства использования или безопасности?

Answer 1

Пароли должны быть хэшированы в базе данных с использованием алгоритма одностороннего хэша. Это мешает вам узнать свой пароль. Выбор правильного алгоритма важен. MD5 считается небезопасным из-за множества уязвимостей. SHA1 не доказал, что он небезопасен, поскольку MD5 имеет, но он считается теоретически слабым. Лучше перейти на SHA2 или SHA256. SHA2 требуется правительство к концу 2010 года

http://en.wikipedia.org/wiki/MD5

Пароли должны быть соленым. Это предотвращает атаки словаря на ваш пароль. Объединив случайный фрагмент информации, злоумышленник не может взять кучу слов и попробовать их один за другим, чтобы увидеть, какие хэши совпадают в вашей системе.

http://en.wikipedia.org/wiki/Salt_(cryptography)

Ключ укрепление помогает бороться слабые пароли, потому что слабые пароли повредить безопасности вашей системы. Вы можете повторять несколько раз в несколько раз, используя алгоритм хеширования, чтобы повысить сложность принудительного ввода паролей.

http://en.wikipedia.org/wiki/Key_strengthening

Убедитесь, что пользователи передают свои логины через протокол HTTPS для веб-приложений. В противном случае они передают свои пароли в ясном виде. Не пытайтесь усвоить Javascript. Просто используйте https и сделайте с ним.

Вы должны весить удобство использования с конфиденциальностью. Использование адреса электронной почты вместо имени пользователя действительно приятно, потому что его легко запомнить, но если у вас есть социальный сайт, людям не понравится публикация их адреса электронной почты. Иногда приятно принимать имя пользователя или адрес электронной почты.

Еще одна вещь, которую вам нужно учитывать, - это то, как ваши пользователи будут входить в вашу систему. Сессии, файлы cookie и т. Д. Сессии - это просто, но они могут стать дорогими, если на вашем сайте миллионы пользователей. Вы можете использовать memcache или одно из множества распределенных кэшей в Java для их хранения. Однако другие альтернативы используют HMAC. Помните, что в отличие от однонаправленных хэшей HMAC имеет закрытый ключ, который должен быть защищен на ваших серверах. Примите меры для обеспечения секретного ключа с помощью какой-либо формы симметричного шифрования, если вы решите использовать файлы cookie HMAC + для идентификации пользователей. Также у вас есть дата смерти, когда HMAC нельзя использовать в прошлом. HMAC должны быть хорошими только в течение фиксированного периода времени. Ваше программное обеспечение должно обеспечить это. Не полагайтесь на тайм-ауты cookie, чтобы сделать это за вас.

Другие вещи, которые следует учитывать, используют OpenID, потому что это действительно помогает вашим пользователям получить доступ к вашему сайту без необходимости проходить процесс регистрации. У меня есть приложение для Android, которое я не запрашиваю для учетной записи, но если они предпочитают использовать определенные функции, я прошу их зарегистрироваться. И удержание пользователей намного выше, не заставляя их входить в систему. Люди падают во время процесса регистрации.

Убедитесь, что ваши методы в приложении заставляют кого-то пройти проверку подлинности до их выполнения. У вас должен быть способ принудительно вызвать все вызовы методов через часть вашего приложения до того, как метод будет вызван, и если они не будут аутентифицированы, перенаправите их на логин. Попытайтесь вспомнить страницу, на которой они тоже шли.

Есть и другие, но я не совсем уверен, что это то, что вы ищете. Удачи, и он платит, чтобы сделать небольшое исследование с Google по безопасности.

Answer 2

Распространенные случаи края:

• Люди забывают пароли.
• Люди выключают Javascript, Flash, cookies ... любую технологию, на которую вы могли бы рассчитывать, чтобы полагаться.
• Безопасность сложна, и все, что вам нужно сделать, это испортить один раз, чтобы разрушить ваш месяц. Моя рекомендация: Пусть кто-то другой это сделает. Если вы не можете изобрести это колесо, сделайте это.