Регистрация в системе Axapta

[SlavaK]

Здравствуйте!

Проставил месяц назад демо версию Axapta 3.0. Зарегистрировался под admin, пароль вводил вроде тоже admin. Точно не помню менял его где-то в системе или нет. Сейчас попытался заново поработать система не пускает. Пишет неправильный пароль. Попытался заново снести все три части Приложение/сервер/клиент и заново поставить. Ситуация та -же.

Подскажите, пожалуйста, как можно снести этот пароль? Может где-то в реестре подчистить?

Слава.

[Alex_K]

Можно попробовать вот это: http://www.axforum.info/forums/showt...=5212#post5212

[SlavaK]

Цитата:

Можно попробовать вот это: http://www.axforum.info/forums/showth...d=5212#post5212

Точно, спасибо огромное .

После перестановки Axapt-ы забыл проверить на пустой пароль. Сейчас в самом деле ничего не ввёл система пустила. А вообще дырка неплохая - зачем тогда шифровать пароль, если кто получил доступ к таблицы юзеров может свободно обнулить пароль и войти в систему?

[Alex_K]

Цитата:

Изначально опубликовано SlavaK

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

Вопрос повис в воздухе...

Вообще-то с подобными приколами и раньше встречался, но на столь дорогой системе - впервые...

[mazzy]

ну, пароли в Аксапте - это не единственное что надо сделать для обеспечения безопасности. Прежде всего пользователям надо запретить прямой доступ к средствам разработки на таблицы. Кроме того, надо и SQL настраивать и роли корректно раздавать.

[raz]

в 2.5 можно было дать разработку, но не дать пароли

[mazzy]

Главное меню \ Администрирование \ Управление пользователями \ Права доступа
Далее либо права пользователя, либо права группы (группа лучше)
Зайти в любые права (кроме админа)

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

Сейчас не проверил, поскольку она у меня на переиндексацию пошла. Но помню, что так делал.

[mazzy]

Проверил.
права на разработку дать надо.
а на словарь данных в пункте разработка - нет.

Если хочется дать пользователю права только на некоторые таблицы, то надо играться с правами на самом SQLе. Надо начать с того, что у всех объектов SQL'я сменить владельца на dbo...

[SlavaK]

Цитата:

ну, пароли в Аксапте - это не единственное что надо сделать для обеспечения безопасности. Прежде всего пользователям надо запретить прямой доступ к средствам разработки на таблицы. Кроме того, надо и SQL настраивать и роли корректно раздавать.

Ну от юзеров системы защитится это пол дела, я же имел ввиду защиту от несанкционированного доступа. С моей точки зрения должно быть 2 уровня защиты от несанкционированного входа в систему: 1-ый на уровне БД, и 2-ой на уровне системы. Так вот получается если БД взломают, то и в Axapt-у войти проблем не составит труда. Другими словами шифровка пароля в таблице userinfo, не обеспечивает нужной защиты, т.к. пароль любого пользователя можно свободно обнулить и зайти в систему под суперадминистратором.

[mazzy]

Это точно.

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

[SlavaK]

Цитата:

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

Ну так видимо разработчики Axapt-ы решили ещё и удобный интерфейс взломщикам предоставить, чтобы ещё проще было с данными разобраться .

А насчёт наглядности не совсем согласен - данные в таблицах всё таки в нормализованном виде лежат - нужен программист чтобы он все справочники с основными данными джойнил - время на разбирательство больше уйдёт. А при входе в ахапту может и специалист данные посмотреть.

[mazzy]

Цитата:

Изначально опубликовано SlavaK
Ну так видимо разработчики Axapt-ы решили ещё и удобный интерфейс взломщикам предоставить, чтобы ещё проще было с данными разобраться .

Конечно же не для взломщиков.
Конечно же для внешних построителей отчетов, для ОЛАПа и прочих внешних инструментов, которые работают с традиционной реляционной базой данных.

