Почему незашифрованные пароли плохо, и как я убеждаю своего босса, что его хранившие веб-сайты находятся под угрозой срыва?
Я когда-то работал с библиотекой C, которая была реализована способом, который показался мне довольно изящный. Они записали, в C, способ определить объекты, затем наследовались от них так, чтобы они были так же расширяемы как объект C++. Основная идея была этим:
- Каждый объект имел свои собственные Государственные функции файла
- , и переменные определяются в.h файле для объекта
- , Частные переменные и функции были только расположены в.c файле
- , Чтобы "наследоваться", новая структура создается с первым членом структуры, являющейся объектом наследоваться от
, Наследование трудно описать, но в основном это было это:
struct vehicle {
int power;
int weight;
}
Тогда в другом файле:
struct van {
struct vehicle base;
int cubic_size;
}
Тогда Вам мог создать фургон в памяти и быть используемым код, который только знал о механизмах:
struct van my_van;
struct vehicle *something = &my_van;
vehicle_function( something );
Это работало красиво, и.h файлы определили точно, что необходимо быть в состоянии сделать с каждым объектом.
8 ответов
В армии это называется «Глубокая защита». Теория состоит в том, что вы укрепляете каждый слой, который можете, вместо того, чтобы укреплять только один слой и надеяться, что этого достаточно.
Я слышал в таких базах данных, как ваша, называется «твердый снаружи, мягкий и вязкий внутри». Есть миллион способов, которыми преданный хакер может получить доступ к вашей базе данных. Социальная инженерия, недовольный сотрудник, бывший сотрудник, который решает проверить, работает ли его логин по-прежнему, или тот бэкдор, который он написал, все еще там, один пропущенный патч ОС ... список можно продолжать.
доступ с помощью любого из этих методов, вместо того, чтобы просто получать данные, он получает доступ к каждой комбинации имени пользователя и пароля для каждого пользователя вашей системы, и, как кто-то заметил, люди часто используют одну и ту же комбинацию для каждого веб-сайта.
Скажите ему, чтобы он подумал, что во многих компаниях проблемы безопасности исходят из внутри , а не извне. [ 1278] Теперь спросите его, как он собирается объяснять своим клиентам, как хакеры украли их пароли (которые, без сомнения, они использовали где-то еще), в следующий раз, когда ему по какой-то причине придется кого-то уволить.
Также спросите его, как он думает о своих клиентах. хотели бы знать, что их пароли видны всем, у кого есть доступ для чтения к базе данных.
Вот несколько причин:
- Кто-то может взломать ваш сайт. Это может быть маловероятно, и это, вероятно, не повлияет на вашего начальника (сейчас я слышу разговор: «Вы говорите, что сайт небезопасен?»). Но такое случается, и помните, никто никогда не думает, что их сайт честно говоря, будет взломан на ...
- Случайный просмотр базы данных инсайдерами (такими, как вы): возможно, вы не ПЫТАЕТЕСЬ посмотреть чьи-либо пароли, но в ходе обычной работы вам может потребоваться посмотреть через таблицу с паролями. Учитывая, что многие люди используют один и тот же пароль абсолютно для всего (включая, возможно, вашего начальника!), Вы бы не хотели, чтобы все эти пароли были раскрыты. Спросите своего босса, использовал ли он когда-либо пароль на двух разных сайтах
- . Если кто-нибудь когда-нибудь узнает, что ваше приложение не шифрует пароли, он может серьезно усомниться в доверии вашего приложения.
- Хеширование практически ничего не стоит. пароль (желательно с солью) в базу данных, так почему бы и нет?
Вы можете указать, что неспособность должным образом защитить учетные записи может подвергнуть компанию юридической ответственности, если информация будет когда-либо скомпрометирована. Игнорирование известной уязвимости может стоить вам судебных издержек, если данные пользователя были раскрыты в результате действий вашей компании (или бездействия, в зависимости от обстоятельств).
В США существуют определенные типы данных. , например финансовую и медицинскую информацию, которую компании юридически обязаны хранить в безопасности и конфиденциальности. Невыполнение этого требования может иметь серьезные последствия. Я не знаком с законами других стран в этом отношении, но это стоит изучить, если ваша компания имеет дело с такими данными.
Besides the security risks, I wonder what your clients would say if they found out every employee of your company has access to passwords. When it comes to possible leaks, the passwords are at risk if:
- the database is backed up by an external company
- the operating system that the db software is running on has any security risks
- security flaws in any other hardware or software firewall
- any users that have access to the db somehow get a virus that could exploit the data
- the db happens to be on a computer or laptop that is stolen
- a disgruntled employee is fired and decides to "get back"
every once in a while you'll hear of businesses that store sensitive information in plain text and it never ends well. we're all human and prone to error, you can't assume perfection when it comes to security. you won't find any large, profitable company leave room for any risk that can be avoided since anything bad that can happen, will happen...
Если «вручить вашим взломщикам список паролей на серебряном блюде» не является достаточно веской причиной, что является достаточно веской причиной?
Я видел два хороших ответа на этот вопрос:
Вы защищаете пароли от слежки сотрудников, то есть люди, имеющие законный доступ к базе данных, не могут легко украсть пароль, если они
Логический изъян приложения, такой как SQL-инъекция во внешнем интерфейсе веб-сайта, будет иметь меньше шансов привести к компрометации.
На мой взгляд, неплохо было бы зашифровать пароль базы данных. (хотя мне еще не удалось это сделать для большинства моих приложений), но гораздо важнее убедиться, что ваш сервер базы данных максимально надежен в отношении сети и авторизованного доступа. Если злоумышленник сможет проникнуть в вашу базу данных, то не имеет значения, как вы храните свои пароли, он сможет их взломать.
Слишком много случаев кражи баз данных с паролями в виде простого текста: если это может случиться с Reddit , то это может случиться и с вами.