Мне нужна альтернатива инициализации векторного шифрования - PullRequest
0 голосов
/ 25 октября 2018

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

Способ, которым работает v1, заключается в простом шифровании / дешифровании номера телефона клиента и использованиив качестве идентификатора клиента в модели данных используется «aes-256-ctr».Поскольку сотрудники / руководители некоммерческих организаций не имеют доступа к ключу шифрования, они могут на законных основаниях утверждать, что не могут получить доступ к любому pii, не раскрытому добровольно их клиентами.Когда они отправляют ответное сообщение клиенту, мне просто нужно расшифровать идентификатор клиента, чтобы получить телефон, который мне нужен для отправки сообщения.

v1 стратегия шифрования:

export const encrypt = (text) => {
  const cipher = crypto.createCipher(algorithm, password);
  let crypted = cipher.update(text, 'utf8', 'hex');
  crypted += cipher.final('hex');
  return crypted;
};

export const decrypt = (text) => {
  const decipher = crypto.createDecipher(algorithm, password);
  let dec = decipher.update(text, 'hex', 'utf8');
  dec += decipher.final('utf8');
  return dec;
};

В последнее время я получал предупреждения консоли, потому что новые версии узлов будут выводить предупреждение при использовании createCipher вместо createCipheriv для использования вектора инициализации.На моем v2 rewrite я переключил его на createCipheriv, но это «случайным образом» выводило шифрование и лишало меня возможности полагаться на зашифрованный номер телефона в качестве надежного, согласованного идентификатора клиента.Возможность надежной группировки клиентских сообщений является важным требованием для обеспечения диалогового представления в UX.

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

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

Любойидеи?

1 Ответ

0 голосов
/ 25 октября 2018

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

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

РЕДАКТИРОВАТЬ: перенести существующие данныеДля каждой записи вы должны взять client_id (в настоящее время зашифрованный номер телефона), расшифровать его, HMAC и сохранить результат в новом столбце.Затем сгенерируйте новый идентификатор и установите его как client_id.Это позволяет искать по фактическому client_id и номеру телефона.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...