А база действительно нормализованная.
Нужен не программист. Достаточно Cristal Report'а если базой не заниматься.
Дык, ведь защита делается стандартными для базы средствами.

Кстати, SlavaK, а как бы вы организовали хранение? Каковы плюсы и минусы Вашего подхода?

[SlavaK]

Цитата:

Кстати, SlavaK, а как бы вы организовали хранение? Каковы плюсы и минусы Вашего подхода?

Хранения пароля в Аксапте я бы организовал бы следующим образом:
1. Не пускал бы в систему с пустым паролём - т.е. если пароль пустой, то Axapta должна была выдавать сообщение: "Не введён пароль". Тогда бы простым обнулением пароля в таблице userinfo вход в Axapt- у взломать было бы нельзя.
2. Для юзера admin по умолчанию поставил бы пароль - так в принципе для database администраторов все известные мне СУБД и делают, но пароль по умолчанию в зашифрованном виде для admin ни в коем случае не показывал бы, чтобы ни одного пароля в зашифрованном и расшифрованном виде не было известно всем админам Axapta. Другими словами первоначально пароль admin не хранил бы в userinfo, а хранил бы в зашифрованном файле (таблице БД) или ехе-шнике, с рекомендацией изменить пароль admin в первую очередь. После изменения пароля прописывал новый пароль для admin в таблицу userinfo, удалял бы зашифрованный файл (таблицу) и прописывал бы признак в БД или какой-нибудь файл, что теперь admin берёт пароль только из userinfo.

Преимущества:
1. С пустым паролём не один пользователь не войдёт
2. Под пользователем admin не зная пароля, который изменили сразу после установки Axapta можно войти только вскрыв систему шифрации пароля или найдя признак откуда берёт пароль admin (из userinfo или зашифрованого файла) и востановив зашифрованный файл(таблицу БД).

Недостатки:
1. Что делать когда пароль на admin забыли не понятно.
2. Сложнее реализовать, и нужно ли это? ( кто то может сказать что это параноя )

[mazzy]

Цитата:

Изначально опубликовано SlavaK
1. Не пускал бы в систему с пустым паролём - т.е. если пароль пустой, то Axapta должна была выдавать сообщение: "Не введён пароль". Тогда бы простым обнулением пароля в таблице userinfo вход в Axapt- у взломать было бы нельзя.

См. параметры пароля.
Там можно задать минимальную длину пароля.
Там же есть и другие параметры

Цитата:

Изначально опубликовано SlavaK
2. Для юзера admin по умолчанию поставил бы пароль ...

Что-то уж очень сложно.
Человек либо имеет доступ при помощи средств разработки к таблице userInfo, либо не имеет. Зачем городить огород то?

Если уж так хочется запретить admin'а, то можно удалить/отредактировать его права в таблице AccessRights. Правда после изменения лицензионных условий это придется делать заново.

[SlavaK]

Цитата:

См. параметры пароля. Там можно задать минимальную длину пароля.

Если такая возможность есть, то согласен мои замечания не обоснованы.
Просто очень мне не понравилось, что вход в AXapt-у под любым юзером можно получить с пустым паролём путём обнуления в userinfo. Установка в параметрах пароля минимальной длины, согласен, позволяет этого избежать.

Цитата:

Человек либо имеет доступ при помощи средств разработки к таблице userInfo, либо не имеет. Зачем городить огород то?

Если уж так хочется запретить admin'а, то можно удалить/отредактировать его права в таблице AccessRights

Вы не учли 2-е ситуации:
1. Человеку может никто и не собирается давать доступ на Axapt-у, а БД он должен админить. Соответсвено к userinfo он должен иметь доступ, а в Axapt-у нет.
2. При несанкционнированном доступе СУБД можно взломать, так зачем давать сразу доступ и в Axapt-у?

А добавить обратно права в таблице AccessRights не составит труда имея права dba на БД.

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

[Антон Солдатов]

Цитата:

