Зачем вообще хранить пароли пользователей?

Я иногда вижу вопросы о том, как безопасно хранить пароли пользователей для веб-приложения (используя RDBMS, я не говорю о Facebook или Twitter). Обычный ответ - «солить пароль, а затем использовать его с сильным алгоритмом, таким как TDES или SHA512».

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

Например, если какой-либо пользователь X хочет создать пароль пользователя учетной записи Y Y в моем веб-приложении, как неправильно издает следующий запрос:

CREATE USER X WITH ENCRYPTED PASSWORD Y IN GROUP baseuser;

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

Я вижу несколько преимуществ этого метода:

  • Если РСУБД решает, что алгоритм шифрования необходимо изменить, мне не нужно ничего касаться, просто чтобы применить обновления безопасности;
  • Мне легко управлять авторизациями пользователей. Если пользователь получает роль администратора, я просто должен добавить пользователя в соответствующую группу,
  • В настоящее время SQL-инъекции бессмысленны, поскольку я управляю разрешениями, позволяя точно, что я хочу разрешить каждому пользователю в базе данных (например, на форуме вроде SO, добавлении новых сообщений, ответе на сообщения, комментировании и редактировании /удалении его собственные вопросы /ответы /комментарии);
  • Учетная запись пользователя «анонимный» может использоваться для неавторизованных подключений к моему приложению;
  • Каждый пользователь является владельцем данных, которые он предоставил.

Но практически по каждому вопросу, который я вижу по этой теме, похоже, существует общее мнение о том, что это не так, как нужно делать. Мой вопрос: почему?

Примечание. Третий пункт разрешен политиками в PostgreSQL и политики безопасности в Microsoft SQL Server. Я понимаю, что эти концепции новички, но в любом случае, теперь, когда они здесь, почему технику, которую я описываю, не является стандартным способом обработки учетных записей пользователей?

10 голосов | спросил Fabian Pijcke 11 Maypm17 2017, 17:29:27

5 ответов


27

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

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

В очень реальном смысле это разница в философии между разработчиками приложений и разработчиками баз данных /администраторами баз данных.

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

В некоторых случаях это может быть близоруким; у многих RDBMS есть потрясающие функции, которые могут значительно улучшить жизнь приложений dev (безопасность на уровне строк, столбчатые индексы, хранилище для хранения и т. д.).

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

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

ответил BradC 11 Maypm17 2017, 17:37:19
8

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

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

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

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

ответил David Spillett 11 Maypm17 2017, 17:54:39
6

Повторение вопроса

  

Зачем вообще хранить пароли пользователей?

Самый простой ответ - вы должны это сделать. Вы по-прежнему сохраняете пароли в своем альтернативном методе. Просто вы используете встроенную систему базы данных для управления хранилищем. Таким образом, ваш метод так же хорош, как и ваши базы данных. Это все равно может быть лучше, чем вы могли бы сделать иначе, но это не позволяет избежать хранения. Это действительно просто избегает хранения кодирования.

Это также может быть не лучше. Если я нарушаю базу данных и получаю копии файлов, я могу напрямую обращаться к таблицам. Поэтому нет смысла использовать блестящую систему управления паролями. Поскольку, если кто-то может получить доступ к таблице уровня системы, содержащей пароли или хэшированные пароли, они также могут напрямую обращаться к файлам. Зачем пытаться взломать пароли, когда у вас уже есть данные? Не похоже, что вы можете легко шифровать данные. Каждый пользователь должен иметь доступ к нему. Таким образом, шифрование на уровне пользователя не будет работать так хорошо.

Но то, что вы действительно спрашиваете, это

  

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

Безопасность

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

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

В слоях защитного лука обычная система:

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

В этой системе:

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

Мы потеряли весь уровень безопасности приложений. И мы добровольно отказались от части слоя базы данных. Поэтому нам нужны только два эксплойта:

  1. Обманывать или компрометировать авторизованный сервер.
  2. Увеличьте доступ к учетной записи с ограниченными правами.

Если мы сможем сделать эти две вещи, у нас есть доступ к базе данных. Таким образом, мы переходим от трех слоев до двух. (Третий уровень в нормальной системе - это то, что вам нужен действительный пользователь для подключения к базе данных.)

Вы будете много управлять этими аккаунтами. Что делать, если вы допустили ошибку? Вместо того, чтобы ограничивать пользователя X только определенными строками, вы предоставляете им доступ к критической таблице. Такие вещи обычно выполняются вручную, и их лишь несколько, поэтому их легко проверить. Но в вашей системе вы можете делать тысячи или миллионы или даже миллиарды учетных записей пользователей, каждый со своим индивидуальным доступом.

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

ответил mdfst13 12 Mayam17 2017, 06:14:32
5

То, что вы описываете, будет обрабатывать аутентификацию, но не авторизацию (какие данные пользователь может получить) или только в самом простом случае использования.

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

Вам также понадобится таблица для хранения информации о пользователе: пользователь не просто имя пользователя + пароль. У него есть электронная почта, репутация и так далее. Таким образом, вам по-прежнему нужна таблица пользователей, которую вы должны обеспечить, синхронизируется с таблицей пользователей базы данных, если вы можете получить к ней доступ.

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

Другой вопрос: как создать пул соединений? Я знаю только jdbc (java <- gt; db), и вам нужно указать имя пользователя + пароль, чтобы получить соединение, которое затем можно объединить.

Я подумал о некоторых других моментах, которые будут сложнее /сложнее реализовать, чем установленным способом:

  • обработка восстановления пароля
  • Через 2 года после первоначальной реализации менеджер по продуктам попросит вас добавить поддержку для oauth-схемы или разрешить double factor auth
ответил Thierry 12 Mayam17 2017, 00:50:51
1

Еще один момент: многие [1] веб-приложения позволяют вам регистрироваться и создавать учетную запись пользователя в режиме онлайн через приложение. Это означает, что ваш анонимный пользователь (который должен иметь наименьшие привилегии, который можно было бы предположить) должен обладать правами на создание пользователей и предоставление привилегий!

ОК, возможно ограничить, какие привилегии он может предоставить, и предоставить пользователям более высокого уровня дополнительные параметры гранта (я не знаю, что это хотя бы - это не «привилегии предоставления», а одна привилегия). Но тем не менее, это означает, что нужно что-то с привилегиями гранта в режиме онлайн для всех, чтобы взломать. Я почти уверен, что мой DBA не понравится, если я это сделаю:)

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

Кроме того, это предотвратит любое использование объединенных или повторно используемых соединений DB.

[1] Большинство, я бы сказал, но не цифры, чтобы поддержать его

ответил Adam 12 Maypm17 2017, 15:54:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132