Можно ли поставить пароль на отдельную папку в XP

[Тень]

. должен быть универсальный пароль расшифровывающий этот файл и дальше уже из расшифрованного берутся и сравниваются хэши

нет, не так. Пусть файл зашифрован по определенному алгоритму с ключем "123". Процесс алгоритма расшифровки с другим ключем тоже "пойдет", но _правильно_ (т.е. не корректно - данные не будут доступны). А как положено он будет расшифровываться только тем ключем, которым и был зашифрован т.е. "123".
Сумбурно как-то получилось.. Если не понял, могу попробовать пояснить на примере ассемблера.

стоп. а как система узнает куда она их забросила в прошлый раз

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

В конце концов такая идея. Взять загрузчик нт (нтлоадер или как там его), прописать туда путь к этому хранилищу файлов с паролями (допустим 40 символов) и зашифровать эти 40 символов с ключем 123. Допустим, заXORить, если знаешь азм (это как пример, вообще же операций над битами и байтами - масса). При загрузке требовать пароль. Если введено 567 то запустить процедуру разXORивания с этим самым ключем (567). Эти 40 символов пути разXORятся неккоректно и там ничего не будет. Таким образом корректно можно будет разXORить путь к файлам только с ключем 123.

[unk]

нет, не так. Пусть файл зашифрован по определенному алгоритму с ключем "123". Процесс алгоритма расшифровки с другим ключем тоже "пойдет", но _правильно_ (т.е. не корректно - данные не будут доступны). А как положено он будет расшифровываться только тем ключем, которым и был зашифрован т.е. "123".
Это я всё понял. Мой вопрос был вот в чём: скажем, база аккаунтов шифрована на пароле "123". Этот пароль знает Вася Пупкин (Главный Админ), но в базе так же содержатся пароли начальника1 и начальника2. Вот приходят эти начальники на работу, пытаются войти в домен, сервак им говорит "пошли нафиг, Главный Админ ещё своё [123] не набрал, база аккаунтов недоступна". Так ? И как выходить из такой ситуации ? Речь же идет как раз про то, что если машина не однопользовательская - получается все юзеры должны знать "главный пароль" для расшифровки базы и свой личный пароль для своего аккаунта ? не пойдёт, юзеры пошлют такую идею с 2 паролями.

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

В конце концов такая идея. Взять загрузчик нт (нтлоадер или как там его), прописать туда путь к этому хранилищу файлов с паролями (допустим 40 символов) и зашифровать эти 40 символов с ключем 123. Допустим, заXORить
угумс, ксор это хорошо. одно "но" - дизассемблированный текст (как и загрузчик) должны будут содержать ксоренный текст. Кто помешает взять этот текст и просто тупо "в лоб" перебрать все варианты ? ок, пусть очень много вариантов, тогда кто мне мешает взять и положить по нужному мне пути _новую_ базу аккаунтов (с другого компа взяту, с известными паролями), потом с помощью 123 заксорить (ну пусть даже AES возьмём, не суть важно - аксиома в том что рано или поздно из загрузчика алгоритм получения пути из пароля мы узнаем) _новый_ путь и уже ксоренный подсунуть (тупо заменив старый) загрузчику. Далее события будут разворачиваться так: загрузчик "кушает" наш новый ксоренный путь, мы ему даёт наш же пароль "123" и он спокойно "кушает" нашу подсунутую базу и гордо загружает систему считая что всё хорошо.
Варианты конечно есть - шифровать весь диск с использованием данных из "правильной" базы, но это слишком долго - ждать пока будут перешифрованы гигабайты данных после того как ты новых програмок в систему понаставил. Так что вариант тоже не пройдет - сломают. с помощью той же дискетки. Ведь дискетка твоя по сути то же самое и делала - она считала хеш нового пароля, брала из реестра общий ключ шифрования для данной базы аккаунтов и в итоге новый хэш подсовывала на место старого. То же самое без проблем делается и в предложенном тобою варианте и это будет взломало точно так же. Ещё варианты есть ? повторюсь: исключительно программные варианты, т.к. в той же NT 4.0 SP3+ без проблем можно создать ключевую дискетку и ты уже просто так пароль не заменишь, т.к. не будешь знать каким ключом шифровать хеш (т.к. к дискетке, с помощью которой базу аккаунтов расшифровывает система, у тебя доступа нет)

