|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
Добрый день. У пользователей некой базы есть потребность сохранять и потом пользоваться логинами/паролями от разных корпоративных ресурсов (b2b поставщиков). Как можно безопасно их хранить и предоставлять только нужным пользователям? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2020, 15:18 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
База данных на MS SQL, интерфейс - на Access. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2020, 15:19 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2020, 15:22 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
drgdr, существуют приложения, которые позволяют хранить пароли в зашифрованном виде и шифровать их мастер-паролем. Лучше использовать специальный софт, чем городить самопал непонятного качества. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2020, 15:53 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
Пароли вообще никак нельзя хранить. Хранить можно хэши этих паролей, а лучше - хэши результата PBKDF2. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2020, 19:02 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
Сон Веры Павловны Пароли вообще никак нельзя хранить. Хранить можно хэши этих паролей, а лучше - хэши результата PBKDF2. Ну, не надо перегибать палку. Хранить можно все, пароли не исключение. Да и хэш пароль не заменит. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 15:33 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
Владислав Колосов drgdr, существуют приложения, которые позволяют хранить пароли в зашифрованном виде и шифровать их мастер-паролем. Лучше использовать специальный софт, чем городить самопал непонятного качества. Ты не поверишь! MS SQL именно такое приложение. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 15:34 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
env Например, шифроватьУ этого способа один недостаток - админ все видит. Always Encrypted зашифрует от админа ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2020, 15:48 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
aleks222 Сон Веры Павловны Пароли вообще никак нельзя хранить. Хранить можно хэши этих паролей, а лучше - хэши результата PBKDF2. Ну, не надо перегибать палку. Хранить можно все, пароли не исключение. Да и хэш пароль не заменит. не прав. однозначно, кто утверждает что хранение паролей с любом виде даже зашифрованном - вызывает ассоциасию что он давно не получал ссаной тряпкой по лицу. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 01:14 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
drgdr, Рекомендую освежить в памяти историю с Ashley Madison, прежде чем браться за такое задание. Поучительно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 07:26 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
drgdr Добрый день. У пользователей некой базы есть потребность сохранять и потом пользоваться логинами/паролями от разных корпоративных ресурсов (b2b поставщиков). Как можно безопасно их хранить и предоставлять только нужным пользователям? Из описания - пользователи хотят сохранить пароль, а потом его вспомнить, а-ля браузер? Для этих целей существуют коммерческие прлграммы, например Citrix Password Manager. Если вы хотите делать свой, и защищать его хорошо, вам предстоит стать экспертом в области компьютерной безопасности, чтобы хотя бы сформулировать проблемы, которые вам предстоит решить. Ну например, только на клиенте: - как обезопаситься от ненамеренно попадания пароля в dump, когда ПК попадает на блюскрин - как не допустить попадания пароля в pagefile, даже временно - как прятать пароль в памяти от хакера в условиях виртуализации - как не отдать пароль вирусу который внёс себя в адресное пространство клиента. Это даже не затрагивает передачу и хранение данных на сервере (что во многих смыслах легче, т.к. контроль конфигурации и физического доступа крепче). Но и там: - как не допустить утечку всей базы паролей одним недовольным сисадмином - как исполнить требование суда о передаче паролей пользователя - при этом не раскрывая пароли других После этого система хранения такой ценной информации потребует проверок и продолжающегося надзора. Возможно, сертификаций для допуска к определенным контакторам, и/или для снижения юридической нагрузки. Несомненно - учебных материалов для образования пользователей. Проработав в этой сфере много лет, я отношусь к таким данным как к обогащенному плутонию - если это не является моей основной задачей - спихнуть на готовое сертифицированное (EAL-х?) решение. Если является - то соразмерный бюджет и команда. Кто будет/сможет решать проблему когда пароли сотен людей всплыли на DMs, а ты только выбрался на Ямайку и наслаждаешься погодой? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 07:56 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
НеофитSQL drgdr Добрый день. У пользователей некой базы есть потребность сохранять и потом пользоваться логинами/паролями от разных корпоративных ресурсов (b2b поставщиков). Как можно безопасно их хранить и предоставлять только нужным пользователям? Из описания - пользователи хотят сохранить пароль, а потом его вспомнить, а-ля браузер? Для этих целей существуют коммерческие прлграммы, например Citrix Password Manager. Если вы хотите делать свой, и защищать его хорошо, вам предстоит стать экспертом в области компьютерной безопасности, чтобы хотя бы сформулировать проблемы, которые вам предстоит решить. Ну например, только на клиенте: - как обезопаситься от ненамеренно попадания пароля в dump, когда ПК попадает на блюскрин - как не допустить попадания пароля в pagefile, даже временно - как прятать пароль в памяти от хакера в условиях виртуализации - как не отдать пароль вирусу который внёс себя в адресное пространство клиента. Это даже не затрагивает передачу и хранение данных на сервере (что во многих смыслах легче, т.к. контроль конфигурации и физического доступа крепче). Но и там: - как не допустить утечку всей базы паролей одним недовольным сисадмином - как исполнить требование суда о передаче паролей пользователя - при этом не раскрывая пароли других После этого система хранения такой ценной информации потребует проверок и продолжающегося надзора. Возможно, сертификаций для допуска к определенным контакторам, и/или для снижения юридической нагрузки. Несомненно - учебных материалов для образования пользователей. Проработав в этой сфере много лет, я отношусь к таким данным как к обогащенному плутонию - если это не является моей основной задачей - спихнуть на готовое сертифицированное (EAL-х?) решение. Если является - то соразмерный бюджет и команда. Кто будет/сможет решать проблему когда пароли сотен людей всплыли на DMs, а ты только выбрался на Ямайку и наслаждаешься погодой? Ну что ты несешь пургу? Фсе твои проблемы решаются шифрованием/дешифрованием пароля на клиенте по мастер-паролю пользователя. Но учитывая "от разных корпоративных ресурсов (b2b поставщиков)" - это не личные пароли, а служебные. Т.е. работодатель имеет право доступа к ним => достаточно шифрования на сервере. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 11:44 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
Для паролей заводится корпоративный аккаунт к примеру на Last Pass, и пароли шарятся между теми, кто имеет к ним доступ. Самим не надо хранить ни пароли, ни их хэши ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 23:31 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
Поскольку речь идет о логинах/паролях сторонних ресурсов, то хранить их так или иначе надо, и хеш тут не подойдет. Я бы хранил это в зашифрованном виде, но ключ при этом должен быть только у самого пользователя. Пользователь логинится в приложение, передает ему ключ, и приложение дешифрует этим ключом нужные логины/пароли. Т.е. в приложении хранятся только прароли, но не хранится ключ для них, т.е. без ведома пользователя-владельца пароля никто его все равно расшифровать не может. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2020, 23:58 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
drgdr, Наиболее точным с моей точки зрения ответом на Ваш вопрос "Как можно безопасно их хранить и предоставлять только нужным пользователям?" будет: хранить в таблице в виде столбца varbinary(max), при соглашении что все средства шифрования/дешифрования обеспечиваются внешиними СКЗИ по отношению к серверу. (он выступает только в качестве хранилища данных) доступ к получению данных из таблицы хранения можно косвенно ограничить "точками входа" в виде хранимых процедур, но это не является основной гарантией защиты данных, оснавная часть ложится на то что клиент должен шифровать исходный пароль на основе криптостойкого алгоритма + ключ к дешифровке должен быть доступен только со стороны клиента. Вы не должны рассматривать ситуацию когда возможен сценаций вида: Код: sql 1. 2. 3. 4.
единственно возможный вариант когда клиент запрашивает информацию: Код: sql 1. 2. 3.
а уже на клиенте @pwd (varbinary) дополнительно десериализуется и дешифруется на стороне клиента ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 02:51 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
fkthat Поскольку речь идет о логинах/паролях сторонних ресурсов, то хранить их так или иначе надо, и хеш тут не подойдет. Вопрос, зачем это делать централизованно. Пусть об этом голова болит у конечного пользователя, и пусть он хранит пароли в соответствии со своими навыками, и степенью осознания рисков - от стикеров на мониторе, до того же бесплатного, но вполне надежного KeePass (шифрование базы по AES-256, key derivation посредством AES-KDF или Argon2 - вряд ли самопал будет лучше). И всех тех проблем, о которых было написано выше , не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 07:54 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
Сон Веры Павловны Вопрос, зачем это делать централизованно. Пусть об этом голова болит у конечного пользователя, и пусть он хранит пароли в соответствии со своими навыками, и степенью осознания рисков - от стикеров на мониторе, до того же бесплатного, но вполне надежного KeePass (шифрование базы по AES-256, key derivation посредством AES-KDF или Argon2 - вряд ли самопал будет лучше). И всех тех проблем, о которых было написано выше , не будет. Да, это верно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.11.2020, 10:37 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
aleks222 Фсе твои проблемы решаются шифрованием/дешифрованием пароля на клиенте по мастер-паролю пользователя. Но учитывая "от разных корпоративных ресурсов (b2b поставщиков)" - это не личные пароли, а служебные. Т.е. работодатель имеет право доступа к ним => достаточно шифрования на сервере. Вот наглядный пример, почему управлением паролями должны заниматься квалифицированные специалисты, а не "Фсе твои проблемы решаются шифрованием". Вы подумали про защититу служебный паролей от работодателя (серьезно??), но не подумали про защиту от трояна/вируса. Или от кражи служебного ноута. Или от атаки посредника RDP сессии. Или... вряд ли есть толк все перечислять для того, кто "Фсе твои проблемы решаются шифрованием". ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 03:51 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
НеофитSQL aleks222 Фсе твои проблемы решаются шифрованием/дешифрованием пароля на клиенте по мастер-паролю пользователя. Но учитывая "от разных корпоративных ресурсов (b2b поставщиков)" - это не личные пароли, а служебные. Т.е. работодатель имеет право доступа к ним => достаточно шифрования на сервере. Вот наглядный пример, почему управлением паролями должны заниматься квалифицированные специалисты, а не "Фсе твои проблемы решаются шифрованием". Вы подумали про защититу служебный паролей от работодателя (серьезно??), но не подумали про защиту от трояна/вируса. Или от кражи служебного ноута. Или от атаки посредника RDP сессии. Или... вряд ли есть толк все перечислять для того, кто "Фсе твои проблемы решаются шифрованием". Дарагой параноик, прежде чем думать о защите "от трояна/вируса" надо бы подумать о защите паролей от самого пользователя. Иначе пользователь может, ненароком, узнать свои пароли. Это же ужасно! И недопустимо. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 06:04 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
aleks222, Я надеюсь, вы начали понимать сложность задачи. Кстати, есть немало пакетов, которые действительно осуществляют защиту паролей от пользователей. Это не тот сценарий что мы обсуждаем, но ваш пример неудачен. Есть такая ниша. А "параноик" в моей предыдущей работе был комплимент. Я занимался проектированием систем компьютерной безопасности и их сертификацией. Первое интересно, второе нужно, но необходимо, особенно когда РФ перешла на свои "GOST". ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 08:33 |
|
Хранение логинов/паролей пользователей от разных ресурсов
|
|||
---|---|---|---|
#18+
НеофитSQL aleks222, Я надеюсь, вы начали понимать сложность задачи. Кстати, есть немало пакетов, которые действительно осуществляют защиту паролей от пользователей. Это не тот сценарий что мы обсуждаем, но ваш пример неудачен. Есть такая ниша. А "параноик" в моей предыдущей работе был комплимент. Я занимался проектированием систем компьютерной безопасности и их сертификацией. Первое интересно, второе нужно, но необходимо, особенно когда РФ перешла на свои "GOST". Я уже давно понял, что вы, болезный, ничем полезным не занимались. Кроме надувания щек. Прекращайте пороть чушь. Ей больно. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 14:50 |
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1685453]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
63ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 187ms |
0 / 0 |