перестановки кодов безопасности;методология безопасности

Question

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

Коды будут созданы с использованием Digest :: SHA qw (sha256_hex). Насколько я понимаю, один из способов избежать дублирования кодов в базе данных - создать уникальный префикс в необработанных данных, которые нужно кодировать. (см. также ниже).

Как только человек подписан, у меня есть запись в базе данных человека с двумя полями «кода», каждое из которых содержит значения, которые являются уникальными в базе данных. Каждое значение представляет собой строку буквенно-цифровых символов длиной 64 символа с использованием строчных букв (только?) A-z и 0-9, например:

code1: ae7518b42b0514d69ae4e87d7d9f888ad268f4a398e7b88cbaf1dc2542858ba3

code2: 71723cf0aecd27c6bbf73ec5edfdc6ac912f648683470bd31debb1a4fbe429e8

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

Мой вопрос:

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

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

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

Спасибо!

Питер (см. Ниже фрагмент кода)

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

#

#!/usr/bin/perl

use Digest::SHA qw(sha256_hex);

$clear = `clear`;
print $clear;

srand;

$id               = 1;
$email            = 'someone@domain.com';
$tag              = ':!:';
$password         = 'z9.4!l3tv+qe.p9@';
$rand_str         = '9' x 15;

$rand_num         = int(rand( $rand_str ));
$time             = time() * $id;

$key_data         = $id . $tag . $password . $rand_num . $time;
$key_code         = sha256_hex($key_data);

$email_data       = $email . $tag . $password . $time . $rand_num;
$email_code       = sha256_hex($email_data);

print qq~

        ID: $id
     EMAIL: $email

  KEY_DATA: $key_data
  KEY_CODE: $key_code

EMAIL_DATA: $email_data
EMAIL_CODE: $email_code

~;

exit;

#

Answer 1

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

Для N-битного действительно случайного числа у злоумышленника будет только 1 / (2 ^ N) шанс угадать его каждый раз. Даже при небольшой энтропии, скажем, 64 бита, ваш сервер должен ограничивать запросы на отписку от атакующего IP-адреса задолго до того, как злоумышленник получит значительные шансы на успех. Им бы больше повезло угадать пароль электронной почты пользователя или перехватить незашифрованную электронную почту в пути.

Вот почему коды отписки обычно короткие. Нет необходимости в длинном коде, а длинный URL, скорее всего, будет усечен или опечатан.

Answer 2

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

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

Быстрый способ генерации случайной строки:

 my $hex = join '', map { unpack 'H*', chr(rand(256)) } 1..8;
 print $hex, "\n";

 b4d4bfb26fddf220

(Это дает вам 2 ^ 64, или около 2 * 10 ^ 19 комбинаций. Или «много», если вы ограничиваете ставку.)

Answer 3

Если вы спросите, как трудно было бы «угадать» два 256-битных «числа», получив одного конкретного человека, которого вы хотите взломать, это было бы 2 ^ 512: 1 против. Если в базе данных, скажем, 1000 пользователей, и злоумышленнику все равно, кто из них получит, это 2 ^ 512: 1000 против - незначительное изменение вероятности.

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

Как и во многих вопросах безопасности, вопрос состоит в том, сколько усилий нужно приложить против выигрыша. Пароли хороши тем, что пользователи ожидают их, так что это не является существенным препятствием для рассылки URL-адресов, которые затем требуют ввода пароля. Если бы ваш URL был хотя бы одним ключом SHA в сочетании с паролем, это почти исключило бы атаку типа «посередине» на ваши электронные письма. До вас, стоит ли это того. Дешево, удобно, безопасно. Выбери один. : -)

Больше усилий было бы, чтобы gpg-шифровать вашу электронную почту с помощью открытого ключа клиента (а не вашего личного). Очевидным недостатком является то, что gpg (или pgp), по-видимому, так мало используется, что среднестатистическим пользователям вряд ли удастся его настроить. Опять же, это полностью исключило бы атаки MITM и не требовало бы пароля, так как оно в основном использует пароль закрытого ключа gpg на стороне клиента.