Каковы проблемы безопасности при передаче хешированного пароля? - PullRequest
1 голос
/ 18 февраля 2009

У меня есть элемент управления Silverlight на веб-странице, и я хочу передать имя пользователя и хешированный пароль этому элементу управления в рамках InitParams.

Каковы проблемы безопасности с этим?

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

Это подводит меня к более конкретному вопросу: существует ли метатег HTML, который говорит браузеру не кэшировать страницу?

Ответы [ 4 ]

2 голосов
/ 18 февраля 2009

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

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

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

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

2 голосов
/ 18 февраля 2009

Безопасность: сначала подумайте о возможном использовании злоумышленником пароля злоумышленником (включая сравнение с другими сохраненными хешами).

Кэширование: Да, есть метатег, но вы не должны использовать его, если не обязаны; лучше установить заголовки HTTP

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

Метатеги просты в использовании, но не очень эффективны. Это потому, что они соблюдаются только несколькими кешами браузера (которые фактически читают HTML), а не прокси-кешами (которые почти никогда не читают HTML в документе). Хотя может показаться заманчивым поместить метатег Pragma: no-cache на веб-страницу, он не обязательно будет поддерживать его свежим.

1 голос
/ 18 февраля 2009

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

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

0 голосов
/ 18 февраля 2009

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

...