Улучшение безопасности входа в систему посредством отказа от копирования и вставки?

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

...<input type="text" value="Username" /><input type="password" value="" />...

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

Однако мы добавили следующие JScripts к входным элементам:

... onpaste="return false;" oncopy="return false;" ondrag="return false;" ondrop="return false;" ...

Тестер критиковал, что по-прежнему можно "перетащить" копию с помощью CRT-ключа, конечно, он будет копировать только * символы, а не пароль, но он по-прежнему позволяет копировать значения из формы, и поэтому тест case был возвращен как не выполнен.

Так много для фона.

Мой вопрос:

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

Спасибо вам Саймон

Ответ 1

Нет. Зачем нужно, чтобы пользователь копировал свои собственные пароли?

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

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

Ответ 2

Я согласен с консенсусом здесь: Отказ от копирования и вставки означает, что мои действительно сложные пароли (хранятся в 1Password) бесполезны. Поэтому мой ответ - использовать короткие легко запоминаемые пароли (т.е. Слабые). Привлечение людей к использованию слабых паролей - идея BAD.

Кроме того, onpaste = "return false;" Я считаю, что это часть DOM, а не дополнение к javascript. Поэтому разработчик сайта действительно может прекратить такие плохие практики.

Кто-нибудь знает, есть ли веская причина использовать "return false"; - то есть, есть что-то опасное в буфере обмена? Если это так, то это делает недействительным использование таких программ, как 1Password.

Ответ 3

Я согласен со всеми, и печально, что крупные компании начинают применять эту практику сейчас, я не могу вставлять ее в paypal, xbox live, а также некоторые приложения, такие как roundcube, блокируют ее по умолчанию. Я утверждаю, что его хуже для безопасности, поскольку он заставляет конечного пользователя вводить его в значение, означая, что он либо должен быть легко запоминающимся, либо им нужно, чтобы он был виден где-то, чтобы напечатать, хорошие приложения, такие как keeppass work на основе паролей arent visible но временно копируется в буфер обмена.

Ответ 4

Предотвращение паролей с копированием и вставкой - это идея TERRIBLE - это в значительной степени делает невозможным использование длинных, случайных генерируемых безопасных паролей. Представьте себе, что я хотел использовать "JFPEWm! QjVIdrFk8l |/%" в качестве пароля - это отличный пароль, но кошмар набирать и ОЧЕНЬ подвержен ошибкам.

Ответ 5

Не на всех

Пользователь может отключить любую клиентскую сторону, включая ваши JScripts. Ваш коллеж неверно проинформирован, покажите им эту тему.

Ответ 6

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

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

http://www.windowsecurity.com/articles/Client-Certificate-Authentication-IIS6.html http://www.impetus.us/~rjmooney/projects/misc/clientcertauth.html

Ответ 7

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

Лучше инвестировать в хороший инструмент управления паролями и обучение (например, Lastpass или 1Password), чем расстраивать пользователей, что делает их более вероятными для быстрого доступа (например, с использованием того же простого пароля везде).

Ответ 8

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

Ответ 9

Спасибо, ребята,

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

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

Привет Саймон