Есть ли способ иметь постоянное (независимо от того, насколько маленькое) хранилище на стороне клиента через Интернет?

Question

Хорошо, так как никто из вас, ребята, не любит мой вопрос, позвольте мне перефразировать его.

Пользователь входит в форму HTML. С JavaScript их пароль хэшируется локально (тоже соленый). Сервер знает, какой должен быть пароль + соль, пользователь уже зарегистрирован, бла-бла. Теперь пользователь запрашивает страницу. Сервер отправляет случайный идентификатор пользователю. Когда пользователь загружает следующую страницу, этот случайный идентификатор добавляется к ключу, который он хранит локально, он хэшируется и ТА отправляется на сервер. Сервер знает, что это за ключ, и случайный идентификатор, выполняет тот же хэш и сравнивает. Если они совпадают, поздравляю, это пришло с надлежащего компьютера. Если нет, то кто-то отслеживает ваш трафик TCP / IP.

Все это, очевидно, без SSL, в противном случае это было бы крайне избыточным.

Мой вопрос - КАК ХРАНИТЬ КЛЮЧ НА КЛИЕНТСКОМ ПК?

Исходное сообщение:

Hello;

Я работаю над разработкой системы управления контентом PHP и разработал систему безопасного входа в систему. Единственная проблема заключается в том, что для этого потребуется некоторая форма хранения на стороне клиента (для очень маленького ключа длиной 40 символов), иначе пользователю придется вводить свой пароль при каждой загрузке страницы.

Есть ли способ, с помощью PHP или JavaScript, я могу сохранить небольшую строку из 40 символов на компьютере клиента и получить ее позже?

РЕДАКТИРОВАТЬ: печенье не вариант. Эта 40-символьная строка НЕ ​​МОЖЕТ покинуть компьютер клиента, и все установленные файлы cookie отправляются с каждым заголовком HTTP.

Я ПОВТОРЯЮ - ПЕЧЕНЬЕ БЕЗОПАСНЫ, И НЕ ВАЖНЫЙ ВАРИАНТ ДЛЯ ЭТОГО.

Позвольте мне переделать это так - клиент отправляет форму HTTP. При использовании некоторого языка сценариев (например, JavaScript) пароль удаляется из формы, НЕ отправляется на сервер, зашифровывается и хранится на стороне клиента, которую я могу получить и проверить (хэшируя его с помощью ключа, отправленного пользователю из сервер). Эта проверка отправляется на сервер, никогда не ключ .

Answer 1

Уже существует браузерная система, использующая ключи для безопасной передачи данных. Это называется SSL.

Answer 2

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

Вы можете использовать Flash локальный "SharedObject",

Silverlights 'IsolatedStorage

или эквивлант в Google Gears.

но ..

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

Answer 3

Сначала я отвечу на вопрос «могу ли я хранить данные на стороне клиента без использования файла cookie»:

• Вы можете использовать Flash SharedObject , но, конечно, требуется Flash, и пользователь должен щелкнуть окно подтверждения, чтобы разрешить его.
• HTML5 имеет клиентские базы данных, поэтому есть еще один вариант для вас.
• Используйте Google Gears на стороне клиента и используйте их локальную API базы данных

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

Answer 4

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

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

Answer 5

Используйте cookie, если хотите сохранить его между посещениями браузера. Он будет храниться на компьютере клиента.

Используйте сеанс, если вы хотите сохранить его на более короткий срок. Он будет храниться на веб-сервере.

Answer 6

Если вы хотите создать что-то, что никогда не путешествовало по Интернету, вам, в основном, придется делать все это на JavaScript.

Сначала создайте фрагмент кода, который запускает что-то вроде Google Gears. Используйте базу данных в Google Gears для хранения ключа.

Далее, на остальных страницах есть фрагмент javascript, который проверяет ключ в базе данных Google Gear. Если ключ недействителен, удалите его, перенаправьте пользователя и заставьте его снова войти в систему.

Answer 7

Я вижу проблему с вашим подходом. Первую загрузку исходного JavaScript можно прослушать, поэтому солевой алгоритм не защищен от хакера. Тогда ID тоже "публичный". То есть Похоже, у вас есть следующая схема (поправьте меня, если я ошибаюсь):

password + SHA1 => hashed password
hashed password + (ID from server) + (salt from server) => mega hashed password

У меня действительно есть проблема, чтобы понять, почему "мега хешированный пароль" более безопасен, чем хешированный.

Answer 8

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

http://ajaxian.com/archives/webkit-does-html5-client-side-database-storage

Answer 9

Cookies - это способ сделать это, но вы не будете хранить пароль в cookie, это (почти) заказ;

Вы можете использовать сеанс для хранения информации между загрузками страниц на стороне сервера. http://fr.php.net/manual/en/book.session.php