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

Question

Мне нужно скрестить имена и логины всех пользователей в базе данных UAT, которые у нас есть. (из-за действия защиты данных)

Однако есть улов.

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

так, если Логин пользователя «Jesse.J.James», то хэш должен быть чем-то вроде

Ypois.X. Qasdf

т.е. примерно такой же длины, с точками в том же месте

так MD5, SHA1 и т.д. не были бы пригодны, как они будут создавать очень длинные строки, а также добавить свои собственные специальные символы, такие как + и = которые не допускаются b y регулярное выражение проверки.

Так что я смотрю на некоторые предложения о том, как достичь этого

Я думаю, мне нужно rollmy собственный хэширования Алгоритм Построения

Кто-нибудь делал что-нибудь подобное?

Я использую C#, но я думаю, что это не так важно для алгоритма

Большое спасибо

ADDED -

Спасибо за все ответы. Я думаю, что я несу ответственность за путаницу, используя слово «Хеш», если это не то, что нужно было сделать.

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Creating test data in a database

Answer 4

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

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

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

ДОБАВЛЕНО:

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

Я буду видеть, если я могу изменить умы предержащих

Answer 9

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