Безопасный вход в систему с надлежащей аутентификацией в PHP
И static и class ключевые слова позволяют нам присоединять переменные к класс , а не к экземплярам класса. Когда self получен доступ в классе, он относится к фактическому классу (а не экземпляр).
Переменная
, Когда Вы делаете static property, это становится принадлежавшим классу, и не может быть измененным подклассами, тогда как, когда Вы используете class, это может быть переопределено в случае необходимости.
Функция
-
Staticфункции не могут быть переопределены.staticто же какclass final -
Class, функции (не методы экземпляра) являются также статическими функциями, но они динамично диспетчеризируются и могут быть переопределены подклассами в отличие от статических функций. -
Globalфункции могут быть сохранены в отдельном файле, который мы можем импортировать в любой проект согласно требованию. В случае [1 110] функции, если мы получаем доступ к одному из статического участника, весь класс, загружаются в памяти. Но в случае [1 111] функция, только что конкретная функция будет загружена в памяти.
6 ответов
В Rails обычно используется уже существующая библиотека. При аутентификации легко ошибиться, и проблема решалась столько раз, что редко стоит пытаться решить ее снова. Если вы хотите написать свою собственную реализацию, я опишу, как работает современная аутентификация.
Наивный метод аутентификации пользователя состоит в том, чтобы сохранить его пароль в базе данных и сравнить его с паролем, который отправляет пользователь. Это просто, но невероятно небезопасно. Любой, кто может читать вашу базу данных, может просмотреть любой пароль. Даже если вы введете контроль доступа к базе данных, вы (и ваши пользователи) уязвимы для любого, кто взломает их.
Правильная форма - использовать криптографическую хеш-функцию для обработки пароля, когда он выбран, а затем каждый раз, когда он Отправлено. Хорошая хеш-функция практически необратима - вы не можете взять хеш и превратить его обратно в пароль. Поэтому, когда пользователь входит в систему, вы берете отправленный пароль, хешируете его и сравниваете с хешем в базе данных. Таким образом, вы никогда не сохраните сам пароль. С другой стороны, если пользователь забудет свой пароль, вам придется сбросить его, а не отправить ему.
Однако даже это уязвимо для определенных атак. Если злоумышленник завладевает вашими хэшами паролей и знает, как вы хешируете свои пароли, то он может совершить словарную атаку: он просто берет каждое слово в словаре и хеширует это слово, сохраняя его вместе с оригиналом. Эта структура данных называется радужной таблицей. Затем, если какой-либо из словарных хэшей слов соответствует хешу пароля, злоумышленник может сделать вывод, что пароль - это словарное слово, хеширующее этот пароль. Короче говоря, злоумышленник, который может читать вашу базу данных, все равно может войти в учетные записи со слабыми паролями.
Решение состоит в том, что перед хешированием пароля он комбинируется (обычно объединяется или xor'd) со значением, называемым солью. который уникален для каждого пользователя. Он может быть сгенерирован случайным образом, или это может быть отметка времени создания учетной записи или что-то подобное. Тогда злоумышленник не сможет использовать радужную таблицу, потому что каждый пароль по сути хэшируется немного по-разному; ему пришлось бы создать отдельную радужную таблицу для каждой отдельной соли (практически для каждой учетной записи), что было бы чрезмерно дорогостоящим с точки зрения вычислений.
Я повторю совет других респондентов: это непростая задача, и вы не должны 'не нужно делать это, потому что это' Это было сделано раньше, и если вы сделаете это самостоятельно, у вас будет очень хороший шанс сделать ошибку и непреднамеренно поставить под угрозу безопасность вашей системы. Но если по какой-то причине вы действительно хотите написать его самостоятельно, я надеюсь, что я предоставил (неполный!) План того, как это делается.
В Zend Framework есть модуль 'Auth' , с которого можно начать. Или, если на вашем сайте будет размещена установка WordPress или PHPBB, есть способы использовать модули аутентификации этих технологий для входа на другие страницы сайта.
Одна вещь, на которую следует обратить внимание при попытке аутентификации, - это ваша настоящая цель.
Например, на SO я использую свой логин в Google, и это работает, поскольку им просто нужно чтобы узнать, кто я, и они могут поверить, что у Google есть идея. Итак, если эта модель будет работать для вас, тогда посмотрите на использование OpenID, так как для этого есть различные инструменты.
Если вы должны сделать свой собственный, тогда будут различные тесты, чтобы убедиться, что он безопасен, опять же, в зависимости от о том, насколько параноиком вы хотите быть.
- Никогда не доверяйте ничему от пользователя, если вы не использовали строгую проверку.
- Используйте https, чтобы защитить пароль пользователя, вы им в этом многим обязаны.
I закончу свой ответ здесь, поскольку Том сделал фантастический ответ.
Автор: Soulmerge:
Я думаю, что в принятом ответе на ваш другой вопрос это довольно хорошо сказано. Зашешивайте пароли с солью. Помимо этого, есть несколько идей безопасности на транспортном уровне:
- Используйте https при отправке паролей. Это гарантирует, что никто не сможет поймать их по сети ( атака «злоумышленник в середине» или клиент использует злонамеренный прокси)
- Альтернативой является хеширование пароля с использованием javascript, когда форма входа в систему Отправлено. Это гарантирует, что пароль никогда не будет передаваться в виде открытого текста. Вы должны снова хешировать хешированное значение с помощью соли на сервере. (
md5 ($ _ POST ['postedPwHash']. $ Salt))
хороший метод для некоторой защиты транзакции клиент-сервер (если ssl недоступен) - использовать одноразовый случайный ключ для создания уникального хэша из учетных данных, а затем только отправить его уникальный хеш для сервера. затем сервер сравнивает этот хеш со своим собственным сгенерированным хешем вместо того, чтобы сравнивать его с реальными учетными данными. это обеспечит хорошую защиту от атаки «человек посередине». Обратной стороной является то, что для этого у пользователя должен быть включен JS (по крайней мере, я не знаю хорошего метода для шифрования данных на стороне клиента без него). это означает, что вам понадобится достаточный запасной вариант, когда он не включен. вы даже можете создать форму на JS, чтобы убедиться, что она включена.
Эта библиотека представляет собой простую библиотеку, которую я когда-то написал, которая выполняет описанную мной процедуру, хотя, вероятно, требует некоторых улучшений.
отмечают, что это в дополнение к использованию методов «соления» и других мер безопасности на стороне сервера. он также весьма уязвим для атак по словарю, поскольку весь процесс хеширования по определению является процедурным, предсказуемым и видимым для пользователя (как всегда JS).
Мой ответ: «Не делайте этого»
Это очень сложная область, полная потенциальных проблем с безопасностью. Если вы не являетесь экспертом в этой области, то на самом деле вы просто просите о проблемах и проблемах в будущем.
Я бы порекомендовал найти существующее решение. К сожалению, я не знаю ничего, что я бы с радостью порекомендовал, кроме openid. Я уверен, что здесь вы получите несколько хороших предложений ...