шифрование паролей

[alexbn]

Может кто подскажет:

Какой алгоритм применён для шифрования паролей пользователей системы Axapta?

Это те которые в UserInfo.
Нужен сам алгоритм (его название - md5 или что-нить подобное).

Отвечать dictionary.buildpassword(user,pass) не нужно.
Дешифровать нельзя однозначно - иначе системе место в унитазе, поэтому - плиз... ссылку на прес-релиз или что-нить подобное, или никого не интересует криптостойкость Аксапты?

[andreynikolai]

Программный код шифрования тебе никто не предоставит,
да и в системе он недоступен.

Если ты имеешь ввиду математическую сущность алгоритма, то его знают наверно
только люди имеющие отношение к созданию системы.

[raz]

Цитата:

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

Какая разница, какая там криптостойкость в шифровании пароля, если сами данные не шифрованы, а восстановить утраченный пароль Adminа нет проблем.
ИМХО данный алгоритм может интересовать только при желании сгенерировать лицензионные ключи, т.к. они очень напоминают шифрованный пароль

[alexbn]

Цитата:

Изначально опубликовано andreynikolai
Программный код шифрования тебе никто не предоставит,
да и в системе он недоступен.

Если ты имеешь ввиду математическую сущность алгоритма, то его знают наверно
только люди имеющие отношение к созданию системы.

Смысл не в матиматической сущности алгоритма.
А в стандарте.
Допустим след. ситуацию:
Надо проинтегрировать пользователей системы Аксапта с произв. приложением.
Условие:
1. Логины пользователей в этих системаю должны быть одинаковыми
2. Пароли в этих системах должны быть одинаковыми

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

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

Думаю что применён md5 с небольшим изменением.

[raz]

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

[alexbn]

Цитата:

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

Супер!
предложи это людям из М...софт
И попробуй на это лицензию получить.
Решение на уровне:
Я такой маладец делайте, что хотите с моей базой - зато у меня всё работать будет.

P.S. К проблеме безопасности системы надо относиться серьёзно.
Особенно если у тебя серьёзная распределённая система, и делать решение, пусть и собственное, надо с учётом возможного маштабирования твоего решения, а также "территориально-распределённого подхода" к этому продукту

[mit]

