хеширование конфиденциальных данных - PullRequest
0 голосов
/ 06 октября 2008

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

Впрочем, тут есть одна загвоздка.

Тестерам по-прежнему необходимо иметь возможность войти в систему, используя хэшированные имена для входа в систему

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

Ypois.X.Qasdf

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

поэтому MD5, sha1 и т. Д. Не подойдут, поскольку они будут создавать очень длинные строки, а также добавлять свои собственные специальные символы, такие как + и =, которые не разрешены регулярным выражением проверки.

Так что я ищу несколько предложений о том, как этого добиться

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

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

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

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

ДОБАВЛЕНО -

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

Ответы [ 9 ]

10 голосов
/ 06 октября 2008

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

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

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

ДОБАВЛЕНО:

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

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

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

8 голосов
/ 06 октября 2008

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

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

4 голосов
/ 06 октября 2008

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

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

1 голос
/ 06 октября 2008

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

1 голос
/ 06 октября 2008

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

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

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

1 голос
/ 06 октября 2008

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

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

0 голосов
/ 06 октября 2008

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

Я посмотрю, смогу ли я изменить умы сил, которые будут

0 голосов
/ 06 октября 2008

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

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

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

0 голосов
/ 06 октября 2008

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

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

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