Как зашифровать пароль в mysql
Как хранить пароли в БД (PHP). Шифрование, хеширование паролей
Почему нельзя хранить пароли в открытом виде
Но если в его руках окажутся логины и пароли, он может попытаться использовать эти данные для входа в почтовые сервисы (Gmail, Яндекс.Почта, Mail.ru и т.д.), социальные сети, мессенджеры, клиент-банки и т.д.
В тот же личный кабинет Пятёрочки, чтобы перевыпустить карту и потратить чужие бонусы.
В общем, пользователи сайта, которые везде используют одни и те же логины и пароли, могут получить кучу проблем.
Некоторые разработчики считают, что их приложение надёжно защищено и никаких утечек быть не может. Есть несколько причин, почему это мнение ошибочно:
Короче, пароли в открытом виде хранить нельзя.
Шифрование и хеширование
Разница между этими двумя действиями в том, можем ли мы из случайного набора символов получить исходную строку по какому-то известному алгоритму.
Приведу пример шифрования. У нас есть сообщение:
Зашифровали. Теперь для расшифровки нужно выполнить обратную операцию, сдвинуть все буквы на 1 символ назад. К слову, этот алгоритм шифрования называется шифр Цезаря (Википедия).
В отличие от шифрования, хеширование не имеет (вернее, не должно иметь) способа «расхешировать» строку обратно:
Шифрование паролей
Не надо шифровать пароли.
Алгоритм дешифровки можно украсть или подобрать. При использовании хеширования неважно, знает ли его алгоритм злоумышленник, это не особо поможет ему в получении исходного пароля из хеша.
Хеширование паролей и авторизация
Для хеширования паролей в PHP существует функция password_hash() :
Вторым параметром передаётся алгоритм хеширования. По-умолчанию это указанный нами bcrypt, но я рекомендую указывать его вручную, поскольку базовый алгоритм в будущем может поменяться. Будет грустно, если при очередном обновлении версии PHP на сайте отвалится авторизация.
Для проверки корректности введённого пользователем пароля используется функция password_verify() :
Таким образом, хранить исходный пароль больше нет смысла.
Да, разные алгоритмы хеширования генерируют хеш разной длины, поэтому рекомендуется хранить хеш в поле с типом VARCHAR(255).
Алгоритмы MD5 и SHA1
Для хеширования паролей их использовать нельзя!
Эти данные затем передаются в userLoginQueries.php, где выполняется запрос.
Когда пользователь вводит свои регистрационные данные, выполняется следующий запрос:
Как я могу изменить свой код так, чтобы пароль пользователя был зашифрован?
3 ответа
В настоящее время я пытаюсь запустить отладочную почту. В тот момент, когда произойдет ошибка, он отправит письмо с ошибкой на почту, которую я использую. Но после того, как он позволил кому-то проверить его, он действительно получил мой почтовый пароль и почту из него и решил изменить пароль.
Вы действительно должны хранить свой пароль с помощью алгоритма хэширования http://en.wikipedia.org/wiki/ Hash_function (односторонний алгоритм) с использованием соли, см. http://en.wikipedia.org/wiki/ Salt_(криптография)
Одна из основных причин этого заключается в том, что если ваша база данных будет скомпрометирована, злоумышленник не будет знать, каков фактический пароль.
Простой алгоритм хеширования-sha-1. Вы можете посмотреть, как его использовать здесь http://php.net/manual/en/function.sha1.php
Перемешивание с использованием соли
В следующий раз, когда вы захотите проверить пароль, просто сравните введенный пароль и вашу соль с фактическим значением и солью. Это позволит вам узнать, является ли пароль правильным, без необходимости сохранять пароль пользователя в открытом тексте.
Зачем использовать соль?
Ну, хотя обычно односторонние функции не могут быть отменены, их можно грубо принудить. Это может означать, что даже если вы используете алгоритм хеширования, некоторые пароли могут быть уязвимы.
Кроме того, хэши сами по себе недостаточно хороши. Оказывается, что сами базы данных паролей постоянно скомпрометированы, и хакеры часто уже знают ваши значения hash. Хакеры потратили много ресурсов на создание готовых таблиц ввода паролей, которые приведут к заданному значению hash. Так что для моего примера пять-«digit» hash у них будет что- то предварительно вычисленное для каждого возможного hash от «00001» до «99999». Их значение для «12345» может не соответствовать моему «p4$$w0rd»,, но это не имеет значения: если он производит тот же hash, это достаточно хорошо. Хакер может использовать это, чтобы просмотреть скомпрометированную базу данных и обнаружить действительный набор учетных данных для каждого пользователя. По этой причине вам также необходимо посолить свои пароли, прежде чем вы их hash. Когда вы солите пароль, вы изменяете отправленную строку перед ее хэшированием. При проверке подлинности моего примера пароля вместо проверки «p4$$w0rd» вы сначала добавите соль моей учетной записи пользователя и hash результат. Если взломщик знает мой hash и может найти входные данные, которые приведут к моему hash в таблице, это больше не поможет ему, потому что вы измените его входные данные таким образом, чтобы нарушить все предварительно вычисленные результаты hash. Это заставляет его вернуться к грубой силе, чтобы угадать каждый пароль.
Прежде всего, я хочу повторить, что я не спрашиваю, как HASH пароль (например, salting / bcrypt / etc). Для каждого другого проекта, который я делал, я всегда хэшировал / солил пароли, но в этом случае мне нужно временно восстановить пароль. В принципе, мне нужно сохранить пароль в моем DB, а.
Похожие вопросы:
У меня есть три пользователя в MySQL, а именно root, testuser1, testuser2. Я хочу зашифровать пароли для всех трех пользователей при подключении к базе данных MySQL, набрав следующую команду в.
У меня есть три пользователя в MariaDB, а именно root, testuser1, testuser2. Я хочу зашифровать пароли для всех трех пользователей при подключении к MariaDB, введя следующую команду в terminal, 1.
Я хочу сохранить идентификатор пользователя и пароль в базе данных MySql для моего проекта WinForms. Один из моих друзей сказал мне, что это небезопасно; я должен зашифровать и сохранить это. Я.
В настоящее время я пытаюсь запустить отладочную почту. В тот момент, когда произойдет ошибка, он отправит письмо с ошибкой на почту, которую я использую. Но после того, как он позволил кому-то.
Прежде всего, я хочу повторить, что я не спрашиваю, как HASH пароль (например, salting / bcrypt / etc). Для каждого другого проекта, который я делал, я всегда хэшировал / солил пароли, но в этом.
Я собираюсь через этот учебник, и я с помощью функции Encrypt MySQL. http://www.pixelinx.com/2010/10/creating-a-mail-server-on-ubuntu-using-postfix-courier-ssltls-spamassassin-clamav-and-amavis / Но.
Шифрование в MySQL: использование Master Key
В преддверии старта нового набора на курс «Базы данных» продолжаем публиковать серию статей про шифрование в MySQL.
В предыдущей статье этой серии (Шифрование в MySQL: хранилище ключей) мы говорили о хранилищах ключей. В этой статье мы рассмотрим, как используется главный ключ (master key), а также обсудим достоинства и недостатки шифрования методом конвертов (envelope encryption).
Идея шифрования конвертов заключается в том, что используемые для шифрования ключи (ключи табличных пространств) шифруются другим ключом (главным ключом, master key). Для шифрования данных фактически используются ключи табличных пространств. Графически это можно представить так:
Таблица A зашифрована ключом 1 (Key 1). Ключ 1 шифруется с помощью главного ключа (master key) и хранится в зашифрованном виде в заголовке таблицы A.
Таблица B зашифрована ключом 2 (Key 2). Ключ 2 шифруется с помощью главного ключа (masker key) и хранится в зашифрованном виде в заголовке таблицы B.
Когда серверу необходимо расшифровать таблицу A, он получает главный ключ из хранилища, читает зашифрованный ключ 1 из заголовка таблицы A и расшифровывает ключ 1. Расшифрованный ключ 1 кэшируется в памяти сервера и используется для расшифровки таблицы A.
InnoDB
В InnoDB фактическое шифрование и дешифрование выполняются на уровне ввода-вывода. То есть страница шифруется непосредственно перед тем, как она сбрасывается на диск и расшифровывается сразу после считывания с диска.
В InnoDB шифрование работает только на уровне табличных пространств. И по умолчанию все таблицы создаются в отдельных табличных пространствах (file-per-table tablespace). Говоря иными словами, создается табличное пространство, которое может содержать только одну таблицу. Хотя вы можете создавать таблицы также и в основном табличном пространстве (general tablespace). Но в любом случае таблица всегда находится в каком-то табличном пространстве. И поскольку шифрование осуществляется на уровне табличного пространства, то оно либо полностью зашифровано, либо нет. То есть нельзя в основном табличном пространстве зашифровать только часть таблиц.
Если по какой-либо причине у вас отключен file-per-table, то все таблицы создаются внутри системного табличного пространства (system tablespace). В Percona Server for MySQL можно зашифровать системное табличное пространство с помощью переменной innodbsystablespaceencrypt или используя потоки шифрования (encryption threads), но это все еще экспериментальная функция. В MySQL этого нет.
Прежде чем двигаться дальше, нам нужно рассмотреть структуру идентификатора главного ключа (master key ID). Он состоит из UUID, KEYID и префикса «INNODBKey». Выглядит это так: INNODBKey-UUID-KEYID.
Теперь, когда мы знаем, как выглядит идентификатор главного ключа, давайте посмотрим на заголовок зашифрованного табличного пространства. Когда табличное пространство шифруется, то информация о шифровании добавляется к заголовку. Выглядит это следующим образом:
Все это время я немного упрощал, говоря, что в заголовке есть зашифрованный ключ табличного пространства. На самом деле, ключ табличного пространства и вектор инициализации хранятся и шифруются вместе с помощью главного ключа. Помните, что перед шифрованием ключа табличного пространства и вектора инициализации, для них вычисляется CRC32.
Зачем нужен CRC32?
Если в двух словах, то для того чтобы убедиться в валидности главного ключа. После расшифровки ключа табличного пространства и вектора инициализации, вычисляется контрольная сумма и сравнивается с CRC32, хранящейся в заголовке. Если контрольные суммы совпадают, то у нас правильный главный ключ и ключ табличного пространства. В противном случае табличное пространство помечается как отсутствующее (мы все равно не сможем его расшифровать).
Если вы читали прошлую статью этой серии (Шифрование в MySQL: хранилище ключей), то, возможно, помните, что при использовании серверного хранилища ключей, сервер при запуске получает только список идентификаторов ключей, а точнее, key id и user id, так как эта пара однозначно идентифицирует ключ. А теперь я говорю, что сервер при запуске получает все ключи, необходимые ему для проверки возможности расшифровки ключей табличных пространств. Так почему же при инициализации, в случае серверного хранилища, загружаются только keyid и userid, а не все ключи? Потому что вам могут быть не нужны все ключи. В основном это связано с ротацией главного ключа. При ротации главного ключа в хранилище создается новый главный ключ, но старые ключи не удаляются. Таким образом, в серверном хранилище ключей у вас может находиться много ключей, которые не нужны серверу и, следовательно, не извлекаются при запуске сервера.
Настало время немного поговорить о достоинствах и недостатках шифрования с использованием главного ключа. Самым большим преимуществом является то, что вам нужен только один ключ шифрования (главный ключ), который будет храниться отдельно от ваших зашифрованных данных. Это делает запуск сервера быстрым, а хранилище небольшим, что облегчает управление. И также единственный главный ключ легко перегенерировать.
Однако шифрование с помощью главного ключа имеет один большой недостаток: после того как табличное пространство зашифровано с помощью tablespace_key, оно всегда остается зашифрованным одним и тем же ключом. Ротация главного ключа здесь не помогает. Почему это недостаток? Мы знаем, что в MySQL есть баги, которые могут привести к внезапному сбою и созданию core-файла. Так как core-файл содержит дамп памяти сервера, может случиться так, что в дампе будет расшифрованный ключ табличного пространства. Что еще хуже, дешифрованные ключи табличного пространства хранятся в памяти, которая может свопиться на диск. Вы можете сказать, что это не недостаток, так как вам нужны root-права для доступа к этим файлам и разделу подкачки. Да. Но root нужен только на некоторое время. Как только кто-то получит доступ к дешифрованному ключу табличного пространства, он / она сможет продолжить использовать его для расшифровки данных, даже без прав root. Кроме того, диск может быть украден, а раздел подкачки / core-файлы можно прочитать с помощью сторонних средств. Цель TDE состоит в том, сделать его нечитаемым, даже если диск будет украден. В Percona Server for MySQL есть возможность повторного шифрования табличного пространства с новыми сгенерированными ключами. Эта функция называется потоками шифрования (encryption threads) и на момент написания этой статьи все еще является экспериментальной.
Базу данных не стащить: правильные способы защитить данные в таблицах БД
Содержание статьи
Как же ошибаются те люди, которые доверяют защиту данных исключительно самой
СУБД. Мол, если пароль на подключение хороший и версия демона – самая последняя,
то все будет нормально. Ничего подобного. Базы как сливали, так и будут сливать.
А наша задача – сделать их нечитаемыми для тех, кому они не предназначены.
Актуальная проблема из мира информационной безопасности – обеспечить
сохранность данных. Есть ситуации, в которых даже при наличии серьезной защиты
системы, сохранность данных оказывается под большим вопросом. Как так? Могу
привести пример из личного опыта, когда в разглашении информации был виновен
засланный сотрудник конкурирующей компании. Находясь на рабочем местом и будучи
технически подкованным, он взламывал сервера баз данных банальным брутфорсом
через терминальное соединение. Базы с клиентами «засланец» перепродавал другим
компаниям, а «интересная» информация о ведении бизнеса отправлялась сотрудникам
силовых структур. Что из этого вышло, объяснять излишне.
Вообще, имея физический доступ к локальной сети, инсайдер мог поступить
гораздо проще: атаковать программу, которая работает с базой данных. Нередко
сценарий взлома сводится к тому, что из программы разными способами извлекаются
конфиги для подключения к базе. Захватив ту же 1С, которая хранит в себе конфиги
подключения к базе (в том числе, шифрованный обычным XOR’ом пароль),
злоумышленник получает доступ к самой базе. Особо не стесняясь, он может ее
выкачать, модифицировать или просто удалить. Такая брешь в защите способна
сыграть злую шутку, особенно в корпоративной среде.
В статье я как раз хочу рассказать о том, как обезопасить информацию в
обычной базе данных. Даже если СУБД будет взломана или левый человек скопирует
данные, утечки конфиденциальной информации не произойдет!
Шифрованию – быть!
Общий подход прост до гениального: раз злоумышленник гипотетически сможет
извлечь данные, надо сделать так, чтобы он их не смог прочитать. Информацию все
равно придется хранить в базе, но… ничего не мешает хранить ее в каком угодно
виде, в том числе зашифрованном! Главное, чтобы мы сами потом смогли
расшифровать :).
Компания Spelabs (www.spellabs.ru/spellabsCrypto1C.htm)
как-то анонсировала продукт, организующий дополнительную безопасность
бухгалтерских 1С на уровне шифрования данных, причем на полностью прозрачном
уровне. Пользовательские приложения, не подозревая о надстройке, работали в
обычном режиме. Увы, компания прекратила разработку этого направления. Но
реально обойтись и без подобных инструментов, ведь для шифрования сгодятся даже
штатные средства СУБД!
Любая современная СУБД, если это, конечно, не собранная на коленке курсовая,
может похвастаться достаточно надежными механизмами шифрования данных. В той же
самой MySQL я по памяти насчитал около 14 соответствующих функций, которые тебе
наверняка хорошо известны:
Для их применения надо лишь чуть изменить свои SQL-запросы, добавив в нужном
месте функции AES_ENCRYPT() или DES_ENCRYPT(), которые считаются наиболее
надежными в MySQL на текущий момент. Например, так:
INSERT INTO t VALUES (1,AES_ENCRYPT(‘text’,’password’));
Приятно признать, что хорошие программисты эти функции используют. Часто во
время проведения SQL-инжекции мне приходилось ломать голову и определять
функцию, которую использовал кодер для крипточки данных. В результате, требуется
производить те же AES_DECRYPT(AES_ENCRYPT()) наряду с unhex(hex()).
Помимо симметричного шифрования, когда упаковка и распаковка текста
производятся одним и тем же ключом (общим для двух участников обмена
сообщениями), поддерживается и ассиметричное криптование. Идея ассиметричных
алгоритмов подразумевает наличие двух ключей – открытого и закрытого
(секретного). Один из них используется для шифрования информации, а другой — для
дешифрования. Если кодирование осуществляется с помощью открытого ключа, то
расшифровать такие данные можно только с помощью парного ему закрытого.
Предлагаю разобраться с этим на примере Microsoft SQL Server, который часто
используется в корпоративных порталах и сложных приложениях.
Для шифрования применяются функции T-SQL, представляющие собой специальное
дополнение языка SQL. Оно поддерживает управляющие операторы, локальные
переменные и различные дополнительные функции.
USE Bank;
CREATE CERTIFICATE andrej
ENCRYPTION BY PASSWORD = ‘pGFD4bb925DGvbd2439587y’
# Для генерации с использованием подгрузки из файла
# FROM FILE = ‘c:\Shipping\Certs\Shipping11.cer’
# WITH PRIVATE KEY (FILE = ‘c:\Shipping\Certs\Shipping11.pvk’,
WITH SUBJECT = ‘Employers Access’,
EXPIRY_DATE = ’10/31/2009′;
GO
У нас создался сертификат! Теперь его можно без проблем использовать для
размещения в таблице зашифрованных записей, выполняя привычные SQL-запросы:
INSERT INTO [БАЗА].[ТАБЛИЦА]
values( N’ДАННЫЕ ДЛЯ ЗАШИФРОВКИ’,
EncryptByCert(Cert_ID(‘andrej’), @cleartext) );
GO
В этом примере неформатированный текст из переменной @cleartext шифруется
сертификатом с именем «andrej». Зашифрованные данные помещаются в таблицу
«ТАБЛИЦА». Уточню, что данные могут быть расшифрованы только с помощью
соответствующего закрытого ключа (как уже было сказано, «приватного»).
Имя функции для обратного преобразования угадать несложно: DecryptByCert(). А
вот синтаксис более хитер, и с ним все чуть сложнее. Дело в том, что на
приватный ключ, как правило, закладывается дополнительный пароль (passphrase).
Его необходимо ввести, и по этой причине он обязательно будет присутствовать в
коде запроса или процедуры. Это не очень хорошо, потому что в этом случае его
можно быстро увести. Но с этим мы разберемся позже, когда поговорим о
безопасности хранимых процедур. А пока – код для извлечения данных из
шифрованной базы данных:
SELECT convert(nvarchar(max), DecryptByCert(Cert_Id(‘andrej’),
ProtectedData, N’pGFD4bb925DGvbd2439587y’))
FROM [БАЗА].[ТАБЛИЦА]
WHERE Description
= N’Employers Access’;
GO
В этом примере производится выборка строк из таблицы [БАЗА].[ТАБЛИЦА],
помеченных как «Employers Access». Пример дешифрует зашифрованный текст с
помощью закрытого ключа сертификата «Andrej» и дополнительного пароля
pGFD4bb925DGvbd2439587y. Расшифрованные данные преобразуются из типа varbinary в
тип nvarchar.
Надо сказать, что ассиметричные преобразования гораздо более накладны, чем
шифрование и дешифрование с использованием симметричного ключа. Поэтому
использование ассиметричного шифрования не рекомендуется при работе с большими
объемами данных, например, таблицами пользовательских данных. Это важно
учитывать при особо больших базах, а также базах, структура которых не приведена
к одной из нормальных форм.
Прячем хранимые процедуры!
Если ты не заметил, многое упирается в то, что вся конфиденциальность и
целостность завязана на использование хранимых процедур или функций. Получается,
что, получив к ним доступ и грамотно проанализировав их код, любой опытный хакер
сможет преобразовать шифрованную белиберду в исходный текст. Конечно, добраться
до кода процедур далеко не всегда реально, потому здесь всплывает вопрос об
утечке программной начинки производства, а именно – логике ПО. Но именно по этой
причине необходимо прибегать к шифрованию процедур и функций в базе. Одно из
самых популярных и удачных средств для таких действий – это программа SQL Shield
(www.sql-shield.com).
После несложной установки приложения не забудь указывать дополнительный флаг
/*sqlshield*/ с выражением «WITH ENCRYPTION» всякий раз, когда будешь создавать
защищенную процедуру. Вот пример функции, которая исполняет простейший запрос к
базе:
CREATE PROCEDURE MyTest
WITH /*sqlshield*/ ENCRYPTION
AS
SELECT 2+2
Исполняем процедуру и получаем:
Проверим, в каком виде хранится процедура, с помощью специального средства
для ковыряния в файлах базы. Подойдет SQL Server Syscomments Decryptor (www.geocities.com/d0mn4r/dSQLSRVD.html),
который при отображении текста процедуры показывает одни лишь знаки вопроса.
Все работает!
Как облегчить себе жизнь?
В заключение – не менее интересный продукт XP_CRYPT (www.xpcrypt.com).
Это средство осуществляет весь тот геморрой, который мы только что проделали
вручную. Все, что от тебя требуется, – скачать дистрибутив проги, установить ее
на сервер (к сожалению, есть версия только для Винды), обозначить свою базу
данных и начать химию с таблицами с помощью удобного GUI-интерфейса.
Напишем внешнюю функцию UDF (расшифровывается, как «User-Defined-Function»,
подробности) для преобразования строки в SHA-хеш:
CREATE FUNCTION ud_MakeSHA1 (@clearpass VARCHAR (8000) )
RETURNS VARCHAR (40)
AS
BEGIN
DECLARE @ret as VARCHAR(40)
EXEC master..xp_sha1 @clearpass,@ret OUTPUT
RETURN @ret
END
Отдаем команду: UPDATE tbl_CCards SET password = dbo.ud_MakeSHA1(Password).
После чего еще раз проверяем содержимое базы той же командой. Что видим? Все
зашифровано, все пароли захешировались!
Теперь нужно не забыть о том, что мы используем шифрование при обращении к
базе. В нашем случае, когда ты будешь делать авторизацию пользователей,
процедура проверки пароля по хешу будет выглядеть примерно так:
CREATE FUNCTION ud_CheckUser (@username VARCHAR(16),@clear_pass VARCHAR
(16))
RETURNS INTEGER
AS BEGIN
DECLARE @res INTEGER
SELECT @res = count(*) FROM tbl_CCards where username=@username AND
password=dbo.ud_MakeSHA1(@clear_pass)
IF @res > 1 SELECT @res= 0
RETURN @res
END
Проверяем исполнением команды:
SELECT dbo.ud_CheckUser (‘anna’,’kolbaska’)
>1 (неправильно)
SELECT dbo.ud_CheckUser (‘anna’,’love’)
>0 (окейно!)
К шифрованию номера кредитной карты надо подойти более серьезно. Впрочем, мы
не будем вникать в различного рода стандарты по информационной безопасности в
платежно-карточной сфере (вроде PCI; хотя организации, работающие с кредитными
картами, безусловно обязаны это делать). В бесплатной версии XP_CRYPT существует
возможность генерации только 256-битного ключа RSA. Вот этим и можно
воспользоваться (пусть упомянутый стандарт и требует, как минимум, 768-битного
ключа). Я бы мог сейчас привести код по генерации публичного и приватного ключа,
но… поступим проще. Все действия можно выполнить из понятного графического
интерфейса, и во многих случаях оставить все на совести программы, не написав ни
строчки кода. И поверь, будет работать!
Пример из личного опыта
Сотрудниками одной из компаний платежно-карточного сектора велась база данных
для выдачи зарплат. Для простого понимания, – пусть это будет примерно следующая
структура:
ID LastName FirstName Emp
Sum
354 Somov Oleg
IT-Manager M0x8900f56543
643 Antipova Alexandra Director
4343Lax#dsdsss
411 Timurov Valeriy Technical Dep.
0x2322322222
Выборку из базы я привел абсолютно произвольную, а теперь суть идеи.
«Безопасниками» компании было предпринято вполне благородное решение – шифровать
данные о зарплатах, которые очень часто бывают «серыми». Инсайдер получил доступ
к базе и сильно обломался, заимев информацию в таком виде. Однако, он не
отчаялся и проделал следующий фокус. Резонно предположив, что человек с
должностью директора должен получать больше, чем простой менеджер, он поменял
соответствующие поля со значениями зарплат одно на другое, тем самым – подложив
бухгалтерскому отделу абсолютно левую информацию. В благополучный день такая
вещь прокатила, и все безопасники были уволены. Для справки: этим сотрудником
был не я, как впрочем, и не безопасником.
Так делать не стоит
В SQL Server можно создавать четыре типа объектов (хранимые процедуры,
представления, пользовательские функции и триггеры) с параметром WITH
ENCRYPTION. Этот параметр позволяет зашифровать определение объекта таким
образом, что тот можно будет использовать, но получить его определение
стандартными способами станет невозможно. Это средство рекомендуется и
Microsoft. К сожалению, на практике никакой защиты применение стандартных
средств шифрования не обеспечивает! Алгоритм, используемый при шифровании
определений объектов, выглядит так:
У этой схемы есть два слабых места:
Как можно расшифровать зашифрованные объекты на SQL Server? Есть два
варианта: