Кража моих данных POST - PullRequest
Новая
       12

Кража моих данных POST

5 голосов
/ 16 мая 2011

Хорошо, это, вероятно, довольно просто, но последствия важны для меня на этом этапе развития.Я благодарен за любой вклад и обсуждение.

Данные в этом примере не защищены с использованием SSL-шифрования.

page1.php/asp содержит форму, которая POST помещает переменные username иpassword до page2.php/asp.

  • Может ли ЛЮБОЙ из ЛЮБЫХ перехватить мои POST-данные, просто прослушав их, возможно, с помощью какого-либо стороннего программного обеспечения, такого как Firesheep?

Если приведенный выше вопрос дает значение ИСТИНА:

  • Должен ли я всегда считать свои незашифрованные данные POST свободно доступными для всех?
  • Является ли стандартная форма входа на моем сайте просто уловкой для изображенияуровень безопасности, которого даже нет?
  • Должен ли я тогда рассматривать функцию входа в систему как способ персонализировать пользовательский опыт?
  • Имеет ли смысл поощрять пользователя НЕ делать это?использовать свой обычный (предположительно безопасный) пароль, так как он не будет защищен во время процедуры регистрации и входа в систему?

Я обдумываю эти проблемы, я ценю любой вводи обратная связь.

Ответы [ 4 ]

9 голосов
/ 16 мая 2011

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

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

  1. Пользователь отправляет логин через HTTPS с именем пользователя и паролем
  2. Сервер берет пароль и применяет к нему алгоритм хэширования, обычно с использованием MD5, хотя рекомендуется что-то сильное, например SHA256
  3. Сервер сравнивает зашифрованное значение с зашифрованным значением в базе данных

Таким образом, если ваша база данных когда-либо взломана, пароли очень ОЧЕНЬ трудно определить (если только они не использовали что-то базовое, например «пароль», но в этом их вина).

Имеет ли смысл поощрять пользователь не должен использовать его или ее нормальный (предполагается более безопасный) пароль, так как он не будет защищен?

Вы будете прогонять пользователей.

2 голосов
/ 16 мая 2011

Да.Любой, кто может видеть проходящие пакеты, может видеть имя пользователя и пароль.Это делает его особенно уязвимым, когда он находится в открытых общих сетях Wi-Fi и т. П.

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

Я бы посоветовал вам перейти на SSL-вход в систему, если вы можете, отчасти потому, что очень многие пользователи будут игнорировать любые ваши советы по использованию общего пароля, а отчасти потому, чтопросто хорошая практика.Это была хорошая практика до того, как такие вещи, как Firesheep, стали настолько простыми для использования "нормальными" людьми, и теперь это еще важнее.

1 голос
/ 16 мая 2011
Должен ли я тогда рассматривать функцию входа в систему как способ персонализировать пользовательский опыт? Имеет ли смысл поощрять пользователя НЕ использовать свой обычный (предположительно безопасный) пароль, поскольку он не будет защищен во время процедуры регистрации и входа в систему?

Это зависит от веб-сайта, который использует форму входа. Большинство крупных сайтов, таких как Gmail, используют https для аутентификации при входе в систему, а затем переключаются на http. (Были сообщения, что этот переключатель также вводит некоторые уязвимости.) Другие сайты отправляют солт-значение в скрытом поле формы. Ваш оригинальный пароль заменяется солью и хешем. То же действие повторяется на сервере, чтобы убедиться, что вы отправили правильный пароль. Это происходит за кулисами, поэтому пользователь не может быть уверен, отправлено ли его в незашифрованном виде. Это ожидается от хороших сайтов, чтобы сделать это. Обычные сайты могут этого не делать. Многие страницы конфигурации маршрутизаторов и модемов не используют шифрование или запутывание.

1 голос
/ 16 мая 2011

Может ли ЛЮБОЙ из НИКОГДА перехватить мои POST-данные, просто прослушав их, возможно, с помощью какого-либо стороннего программного обеспечения, такого как Firesheep?

Нет, возле них должно пройти движение.

Если приведенный выше вопрос имеет значение ИСТИНА:

Нет, но даже так.

Должен ли я всегда считать свои незашифрованные данные POST доступными для всех?

Если только он не путешествует по локальной сети, тогда да. Если он путешествует только по локальной сети, добавьте классификатор «в этой локальной сети», и ответ будет «да».

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

нет

Нет

Должен ли я тогда рассматривать функцию входа в систему как способ персонализировать пользовательский опыт?

Конечно, вы не должны делать ничего серьезного без шифрования.

Имеет ли смысл поощрять пользователя НЕ использовать свой обычный (предположительно безопасный) пароль, поскольку он не будет защищен во время процедуры регистрации и входа в систему?

Имеет смысл сделать это для любой системы. Даже если связь была защищена, ваш сервер может быть скомпрометирован в будущем, или может быть сторонняя система, а затем данные, используемые для атаки на вашу систему.

...