Как хранить ключ шифрования AES?

Question

Я запускаю сервер DV 3.5 на MediaTemple с помощью Linux CentOS 5, php и mysql DB и пытаюсь зашифровать записи телефона с помощью AES.

я наткнулся на то, что, кажется, хороший сценарий, как PHPAES

, но я не уверен в следующем:

1. Где я на самом деле хранения ключа шифрования AES , используемый для шифрования и расшифровать номер телефона?

2. Как я могу позвонить на шифрование ключа AES, когда пользователь отправляет свои данные через форму и сохраняет в нашу базу данных MySQL ?

3. Когда я хочу раскрыть эту информацию для наших внутренних агентов по обслуживанию клиентов - как они в свою очередь вызывают ключ AES?

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

Answer 1

Я на самом деле в конечном итоге будет этот маршрут:

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

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

вполне безопасный, на мой взгляд.

Answer 2

Я разработал процесс, в котором я начинаю с начального ключа шифрования, который я кодирую в хэш SHA1, затем шифрую с помощью комбинации с именем пользователя/паролем и сохраняю его в базе данных. Пароль (хешированный или иным образом) никогда не сохраняется в базе данных и используется только для входа в систему, чтобы расшифровать ключ шифрования. Затем я использую это имя мастера/пароль для создания дополнительных пользователей с паролями, в которых PHP или JavaScript кодирует ключ дешифрования с именем пользователя/паролем нового пользователя и сохраняет зашифрованный ключ в базе данных. Когда я пытаюсь дешифровать ключ шифрования из базы данных, используя комбинацию имени пользователя/пароля, я должен ожидать хэш SHA1. Если я не получу действительный хэш-файл SHA1, который может расшифровать данные, тогда я знаю, что пароль неправильный, и данные непригодны для использования. У вас должна быть действующая комбинация имени пользователя и пароля, чтобы получить ключ дешифрования и который передается клиенту через SSL, дешифруется с помощью функции JavaScript, а затем сохраняется в cookie для сеанса SSL.

Чтобы обойти систему, расшифруйте данные и получите доступ к информации, которую вы должны были бы заразить, с помощью ключа-регистратора или трояна, который просматривал ваши файлы cookie во время этого сеанса входа в систему, в противном случае владелец сервера или клиент без имени пользователя/комбинация паролей может использовать данные в базе данных без грубой принудительной установки. Используя AES 256-битные и надежные пароли (12 + символов, A-Z, a-z, 0-9, символы и т. Д.), И у вас есть довольно сложное решение, или, по крайней мере, одно, что было бы больно пытаться.

У каждой учетной записи есть функция блокировки, поэтому, если вы пытаетесь входить в систему через Интернет слишком много раз и терпеть неудачу, учетная запись заблокирована.Все PHP-страницы кодируют/декодируют параметры для предотвращения атак SQL-инъекций и проверки сеанса PHP активны и соответствуют последнему сеансу, отслеживаемому во время входа в систему, а также проверяет ваш ключ шифрования. Каждый раз, когда вы входите в систему или посещаете страницу входа в систему, предыдущий сеанс считается недействительным, или если ваш сеанс не работает, он также недействителен. Даже со всеми этими слоями он быстро и не позволяет людям использовать PHP-скрипты, которые выводят JSON с использованием сфабрикованных POST-скриптов и атак SQL-инъекций. Это также ограничивает способность владельца/администратора сервера расшифровывать и читать вашу информацию, если она хранится у общего поставщика и т. Д.