Безопасность - нормально ли отправлять имя пользователя и пароль через HTTP GET?

Ответ 1

Если это медицинские данные и вы живете в Соединенных Штатах, есть отличная возможность, что доступ к ней регулируется правилами HIPAA, включая требования безопасности. Вы должны просмотреть http://www.cms.hhs.gov/SecurityStandard/Downloads/SecurityGuidanceforRemoteUseFinal122806.pdf. Если вы не живете в Соединенных Штатах, я бы предположил, что вы все же можете указать на HIPAA как относящуюся к домену.

Если ваш продавец попытается вернуться за дополнительную плату, скажите: "Вы говорите, что не согласны с соответствующими правительственными стандартами? Golly, может быть, вы должны предоставить нам полную документацию по вашим стандартам безопасности и конфиденциальности, и процедуры. Потому что, очевидно, если мы получим штраф, мы пойдем за тобой" (IANAL и все такое.)

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

Ответ 2

Хороший способ сделать ваше дело - захватить относительно технического (или яркого) менеджера, который поймет, если вы покажете им живую эфирную трассу входа (смотрите здесь пароль для пользователя: MrGreen. "Поверь мне? Здесь попробуй!".

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

Сделайте прямую трассировку, объясните, что вы сделали (кто-нибудь из нашей сети может это сделать, это так же просто, как установка этой программы). Впоследствии объясните, что почти бесплатно получить шифрование, идущее в системе, которое предотвратило бы это, и что приложение едва ли должно быть изменено как минимум. И это будет иметь преимущество передачи всего зашифрованного, чтобы записи были намного более безопасными, а также.

Затем оставьте этого менеджера позаботиться о соответствующих разрешениях/утверждении бюджета/независимо.

И единственный разумный способ исправить его в целом - это действительно использовать POST (для исправления пароля, отправляемого в URL-адресах) и HTTPS.

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

Ответ 3

У вас есть два вопроса, один технический, один контрактный (и, следовательно, законный). Я бы не просил юридических консультаций по переполнению стека.

Технический ответ очевиден - эти ребята, которые сделали вашу систему, были клоунами, так как они оставили в нем зияющую дыру в безопасности.

С юридической точки зрения, это зависит от того, в какой стране вы находитесь (я замечаю, что вы из Брисбена так приветливы с другой стороны страны). Многие из них будут иметь законодательство о медицинской и/или частной жизни, которое, возможно, было нарушено, чтобы было проверено одно. Законы HIPAA, которые другие предложили изучить, являются только США; у нас может быть эквивалент в Австралии, но я вполне уверен, что законы о конфиденциальности здесь, в Оз, можно купить в игре.

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

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

Но сначала, обратитесь за помощью к адвокату. Они - отбивные донные кормушки:-), но они - люди, которые будут знать, что делать, и они лучше всего могут изучить контракты и дать вам лучшие варианты, открытые для вас. Я использовал около 10 лет назад, чтобы выйти из автомобильного контракта, который я больше не мог себе позволить, и хотя он стоил несколько тысяч долларов, это было намного лучше, чем альтернатива.

Если они не посещают SO, совет, который вы собираетесь получить здесь, либо перекошен в техническую сторону (в лучшем случае), либо совершенно опасно в юридическом смысле (тем более, что он будет в основном основан на законе США), Не желая рекламировать типы адвокатов, я знаю, что вы можете найти здесь здесь.

Желаем удачи.

Ответ 4

Даже при использовании SSL помните, что когда имена пользователей и пароли отправляются с использованием GET, они включаются как часть URL.

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

Ответ 5

Я думаю, что для вашего случая вы должны настаивать на https - даже если это над "защищенной" сетью.

Это похоже на http basic (базовый разрешает его в заголовке - что предпочтительнее, но вы также можете поместить его в URL-адрес в определенном формате, см. rfc2617 для более подробной информации).

с SSL/https, имя хоста будет в ясном (очевидно, так как оно должно найти сервер), но другие части URL-адреса должны быть безопасно зашифрованы.

Ответ 6

Это не менее безопасно, чем встроенная базовая HTTP-аутентификация. Просто убедитесь, что имя пользователя/пароль не кэшируется клиентскими веб-браузерами (это в истории вашего браузера?)

Я думаю, что самым простым и дешевым способом было бы требование HTTPS защитить ваше веб-приложение. Если пользователь переходит к URL-адресу, который является HTTP, вы можете просто перенаправить их на эквивалентный URL HTTPS.

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

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

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

Ответ 7

Это не менее безопасно, чем встроено базовая HTTP-аутентификация.

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

По крайней мере, я думаю, что они должны ПОСТАВИТЬ эту информацию на сервер.

Ответ 8

Имена пользователей и пароли никогда не должны быть отправлены незашифрованными по сети, поэтому настаивайте на HTTPS, по крайней мере, на аутентификации. Мое предпочтение было бы в том, что имя пользователя/пароль будет приниматься только через POST (чтобы он вообще не отображался в URL-адресе), но вы могли бы зашифровать и закодировать пароль, чтобы его можно было поместить в запрос GET. Я не могу представить, почему я сделал бы это вместо POST.

[EDIT] Как указывали другие, если у вас есть данные, связанные с пациентом, вам может потребоваться зашифровать все коммуникации с сервером. Если вы находитесь в США, я настоятельно призываю вас заглянуть в правила HIPAA, чтобы узнать, что, если они применяются в отношении обеспечения безопасности данные, особенно подраздел 164.306 правило конфиденциальности (PDF).

Ответ 9

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