• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

еще раз об Id

  • Автор темы phantom76
  • Дата начала
P

phantom76

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

collection

<!--QuoteBegin-phantom76+9:08:2007, 07:58 -->
<span class="vbquote">(phantom76 @ 9:08:2007, 07:58 )</span><!--QuoteEBegin-->есть ли способ сгенеривать новый id
[snapback]74819" rel="nofollow" target="_blank[/snapback]​
[/quote]
равнозначный потерянному без использования опции восстановления нельзя
<!--QuoteBegin-phantom76+9:08:2007, 07:58 -->
<span class="vbquote">(phantom76 @ 9:08:2007, 07:58 )</span><!--QuoteEBegin-->правильно я все понимаю
[snapback]74819" rel="nofollow" target="_blank[/snapback]​
[/quote]
все зависит от того привильно ли Вы понимаете где включать проверку паролей :)
 
P

phantom76

в основном конфигурационном документе на сервере...
 
30.05.2006
1 345
12
BIT
0
еще вопросик: если всех юзеров прошу сменить пароли, id со старыми паролями перестают действовать, при условии , что включена проверка паролей - правильно я все понимаю?
Не правильно.
1.Пароль меняется "У-НУТРЕ" конкретного id-шника (т.е. другие пароли к нему уже не подходят)
2.На сервер с включенной проверкой теперь пускают только владельца этого подновленного id-шника
НО:
id cо старыми паролями продолжают действовать там, где пароль не проверяется:
3.На других серверах/доменах (эта проверка м.б. и выключена)
4.На клиенте (в локале)

Т.е. смена пароля не помешает злоумышленнику (предварительно укравшему ваш id) подделать док-т с вашей подписью, расшифровать вашу базу

Вывод: при компроментации ключей надо менять ЭТИ КЛЮЧИ, а не пароль к ним
 
P

phantom76

а чего не так? пункты 1 и 2 ,я так и понимал...

3.4. - тоже мне были ясны... было сомнение, о том что отваляться ли старые id

про ключи согласен... самый надежный способ.

спасибо!
 
30.05.2006
1 345
12
BIT
0
Ради НО и написАл уточнение. У тебя было "старые копии не действуют, если на сервере ...". А сервера-то может и не быть (в нужный момент)!
 
P

phantom76

окей, как в таком случае будет работать "защита" на локале?
с чем будут сравниваться ключи id-шки ?
насколько я знаю, в случае даже если БД перетянули на локал, даже если стоит опция Enforce ACL, если конечно база не зашифрована.
все равно можно, при условии, что знаешь точное имя управляющего БД, создать аналогичного пользователи и получить доступ к данным к локальной копии.
во всяком случае в 5-ке это прокатывало.
 
C

collection

к слову, не помешает:
To prevent users whose access levels are Depositor or No Access from using the operating system to copy the database, encrypt the database with the server ID through the local Encryption option. This ensures that the database, even when copied, is illegible to anyone who doesn't have access to the server I
<!--QuoteBegin-phantom76+9:08:2007, 15:23 -->
<span class="vbquote">(phantom76 @ 9:08:2007, 15:23 )</span><!--QuoteEBegin-->как в таком случае будет работать "защита" на локале
[snapback]74915" rel="nofollow" target="_blank[/snapback]​
[/quote]
-снимем шифрование
-меняем ключи
-устанавливаем шифрование
 
30.05.2006
1 345
12
BIT
0
окей, как в таком случае будет работать "защита" на локале?
с чем будут сравниваться ключи id-шки ?
насколько я знаю, в случае даже если БД перетянули на локал, даже если стоит опция Enforce ACL, если
все равно можно, при условии, что знаешь точное имя управляющего БД, создать аналогичного пользователи и получить доступ к данным к локальной копии.
Все так. id-шки ни с кем не сравниваются. По определению: при наличии ФИЗИЧЕСКОГО доступа к базе (мимо сервера) защита по ACL бессмысленна и потому отключается (Consist.ACL - отладочный бантик).
конечно база не зашифрована.
Вот именно! Я о том и талдычу. Зашифрованную базу хрен откроешь, если предварительно не украл id-шник. Но к краденому id подойдет старый пароль
 
P

phantom76

проделайте батенька эксперимент:
- скопируйте любую базу на локал с сервера, удалите себя с ACL,
далее: - управление ACL, - закладка дополительно - установливаем опцию - enforce ....... ACL.

закройте базу, а потом попробуйте получить контроль над ней? в 5-ке да можно было открыть любую базу, а в 7-ке не получиться... попробуйте и расскажите, что получилось.
 

puks

Lotus Team
03.02.2007
1 919
55
BIT
3
<!--QuoteBegin-phantom76+10:08:2007, 11:05 -->
<span class="vbquote">(phantom76 @ 10:08:2007, 11:05 )</span><!--QuoteEBegin-->закройте базу, а потом попробуйте получить контроль над ней? в 5-ке да можно было открыть любую базу, а в 7-ке не получиться... попробуйте и расскажите, что получилось.
[snapback]75055" rel="nofollow" target="_blank[/snapback]​
[/quote]

А если ее потом на любой сервер и под Full Admin? ;)
 
K

Kee_Keekkenen

Для: phantom76
к тому же на локале включить менеджеские права на нешифрованной бд (на шифрованной не пробовал), даже если вообще никаких прав на базу не имеешь, раз плюнуть..
 
P

phantom76

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

на текущий момент - хранилище бд mail-in + сеть
на клиентах - локал, стоит ли уносить их на сетевой диск?
как лучше хранить администраторские id и cert ?
 

puks

Lotus Team
03.02.2007
1 919
55
BIT
3
Я не сохраняю в адресной книге (но это зависит от конфигурации). Есть копии на диске, архиве, болванках и тп. Кроме того, если используешь восстановление, то они есть еще и в базе, которая шифрована, как и любая база имеет права доступа. Особенно внимательно к хранению cert.id, ou и серверных. Конфигурации с работой с сеткой мне не нравятся, так как очень чувствительны к сети и не поддерживаются IBM. Но все это дело вкуса. За все время работы никто у меня не жаловался на хищение id.
 
C

collection

храню id пользователей на сетевом диске,потоиу как вопрос безопастности в организации так остро не стоит, а вот восстанавливать, менять пароли, обеспечивать доступ нескольких пользователей под одним id без использвания механизма rouming users очень удобно ;)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!