Изначально опубликовано SlavaK


Установка в параметрах пароля минимальной длины, согласен, позволяет этого избежать

не позволяет - т.к. минимальная длина проверяется на уровне бизнес-логики(причем при входе в систему длина не проверяется), а не бд.
Никто не помешает Вам залогиниться, если у пользователя проставлен пустой пароль, даже если установлена минимальная длина > 0.

Цитата:

Изначально опубликовано SlavaK

2. При несанкционнированном доступе СУБД можно взломать, так зачем давать сразу доступ и в Axapt-у?

Это надуманная проблема.
Достаточно разрешить доступ к БД только с определенных ip. Например 127.0.0.1 и ip машины на которой установлен AOS.

[SlavaK]

Цитата:

Достаточно разрешить доступ к БД только с определенных ip. Например 127.0.0.1 и ip машины на которой установлен AOS.

Ну так если налоговая полиция заберёт сервер БД у неё уж точно доступ c localhost будет.

Я ведь сразу указал в недостатках моего предложения хранения пароля:
2. Сложнее реализовать, и нужно ли это? ( кто то может сказать что это параноя )

Но мой вопрос так и остался без ответа - для чего шифрования пароля - если оно обходится обнулением в таблице userinfo? (если прав Антон, то настройка параметров пароля ситуацию не спасает) Для того чтобы его явно в userinfo явно не видели и не обнуляя пароль не могли зайти?

[Антон Солдатов]

Цитата:

Изначально опубликовано SlavaK

Но мой вопрос так и остался без ответа - для чего шифрования пароля - если оно обходится обнулением в таблице userinfo? (если прав Антон, то настройка параметров пароля ситуацию не спасает) Для того чтобы его явно в userinfo явно не видели и не обнуляя пароль не могли зайти?

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

PS: imho дырка в алгоритме шифрования пароля. Можно было привязать процесс шифрования к имени пользователя, или дате регистрации - тогда бы 'пусто' у каждого было свое. Хотя конечно это все тоже обходится. Вопрос - игра свеч стоит?

[Vadik]

Цитата:

Ну так если налоговая полиция заберёт сервер БД у неё уж точно доступ c localhost будет

В этом случае никакое шифрование паролей Вам точно не нужно - Вы этим товарищам сами все расскажете и покажете в удобной для них форме, они специально этому обучены

Цитата:

кто то может сказать что это параноя

Вы сами напросились - да, это паранойя

Цитата:

Но мой вопрос так и остался без ответа - для чего шифрования пароля - если оно обходится обнулением в таблице userinfo?

Для того, чтобы его не было видно в select * from UserInfo. Запретите изменение таблицы тем, кому это не положено, и не будет у Вас кто попало пароли обнулять. Если же у Вас кто угодно может чем угодно к БД подключаться - какая разница, зашифрован пароль или нет - данные-то открыто лежат.

[SlavaK]

Цитата:

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

А если Вася сначала зашифрованный пароль скопирует, обнулит пароль, что надо в Axapt-а сделает, затем зашифрованный пароль обратно вставит? Сузим ли мы круг подозреваемых?

Цитата:

Вы сами напросились - да, это паранойя

Согласен паранойя - но довольно полезная. Дырок зато в системе остаётся меньше если руководствоваться такой паранойей, а там глядишь и в самом деле преследовать начнут .

Цитата:

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

Ну уж если мы руководствуемся параноей при организации входа в систему, то уж наверно и БД стараемся блюсти. Но способов сломать СУБД и без "пыток" налоговой инспекцией итак много и я считаю что не надо всю безопасность валить на средства СУБД. Особенно если СУБД часто валит её на средства операционки (MS SQL аутентификация пользователя Операционной Системы).
А насчёт открытых данных в таблицах - почему никто не изучает Axapt-у по содержимому таблиц, а делает это войдя в систему? Наверно всё таки проще и деятельность организации через систему смотреть, чем рыться в таблицах?