Думаю, что нет никакого практического смысла в разрадывании механизма паролеобразования в аксапте. Исключение составляет интерес взлома.
Все равно пароли необходимо хранить в БД, для того чтобы их использовать для доступа к тем самым приложениям. Весь вопрос в том, - как хранить.
Можно это сделать в явном - открытом виде, можно и зашифровать. Механизмы шифрования могут применяться различные, включающие такие средства как электронные ключи (HASP, USB) (например http://www.aladdin.ru/)
Если принципиально хранить пароли, идентичные тем, что пользователи вводят при входе в аксапту - все таки придется писать что то свое.
Если кругом враги, то криптофункции можно вывести отдельно в DLL, тогда система получается намного устойчивее.
На мой взгляд удобней организовывать пароли в удаленнной системе - это как раз
dictionary.buildpassword(user,pass), но это пройдет только, если пользователь будет ходить в приложение из аксапты.
PS был удивлен, получив результат от приведенного ниже кода

PHP код:

static void Job1(Args _args)
{
    loginProperty   loginProperty;
    SqlSystem       sqlSystem;
    ;
    sqlSystem = new SqlSystem();
    loginProperty = sqlSystem.createLoginProperty();

    info ( "getPassword .." + loginProperty.getPassword());
    info ( "getUsername .."+ loginProperty.getUsername());
    info ( "getDatabase .."+ loginProperty.getDatabase());
    info ( "getServer .."+ loginProperty.getServer());
    info ( "getServer .."+ loginProperty.getDSN());
} 


[Lazy_Tiger]

Цитата:

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

предложи это людям из М...софт
И попробуй на это лицензию получить.
P.S. К проблеме безопасности системы надо относиться серьёзно.

А какое дело MS до МОЕГО ПРОЕКТА? НИКАКОГО. Как хочу, так и делаю. Сам за это отвечаю

Не проще ли авторизоваться средствами ОС (операционной системы) хоть с помощью смарт-карт и не парить мозг людям?

P.S. Текстовые пароли, в 21 веке, когда космические корабли чего то там бороздят и идет базар за "проблемы безопасности", ну не смешно ли самому?

[alexbn]

2 Lazy_Tiger : это не выход. И напомню, что живём всё-таки в 21-веке, и стоимость проекта всё-таки имеет некоторое значение, а также разговариваем о конкретном продукте.
2 mit: Без вопросов можно хранить как угодно - только неэтично переписывать стандартную процедуру регистрации, и дублировать данные.

Хорошо думаю меня не совсем поняли.

Сформулирую обратную задачу:

Зставить аксапту брать инфу по пользователям не из собственной БД, а например из любого ldap сервиса?

решается ли стандартными средствами?

[Lazy_Tiger]

2 alexbn: да уж куда там...
Про стоимость: картридер+смарткарта (даже если ими обеспечить _ВСЕХ_) пользователей, обойдется вам в такой мизер на фоне стоимости аксапты и железа под нее, что даже обсуждать нечего.
Про продукт, да, ы ж про аксапту, ничего не путаю?
Аксапта умеет использовать авторизацию винды. Даже если она (авторизация) проводится смарткартами (лично держал в руках) или сканированием сетчатки глаза (читал)

Из любого ldap - конечно нет. зачем? это ж таки продукт Microsoft

[Lazy_Tiger]

2 alexbn: да уж куда там...
Про стоимость: картридер+смарткарта (даже если ими обеспечить _ВСЕХ_) пользователей, обойдется вам в такой мизер на фоне стоимости аксапты и железа под нее, что даже обсуждать нечего.
Про продукт, да, мы ж про аксапту, ничего не путаю?
Аксапта умеет использовать авторизацию винды. Даже если она (авторизация) проводится смарткартами (лично держал в руках) или сканированием сетчатки глаза (читал)

Из любого ldap - конечно нет. зачем? это ж таки продукт Microsoft

P.S. да, система не сертифицировалась на соотвествие каким нить C2 и прочим. Но однако, оно и не заявляется. Обеспечивайте безопасность на уровне ОС и SQL-сервера. Ибо это их задача. И не нада путать мух с котлетами

[mit]

Цитата:

Изначально опубликовано alexbn
[B]2 mit: Без вопросов можно хранить как угодно - только неэтично переписывать стандартную процедуру регистрации, и дублировать данные.B]

ну, если неэтично переписывать стандартную процедуру , наверное взлом этичнее будет

[alexbn]

Цитата:

Изначально опубликовано Lazy_Tiger
2 alexbn: Из любого ldap - конечно нет. зачем? это ж таки продукт Microsoft

Затем что сопутствующий продукт линуксовый.

Понимаете, не надо мне авторизацию аксапты из винды - нужно как раз наоборот!
+ неохота для этой задачи использовать BC, тем более что его использовапние сильно затруднено (всё теме же ограничениями операционки).

[alexbn]

Цитата:

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

ну, если неэтично переписывать стандартную процедуру , наверное взлом этичнее будет

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

[Lazy_Tiger]

1. Что такое BC?
2. линуксовый? сами писали? ну дык в чем проблема? сами написали, сами и перепишите

P.S. проблема не стоит усилий которые вы потратили на этот топик. ИМХО. Решений масса, выбирайте то, которое вас устроит. Стандартного пути нет, придется программировать.
Где (в аксапте, в вашей программке на линуксе или и там и там) - дело десятое.

[raz]

Цитата:

Сформулирую обратную задачу:

Зставить аксапту брать инфу по пользователям не из собственной БД, а например из любого ldap сервиса?

решается ли стандартными средствами?

настройте COM коннектор, создайте в Аксапте нужные классы и синхронизируйте из внешнего ldap сервиса пароли.

[alexbn]

Цитата:

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

настройте COM коннектор, создайте в Аксапте нужные классы и синхронизируйте из внешнего ldap сервиса пароли.

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

Ладно. закрываем тему.

Резюме:
1. BC - COM - сильно трудоёмко для этой задачи, и затруднено архитектурой.
2. Способ кодирования паролей никто не знает и как видимо этот факт является обычной практикой Мелко-мягкого софта ("никто не должен ничего знать, даже если за это он заплатил")
3. Придётся просто вмешиваться в процедуру регистрации пользователей и сохранять пароли ещё куда-нить (именно этого и пытался избежать)

Спасибо за высказанные предложения.

[Wamr]

alexbn, оставь свой контакт или свяжись со мной.
Мне есть, что тебе сказать.