Защищенная ссылка для отказа от подписки. Насколько достаточно шифрования?

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

// generate iv and create encrypted data
$iv = openssl_random_pseudo_bytes(16);
$encrypted = openssl_encrypt($data, 'AES-128-CBC', ENCRYPTION_KEY,0,$iv);

// send the iv along with the encrypted text
$ciphertext = $iv . $encrypted;

// generate a hash which can verify the data has not changed
$hash = hash_hmac('sha1', $ciphertext, ENCRYPTION_KEY)

// encode the data for email link
encoded = urlencode(base_64_encode($hash.$ciphertext))

Это генерирует строку вида:

www.site.com?id=YzU4MzAzMjljZWUyYmNmY2JmNjE5MGE0YzVhNDUzZjI0YmJmZWI3YoyqdFj6dxA/OVJOw2UN7HErYVV5dmhUVEJzVHBsUGd3aDNHbjVYbmFMa0dhUFczSmpXWnFBN0FyVGxkVml3S041VlhsSXd6TitJYld5QmdhWEFkL3hYSDFiRWdzN0wvNjFXYURiYlNreXpLQ1ZqWnhHMmdCSlZGaUVxU3ZGY3I3RW9GZkJYN3l4Vkp3YmJicg

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

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

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


person mseifert    schedule 13.03.2015    source источник
comment
Любые конфиденциальные данные не должны покидать вашу систему, независимо от того, зашифрованы они или нет. Конфиденциальные данные должны просто храниться в базе данных вместе со случайным и уникальным значением, таким как хэш. Хэш может быть использован для поиска других данных, если это необходимо. Кроме того, это не должен быть временный логин. Страница не должна выдавать никакой информации, просто возьмите хеш, обновите настройки пользователя и выведите сообщение с благодарностью, отписались. Если вы хотите изменить настройки электронной почты, войдите здесь.   -  person Jonathan Kuhn    schedule 14.03.2015
comment
@JonathanKuhn - временный логин, который я упомянул, предназначен для другой ссылки в электронном письме, которая ведет пользователей к сообщению, на которое подписаны. Это временно, чтобы письмо не представляло постоянной угрозы безопасности. Для этого сценария имеет смысл отправить хеш и найти остальную информацию по хэшу. Спасибо за совет.   -  person mseifert    schedule 14.03.2015


Ответы (1)


Более простой метод — это случайная строка определенной длины (например, 30 символов), хранящаяся в таблице с ограничением unique для этого поля. Это случайное значение не имеет никакого значения, кроме базы данных, и не может быть расшифровано, поскольку в нем нет никакой информации. Это имеет значение только тогда, когда вы используете его в предложении where для поиска записи в этой таблице.

person developerwjk    schedule 13.03.2015
comment
Я знал, что простой ответ очевиден. Это имеет смысл для данной ситуации. Спасибо. - person mseifert; 14.03.2015