Безопасность, когда исходный код общедоступен

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

В свободное время я потихоньку создаю приложение, которое, надеюсь, будет полезно на работе. Это простое приложение для отслеживания результатов рецензирования. По сути, я просто пытаюсь научить себя C#.

Моя проблема в том, что, поскольку я действительно не могу ничего установить, и я не могу использовать свой собственный веб-сайт для этого (две причины - 1) Министерство обороны, вероятно, не разрешит это, 2) я хочу, чтобы это был рабочий стол (WinForms ), а не Web), я использую Jet (например, Access) в качестве хранилища данных.

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

Моя проблема в том, что я хочу, чтобы этот код был несколько общедоступным. В конечном итоге я хочу опубликовать свой код на своем веб-сайте и попросить StackOverflow и, возможно, сабреддит по программированию для некоторых быстрых обзоров и идей. Думайте об этом как о программе наставничества для бедных. Для обслуживания, особенно после того, как я уйду с этой работы, исходный код в конечном итоге будет доступен моим коллегам. Если у них есть доступ к зашифрованному «ключевому файлу» и источнику, они смогут определить пароль базы данных.

Есть ли способ закодировать это так, чтобы даже с файлом и кодом мои коллеги не смогли попасть в БД? Я предполагаю, что нет, но стоит кое-что спросить.

Если нет способа сделать это, я думаю, что мой второй вариант — изменить шифрование, когда я размещаю его на своем сайте (изменить шифрование, эквивалентное хэшу — IV? — на что-то другое при публикации), и предоставить источник в защищенный паролем rar-файл, давая пароль только управлению.

Любые идеи?


person AgentConundrum    schedule 07.07.2009    source источник


Ответы (2)


Не существует "Безопасность через неизвестность". Если вы всегда считаете весь код общедоступным, у вас больше шансов реализовать что-то действительно безопасное. Если вы «спрячете» код или «спрячете» пароли, вы совершили ужасную ошибку.

Вот как взломать пароль на Jet. http://lastbit.com/access/

Безопасность — это глубокая проблема. Вы не можете кинуть пароль в файл. Можно кидать хеши паролей в файлы.

У вас есть два взаимодополняющих вопроса.

  • Аутентификация. Кто пользователь? Вот что могут сказать вам пароли и кодовые фразы: Кто подключается.

  • Авторизация. Что может сделать этот пользователь? Вот почему у вас есть разделение обязанностей. Сотрудники службы безопасности, которые устанавливают пароли, и пользователи, которые должны предоставлять пароли и иметь доступ к данным, должны быть отдельными людьми.


Изменить

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

«Есть ли способ закодировать это так, чтобы даже с файлом и кодом мои коллеги не смогли попасть в БД?» Да. Это просто. Используйте хэши паролей, а не зашифрованные пароли.

"предоставление пароля только руководству" Неправильно. Если вы дадите пароль кому-то, то слишком много людей узнают пароль. Это нарушает аутентификацию. Люди должны устанавливать свои собственные пароли, иначе они не будут аутентифицированы.


Изменить

Что делать?

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

    Вы не упоминаете действительно важные вещи в своем вопросе. Например, вы не упоминаете, есть ли у вас несколько пользователей. Вы просто упоминаете конкретную технологию (JET) и конкретный метод (пароль уровня БД). Вы не упоминаете, используют ли эти пользователи общую базу данных.

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

    Если у вас нет общей базы данных — если у каждого пользователя есть частная база данных — тогда у вас есть отдельные установки, где обычная безопасность Windows подходит. Зачем что-то скрывать?

  2. Выберите архитектуру.

    • У вас есть ActiveDirectory. Это дает вам имена пользователей и надежно хешированные пароли. Используйте это.

    • SQL/Server может использовать AD для аутентификации и авторизации пользователей. Это достаточно безопасно, если люди не делятся своими паролями.

  3. Создайте что-то, что работает.

    • группы объявлений.

    • Центральная БД в SQL/Server.

    • Административные процедуры для создания пользователей, сброса паролей, перемещения пользователей из группы в группу и т. д. Это несложно. Это в документации AD. Любой системный администратор Windows может подсказать, как это сделать. Документируйте процедуры. Они являются частью модели безопасности.

    • Приложение Winforms, которое можно установить на настольные компьютеры. Пользователи будут использовать свои существующие учетные данные Windows. Вход в Windows означает, что ваше приложение winforms может регистрировать их в базе данных, и они исчезают. Надежно.

    • MSI для настольного компонента. Поскольку нет «мастер-пароля базы данных» или другого мусора, они просто устанавливают простое приложение. Они настраивают расположение центрального сервера БД. Они входят в систему со своими существующими учетными данными Windows.

