Хеширование конфиденциальных данных

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

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

Почему бы не использовать генератор тестовых данных для данных, которые могут идентифицировать человека?

Создание тестовых данных в базе данных

Тестировщики НЕ должны входить в систему как законные пользователи. Это явно нарушило бы требование о неразглашении любого закона о защите данных, над которым вы работаете.

Система не должна позволять никому входить в систему, используя хешированное значение. Это разрушает всю цель хеширования!

Извините, я не отвечаю на ваш конкретный вопрос, но я действительно думаю, что всю вашу систему тестирования следует пересмотреть.

ДОБАВЛЕН:

Приведенные ниже комментарии JPLemme проливают свет на то, что вы делаете, и я боюсь, что я совершенно неправильно понял (как, вероятно, те, кто голосовал за меня).

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

В этом случае ответ WW ниже более уместен, и я рекомендую всем вместо этого отдать свои голоса ему / ей. Мне жаль, что я неправильно понял.

Вообще говоря, не рекомендуется использовать собственные алгоритмы шифрования / хеширования. Существующие алгоритмы делают то, что делают, не зря.

Неужели было бы так плохо либо дать тестировщикам путь доступа, который хеширует для них имена пользователей, либо просто заставить их копировать / вставлять хэши SHA-1?

Чтобы дать вам дополнительную информацию:

Мне нужно протестировать пакет DTS, который импортирует всех пользователей системы из текстового файла в нашу базу данных. Мне будут предоставлены данные в реальном времени.

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

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

Например, обновите все имена для входа и замените каждую букву другой случайной буквой.

Хеши по определению односторонние.

Если все, от чего вы пытаетесь защититься, - это случайное прочтение данных (так что уровень шифрования низкий), сделайте что-нибудь простое, например, шифр транспозиции (отображение 1-1 разных символов друг на друга - A становится J, B становится '-', так далее). Или даже просто сдвинуть все по одному (IBM становится HAL).

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

Спасибо за ответы на все вопросы. Я думаю, что вы почти наверняка правы в том, что наша стратегия тестирования ошибочна.

Я посмотрю, смогу ли я изменить мнение сильных мира сего.

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