Каковы соображения безопасности для генератора паролей javascript?

Question

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

Теперь я размышляю над следующим решением: букмарклетом, который будет делать только одно: открыть URL на новой странице с добавленным исходным URL (например, http://example.com/password_man.html?url=slashdot.org). Сценарий, расположенный на странице из example.com сделает фактическую генерацию пароля.

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

Дополнительные уточнения:

• Генерация пароля будет производиться исключительно на стороне клиента. «Password_man.html», упомянутый в приведенном выше примере, будет содержать код javascript, аналогичный тому, который уже содержится в букмарклетах, и он будет содержать поле ввода для указания мастер-пароля
• Интерпретация параметра "url" также будет выполняться на стороне клиента. Я думаю о том, чтобы разместить этот файл как отдельную ревизию в моей учетной записи кода Google (т. Е. V1234 of password_man.html), что обеспечило бы гарантии того, что я не изменяю страницу под пользователями
• Кроме того, HTTP / HTTPS не является проблемой, поскольку вся обработка выполняется клиентским браузером, никакие данные не отправляются обратно на сервер. Вы могли бы утверждать, что атака MITM может изменить страницу так, чтобы она отправляла обратно сгенерированный пароль, например (или мастер-пароль в этом отношении) в случае, если вы используете протокол с открытым текстом (например, HTTP), но если у вас уже есть ситуация MITM, есть и другие способы атаки, которые проще сделать (например: отследить пароль от запроса, который его отправляет, или отследить идентификатор сеанса и т. Д.)

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

Answer 1

supergenpass звучит очень похоже на то, что вы предлагаете сделать.

Если для реализации в виде букмарклета требуется переносимость, существуют мультиплатформенные менеджеры паролей. Например, я использую Lastpass , он поддерживает все основные браузеры, также работает в Opera Mini, также поставляется в виде букмарклета.

Answer 2

PRNG Javascripts обычно не криптографически сильны: https://bugzilla.mozilla.org/attachment.cgi?id=349768; поэтому, если вы используете для генерации паролей, другие сайты могут угадать сгенерированный пароль или даже повлиять на выбранный пароль.

Answer 3

Если вы не возражаете против решения, ориентированного на Firefox, взгляните на Password Hasher . Существует опция «переносимая страница», которая позволяет создавать страницы, которые можно использовать с другими браузерами, но я пробовал только с Chrome

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

Answer 4

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

Если вы передадите только URL-адрес и он всегда будет использовать один и тот же пароль, то только одно лицо может использовать это приложение.

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

Если вы используете HTTPS-соединение, оно будет более защищено от отслеживания.

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

Обновление: Из-за уточнения мой ответ меняется.

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

Эта ссылка поможет объяснить это подробнее: http://www.crockford.com/javascript/private.html

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

Это должно позволить вам иметь безопасную страницу генерации пароля.