person S.Lott    schedule 07.07.2009
comment
Это был скорее образовательный вопрос, чем что-либо еще. Для чего я это делаю, если кто-то хочет в базу данных достаточно сильно, чтобы взломать пароль доступа или копаться в моем коде, тогда они могут это сделать. Единственное, что это действительно гарантирует, — это то, что руководитель группы будет выбирать, кто может выполнять определенные типы проверок. Внутренний инструмент, который мы используем для фактического заполнения обзоров (у нас есть контрольный список, в дополнение к собственному здравому смыслу рецензентов), позволяет любому сделать обзор для кого-либо еще. Прямо сейчас люди спамят команду в поисках отзывов, так что проще там ничего не контролировать. - person AgentConundrum; 07.07.2009
comment
(продолжение) Это просто для того, чтобы сделать вещи более удобными для пользователя и т. д. На самом деле это просто любимый проект для учебных целей. Спасибо за ответ, вы только что подтвердили то, что я уже знал. :) - person AgentConundrum; 07.07.2009
comment
Я не уверен, что здесь делать, так как я действительно смотрел только на использование пароля уровня db. Должен ли я просто сохранить источник в секрете, по крайней мере, для пароля базы данных? Должен ли я иметь пароль уровня приложения (возможно, каким-то образом автоматизированный), который хешируется для получения реального пароля и использует его для доступа к БД. Я бы хотел использовать для этого что-то еще, поскольку Access/Jet кажется кошмаром для безопасности, но сочетание среды и моих собственных (текущих) знаний делает этот вариант для меня менее чем жизнеспособным на данный момент. Извините, если это звучит как нуб, я просто хочу научиться. - person AgentConundrum; 07.07.2009
comment
Вы не можете держать источник в тайне — он просто не работает — его всегда можно подвергнуть обратному проектированию. Вы не можете использовать простой пароль БД — на самом деле он не работает. Встроенная защита JET не работает. - person S.Lott; 07.07.2009

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

Самый безопасный вариант с доступом — хранить файл на сервере с хорошей настройкой разрешений общего доступа к файлам и использовать ODBC для доступа к нему. - Однако на самом деле это не решает вашу проблему с распространением.

Почему бы не взглянуть на некоторые альтернативы там? SQL Compact более безопасен и обеспечивает очень похожий опыт программирования. Если вы можете позволить себе немного «тяжелее», SQL Express превосходен. Есть также много хороших предложений с открытым исходным кодом. Здесь вам может подойти Firebird.

Надеюсь это поможет..

Редактировать: S.lott здесь на высоте. В конечном счете, если люди имеют доступ к вашему коду и вашей базе данных и знают, что с ними делать, они смогут войти.

person Daniel M    schedule 07.07.2009
comment
Если вы можете использовать вариант SQL Express, он обеспечит хороший контроль над тем, какие пользователи могут видеть какие данные. Просто держите пароль sa при себе; если вы пойдете дальше, вы можете оставить пароль своему преемнику, чтобы он мог продолжать контролировать базу данных. - person Rhys Jones; 07.07.2009
comment
Когда я установил SQL Server Compact, у него было необходимое условие для IIS. Я действительно не смотрел дальше этого. Есть ли базовое изложение того, как это работает? - person AgentConundrum; 07.07.2009