Как защитить пароль от чтения на клиенте?

Не выполняйте проверку в Javascript - сделайте это в своем PHP-коде.

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

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

Затем вы можете ограничить использование ключа:

• Проверка IP-адреса клиентов и агента пользователя
• Позволяя ключ, который будет использоваться только один раз (например, хранить его использование в базе данных)
• Разрешение использования ключа в течение срока, установленного с момента его создания

Вы всегда должны предполагать, что любые операции на стороне клиента могут быть подделаны.

Если я правильно понимаю вопрос, эти вопросы SO могут пытаться делать подобные вещи.

• Передача нетронутых данных из приложения Flash на сервер?
• Каков наилучший способ остановить людей, взламывающих Таблица рекордов флеш-игры на основе PHP.
• Безопасные Онлайн-списки рекордов для Не-Веб-игр

Пока вам нужно получить пароль в браузере, пользователь сможет его прочитать. Единственный способ защитить пароль от пользователя - никогда не отправлять его в браузер.

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

На самом деле, вы также не должны хранить на своем сервере пароли с открытым текстом, вы должны хранить хэш (предпочтительно SHA-1, так как MD5 был успешно взломан).

Вы могли бы вместо этого

1. [сервер чата] создайте nonce, сохраните его и отправьте клиенту
2. [клиент] отправьте nonce на первый сервер
3. [сервер входа в систему] отправьте обратно клиенту хэш a (SHA-1) хэша пароля плюс nonce
4. [клиент] отправьте nonce и хэш обратно на сервер чата
5. [сервер чата] проверьте отсутствие в сохраненном списке и удалите это для предотвращения повторных атак, затем снова вычислите хэш и проверьте, соответствует ли он тому, что вы получили от клиента

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

Отправить клиенту:

sha1(sprintf("%s%s",salt,hash_from_db))

Проверка у клиента:

sha1(sprintf("%s%s",salt, hash_func_as_on_srv(password))) == sha1_recieved_from_server

Вы можете сгенерировать свой уникальный идентификатор сеанса salt-формы, удаленный IP-адрес или что-то в этом роде.

Используйте что-то вроде MD5 для хранения пароля, а затем используйте то же самое "шифрование", передавая passwd.

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

Поскольку вас не волнует безопасность на проводе, можно ли с уверенностью предположить, что вы не заинтересованы в том, чтобы помешать пользователю получать данные с помощью какого-либо другого инструмента, такого как fiddler/firebug или Wireshark?

Если это так, то уже было предложено использовать AJAX таким образом, чтобы данные не должны были становиться частью источника, доступного для просмотра, используя опцию "Просмотр источника" или в IE, нажав клавишу F12.

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

Вы можете передать хэш MD5 данных (при условии, что оба сервера имеют доступ к оригиналу) сервер B может сгенерировать хэш MD5 из исходных данных и сравнить его с хэшем, переданным клиентом. Как уже отмечалось, это относится к атаке с повторным воспроизведением так же, как и большинство веб-приложений которые не аутентифицируют пользователей с помощью клиентских сертификатов или чего-то вроде NTLM.

Вы можете не передавать имя пользователя и пароль через клиент, а использовать идентификатор только один раз (GUID), который указывает на имя пользователя в базе данных, и попросить сервер B удалить идентификатор после его использования. Таким образом, данные хранятся в секрете, и вы избегаете повторных атак.

Существует также множество других криптографических методов, которые вы могли бы исследовать, но я думаю, вы хотите, чтобы все было просто.

Если вы отправляете (пароль и имя пользователя) на сервер B, восстановленный с сервера A, то, если вы хотите сделать его безопасным, вы должны предоставить для этого какой-то механизм безопасности (интерфейс).

Я хотел бы, чтобы вы взглянули на Двустороннее шифрование: Мне нужно хранить пароли, которые можно получить сначала вопрос. Здесь вы можете хранить key для шифрования определенных value, т.Е. username и password.

Для примера: - На сервере A мое имя пользователя user и пароль pass, а мой ключ asdfasdhfkshf, который является солью. В приведенном выше решении вы можете использовать двустороннее шифрование-дешифрование.

Всякий раз, когда я извлекаю (с помощью javascript) свои username и password Я бы получил зашифрованную версию. допустим, "sfdasdfaskuyfgdkgh2145" и "24sdf25asdf2asf42sad1fh", которые зашифрованы с помощью ключа asdfasdhfkshf. Конечно, никто не сможет угадать, если у них нет ключа, а ключ хранится на сервере A.