P.S. Плз, не упоминай асм постоянно. знаю я его, знаю. правда лишь поверхностно и в основном в контексте "лечения" простейших windows программ от жадности (до денег) разработчиков, но всё равно хоть основы, но знаю. И мне кажется (может и ошибаюсь), что битовые операции тут не пойдут из-за своей простоты и, при ограниченном наборе возможных символов пароля, будут легко вскрываться даже перебором, поточное шифрование как и гаммирование (частным случаем которого xor и является) тут тоже не пойдут, лучше уж блочное и блоками максимальной длины, так что реализовать можно хоть на асме хоть на сях - в любом случае современные оптимизирующие компиляторы на выходе дадут код не хуже чем вручную на асме написанный, а может и лучше (если использовать, например, интеловский оптимизированный компилятор под конкретный процессор заточенный, всё равно человек вручную всех нюансов процессора не учтёт)

[Тень]

Это я всё понял. Мой вопрос был вот в чём: скажем, база аккаунтов шифрована на пароле "123". Этот пароль знает Вася Пупкин (Главный Админ), но в базе так же содержатся пароли начальника1 и начальника2. Вот приходят эти начальники на работу, пытаются войти в домен, сервак им говорит "пошли нафиг, Главный Админ ещё своё [123] не набрал, база аккаунтов недоступна". Так ? И как выходить из такой ситуации ? Речь же идет как раз про то, что если машина не однопользовательская - получается все юзеры должны знать "главный пароль" для расшифровки базы и свой личный пароль для своего аккаунта ? не пойдёт, юзеры пошлют такую идею с 2 паролями

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

одно "но" - если код проверки исполняется процессором

ты не понял меня. В том то и дело, что никто не будет сверять введенный пароль с паролем, хранящимся где-то. Хранится никакой пароль вааабще нигде не будет! А зашифрованный путь будет преобразовываться введенным паролем. Если он не верен, то преобраование будет иметь неверный вариант. Если верен - то верный.
Дизассемблирование тоже не подойдет, т.к. узнать конечный и правильный вариант можно только зная верный пароль.

должны будут содержать ксоренный текст. Кто помешает взять этот текст и просто тупо "в лоб" перебрать все варианты ?

ну ксор - это простейший пример. А путь можно сделать не в виде \WinNT\Password\ а в виде \ub5tui5t\3thht\4r34rh3r И ты никогда не узнаешь - правильный ли ты выбрал вариант или ошибочный.

положить по нужному мне пути _новую_ базу аккаунтов

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

битовые операции тут не пойдут из-за своей простоты

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

[unk]

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

про "непонятки": дизассемблирование нужно чтобы восстановить алгоритм шифрования пути. а если будешь знать как шифруется путь - положишь новую базу по новому пути и зашифруешь новый путь и положить на место старого шифрованного. и лоадер без проблем его расшифрует... как тебе нужно

ну ксор - это простейший пример. А путь можно сделать не в виде \WinNT\Password\ а в виде \ub5tui5t\3thht\4r34rh3r И ты никогда не узнаешь - правильный ли ты выбрал вариант или ошибочный.
угумс, я создам путь \123, кину туда базу и мне пофигу какой _был_ правильный

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

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

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

[Fun_monster]

[QUOTE=lossofsoul;793023]Народ скажите пожалуйста можно ли поставить пароль на отдельную папку в XP, и если можно то как?[/

скачай программу "File and folder protector" или "Folder Password Protect" и дальше если не валенок разберёшься как пользоваться программой)))