Теперь мы отправляем это зашифрованное имя пользователя и пароль на сервер B, на котором также хранится тот же ключ и код для расшифровки, и, конечно, сервер B сможет расшифровать его обратно в user и pass.

Таким образом, пользователь никак не может угадать, какое имя пользователя и пароль, даже если он может их просмотреть.

Но это применимо только в том случае, если вы реализовали этот интерфейс или механизм на сервере B.

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

Вместо этого для этих оценок можно использовать PHP (на стороне сервера), поскольку все эти оценки происходят на веб-сервере, обычные пользователи не будут знать, что происходит за кулисами.

Совет: Использование AJAX и PHP может обеспечить как безопасность, так и скорость реагирования, необходимая для приложения.

В качестве альтернативы вы можете выполнить вызов ajax, где вы запрашиваете пользователя/пропуск непосредственно перед доступом к другому серверу. Таким образом, он не будет отображаться в вашем коде JavaScript.

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

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

Я думаю, что лучше всего будет отправлять через PHP.

Но вы хотите использовать JS специально, поэтому вот несколько вещей, которые я могу предложить;

Зашифруйте пароль, md5(); если вы не считаете, что это безопасно, попробуйте многослойное шифрование, такое как md5(sha1(sha1())) и т. Д. и т. Д. И сохраните пароль в базе данных в зашифрованном виде как для вашей безопасности, так и для безопасности ваших пользователей. Таким образом, вы можете отправить пароль в зашифрованном виде с другим именем или псевдонимом, например "весело", чтобы скрыть от людей, чтобы знать, что это пароль.

Также вместо отправки пароля вы можете авторизовать людей с помощью их пароля с помощью PHP и просто использовать JS для передачи случайного "ключа авторизации" на основе сеанса, срок действия которого истечет в следующий раз.

А также вы можете использовать Ajax. PHP с JS для тех, о ком я говорил выше.

(...) Я получаю пароль имени пользователя с сервера A (...)

Звучит очень плохо, что в системе есть сервер паролей. Вместо этого вы можете использовать A в качестве прокси для B: клиент должен подключиться к A, который направляет трафик в и из B. Когда пользователь успешно аутентифицируется с помощью A, он может войти в систему B с сохраненным паролем.

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

Javascript:функция(){getalementbytagname('пароль').значение} вставьте его в URL

ЧАСТЬ I.
Если пользователь, имя пользователя и пароль которого получены с сервера A для аутентификации и входа на сервер B, использует интерфейс сервера A, вам не нужно беспокоиться, потому что, когда он входит в систему вручную, он делает то же самое. Он вводит пароль в поле пароля и нажимает кнопку отправить.

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

ЧАСТЬ II.
Позвольте мне перефразировать ваш вопрос, приведя пример, вы хотите сделать что-то вроде meebo.com (Ваш сервер A) где, как только кто-то войдет в систему, он сможет использовать чат facebook, чат Gmail или что-то еще. Для входа пользователей в соответствующий чат вы сохраняете их пароль и отправляете его с помощью javascript на этот сервер чата (ваш сервер B) для аутентификации.

Если это то, что вы хотите, то ваш подход неверен, ваш сервер A должен взаимодействовать с сервером B и извлекать/передавать все данные. Например, сервер A должен иметь свой собственный интерфейс чата, если пользователь отправляет "Привет" на ваш сервер чата, он должен внутренне перенаправить (отправить) это сообщение на сервер B. Аналогичный ответ с сервера B может быть показан непосредственно пользователям в интерфейсе сервера A. Хорошая особенность этого подхода заключается в том, что вам не нужно передавать имя пользователя и пароль туда и обратно, что делает его небезопасным.

ЧАСТЬ III.
Еще одна вещь, которую я хочу добавить, если вы храните имя пользователя и пароль для сервера B в база данных сервера A, затем вы должны сообщить об этом пользователю в правилах и условиях.

Вы можете создать сеанс на стороне сервера (используя http-api) и передать (идентификатор сеанса и т. Д.) Его в клиентский сеанс

Пожалуйста, обратитесь к http://metajack.im/2008/10/03/getting-attached-to-strophe/