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

[lossofsoul]

Народ скажите пожалуйста можно ли поставить пароль на отдельную папку в XP, и если можно то как?

 

[Yellow_GIRL]

FIRE, помоему нельзя...можно только открыть доступ...а закрыть его..!Ну незнаю у меня такой функцие нету...вот=)

 

[Kosh]

Можно, если у тебя винчестер отформатирован в систему NTFS(стандартная для вигдовса NT), однако, обычно делают Fat32 - практически все так делают, так вот там такого сделать нельзя...
Если система NTFS - всё очень просто: создаёшь учётные записи тех, кто будет работать на компьютере и далее, берёшь папку, на которую хочешь поставить запрет на доступ определённому человеку и создаёшь правила, которые позволили бы ТЕБЕ нормально работать в этой папке, а другому только читать, а третьему - вообще доступ запретить...
Вобщем, всё упирается в файловую систему...

P.S.: Вобщем-то там ставится не пароль - пароль ставится на вход в виндовс под его именем, а дальше винда сама думает пускать тебя в папку или нет(в любом случае Администратор устанавливает всё эти правила).

 

[unk]

Описанное - это разграничение доступа на уровне прав NTFS'а, появилось начиная с NT, но это "как бы ограничение" обходится секунд за 20 (перезагрузка - секунд 10, запуск DOS-програмки 5-летней давности для чтения файлов с ntfs раздела с игнорированием атрибутов - ещё секунд 10) путем доступа к NTFS разделу из DOS, с Win'PE или вообще конвертацией тем же PQMagic'ом раздела в FAT32 из NTFS и тогда все "спец. атрибуты" будут потеряны и доступ будем всем, так что это не защита, а видимость защиты

Можно использовать шифрование (EFS), для win'xp применимо только к Win'XP pro, в Win'XP home этого нет. Достаточно вызвать свойства нужного файла/папки и в атрибутах поставить "использовать шифрование для защиты данных". В итоге все файлы скопированные в такую шифрованную папку автоматически шифруются, при чтении - автоматически расшифровываются. Плюсы - используется асимметричное шифрование на нескольких ключах - на ключе юзера (получается из его пароля и его SID) и ключе агента восстановления, т.е. в системе заводится пользователь от имени которого можно восстановить шифрованные файлы если юзер забыл свой пароль. Т.к. файлы реально шифруются - копирование файлов под DOS'ом или снимание винчествера и попытка копирования файлов через другой комп с Win'XP уже (в отличие от описанного способа с разграничением доступа по правами) не прокатит. Недостатки: 1) шифруются файлы с использованием пароля юзера и если юзер сменит пароль - он теряет доступ к ранее зашифрованным (на другом пароле) файлам; 2) по-дефолту агентом восстановления является админ и если этого не изменить, то админ сможет расшифровать файлы юзера (если изменить агента восстановления, то админ уже ничего не сделает). Средства обхода: advanced EFS data recovery от elcomsoft и подобное (от Passware, например) - расшифровывают чужие файлы, для этого тому кто расшифровывает нужен физический доступ к файловой системе юзера и знание пароля юзера (если пароль был сменён после шифрования).

P.S. для Win'XP home можно использовать WinGuard Pro (http://www.winguardpro.com), _теоретически_ она тоже использует шифрование.. а вот практически какие существуют способы обхода - фиг знает поэтому лучше пользоваться проверенными штатными средствами EFS. Хотя можно попробовать так же всякие PGP disk, но это уже совсем радикальные меры когда нужно просто создать шифрованный виртуальный диск в системе при копировании на который будет примерно то же что с шифрованными папками EFS, но который можно перетаскивать между компьютерами (EFS шифрует файлы только для данного компа, при копировании шифрованного файла на дискетку или на FAT раздел, если копирование ведёт тот кто шифровал, то файл автоматически расшифруется)..

 

[Шогал]

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

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

 

[unk]

Гонишь... Паролем юзера шифруются не сами файлы, а ключ их расшифровки.

Не будем без повода бросаться пионерскими фразами типа "гонишь". Хотя если так слово нравится, то используя его можно сказать, что гонишь как раз ты, т.к. я не говорил "файлы шифруются паролем юзера", я сказал "файлы шифруются с использованием пароля юзера" - это разные понятия. Для педантов (модераторам: это не ругательство, см. толковый словарь ) я специально пояснил, что файл шифруется на нескольких ключах и из этой фразы и из того что шифруется "с использованием пароля" можно без проблем сделать вывод, что один из ключей шифруется паролем юзера. И если уж на то пошло - не паролем он шифруется, максимум - хэшем пароля.
Далее, насчёт того что доступ теряется не всегда, а в зависимости от того кто сменил пароль: тут рассматривается практическое применение и большинству пофигу кто сменил пароль - важен лишь результат к чему приведет смена, а в общем случае (самый плохой вариант) - смена пароля приведёт к потере доступа к файлу. А если уж хочется попридираться - то вспомни что начиная с win'xp можно давать доступ к шифрованному файлу нескольким пользователям (добавлять в DDF новые записи FEK для других юзеров) и таких юзеров, кажется, не больше 800 можно добавить, но через WinAPI такое можно было делать уже начиная с Win'2k, а в проводник (чтобы через GUI такое сделать) это добавили в Win'XP. Но это всё если именно придираться, тут же человек хотел получить ответ. Общий ответ "как поставить пароль на папку" без вникания в нюансы. Я что-то не так сказал в контексте общего ответа на изначальный вопрос ?

 

[Шогал]

"Гонишь" - это в моем лексиконе обозначает "опечатка"

 

[Тень]

Хочу вас всех разочаровать.

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

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

А по теме, после длительных и мучительных попыток ответить на тот же вопрос около года назад я пришел к выводу, что НЕТ, НЕЛЬЗЯ.
Однако существует целая туева хуча программок, которые гордо именуют себя "системами защиты", которые позволяют подобное. У всех них есть свои недостатки - главный из которых то, что они "навесные".
Оптимальным решением проблемы я тогда посчитал создание небольших логических дисков и их последующее шифрование.

 

[Шогал]

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

 

[unk]

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

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

Около года назад был шокирован, отрыв древнющую программку, которая создает загрузочную дискету для любой НТ-винды (лично опробовал только на 2000 и хр). С этой дискетки можно загрузить комп (не винду)
чем шокирован-то ? А не шокирует, что микрософт _бесплатно_ распространяет Win'PE с помощью которой можно подцепить реестр локального компа и вместо скринсейвера прописать cmd.exe из которого потом сменить любой пароль включая пароль в домене ? а уж про LOCKSMITH под WinPE вообще молчу
А вот вышеуказанная дискетка явно не умеет пароли в базе active directory (точнее, в базе AD распологающейся в ntds.dit) менять
Ещё можно: NTFSDOS Pro и стереть SAM (опять же, действует лишь для локальных учётных записей, если комп - контроллер домена, то только менять скринсейвер и из командной строки менять пароль админа).. ещё варианты есть.. так что всё нормально

над тупоголовостью микрософтцев..
можно уйти на *nix'оподобное и не ругать тех кто что-то делает как считаем нужным.. например, как бы мне что-нибудь не ненравилось в windows, но никогда не скажу, что она глюкавая, т.к.:
1) я один не напишу лучше ОС, а как можно от других _требовать_ (или обвинять, что одно и то же по сути) чего-либо если сам не можешь этого сделать ?
2) почему-то обычно все глюки лишь у "хом юзеров", а корпоративные серваки под win'2k стоят годами и всё нормально. главное перед серверной охрану и всё. А не ломается (не взламывается) лишь то, что не работает
Опять же, лучше идеи сделать два виртуальных рабочих стола и в контексте одного запускать winlogon, а в контексте другого - всё остальное чтобы клавиатурные хуки уровня приложений не смогли перехватить пароль (а по alt ctrl del принудительно на другой виртуальный рабочий стол переключаться) - до такого в *nix'ах пока не додумались и никто тебе не помешает под *nix'ами эмулировать приглашение ввода пароля.. про внутреннее хранение хешей никто и не говорит - с внешним видом окна авторизации разобрались бы

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

Оптимальным решением проблемы я тогда посчитал создание небольших логических дисков и их последующее шифрование.
угумс.. народ давно с этим согласился и изобрел кучу всего - начиная от diskreet и заканчивая PGP disk и bestcrypt с его перемещаемыми кроссплатформенными контейнерами

 

[unk]

Вот у меня появлялась превосходная идея - вешать хук... никто в форуме не хочет говорить, как это реализовать на дельфах. А то что реализовать можно - уверен на 100% - пример тому антивирусы.

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

 

[Тень]

что знание ключевой информации позволит дешифровать шифрованное

вот именно, что ключевая инфа неизвестна. Создаю эту дискетку на своем компе и открываю любые другие..

? А не шокирует, что микрософт _бесплатно_ распространяет Win'PE

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

 

[unk]

вот именно, что ключевая инфа неизвестна. Создаю эту дискетку на своем компе и открываю любые другие..

ЛЮБЫЕ ? повторюсь: ты сможешь "открыть" (хм-м.. что значит "открываю" ? ) пароль админа в базе домена, Active Directory ? Нет. Дискетка эта тупо напрямую правит только файлы реестра и позволяет получить доступ только к локальным аккаунтам.

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

Угу. Сможешь назвать мне систему которая не ломается путем подмены хэша пароля ? ну хоть одну ? Таких нет. Так чего ж этого требовать от windows ? Наверное, о математических аспектах спорить бесполезно - ты ответишь "ну у меня же есть дискетка, а что там как меня не волнует" поэтому приведу такой пример: ты покупаешь сейф. ну тысяч за 50-100 баксов, обеспечивающий какой-нибудь заведомо нафиг не нужный для дома уровень безопасности. А потом просто берешь и высверливаешь замок (не рассматриваем аспекты чем и как высверлись для конкретного материала стенок), т.е. просто меняешь систему защиты (замок) на пустую (дырка) или, например, ставишь туда свой замок с заведомо известным ключом и потом долго кричишь везде что "фу, отстойные сейфы, их система защиты ничего не стоит, я ломаю её одной несчастной дрелью". И чего - это будет пример того, что система ненадежна ? Нет, это будет пример того, что не существует систем противодействующих подмене алгоритма проверки ключевой информации или самой ключевой информации. Защита гарантирует стойкость атак на математическую реализацию, а не стойкость от подмены алгоритма (стойкость от подмены могут обеспечивать аппаратные средства, например, электронные ключи и платка проверяющая целостность базы аккаунтов и просто не дающая загрузить комп если ты дискеткой эту базу подменил). И 99/100 про то, что речь шла о дискетке типа "Offline NT Password & Registry Editor", её недостатки (точнее, что она далеко не всё восстанавливает) есть на домашней страничке программы.

Так что, по-моему, нельзя говорить о том, что система "взломана" если для "взлома" используются не уязвимости самой OS, а уязвимости компа который предоставляет возмжность всем кому не лень править байтики на диске. Т.е. нужны аппаратные средства контроля правки этих байтиков, а то, например, если у тебя есть программа которая в файле хранит пароль "123", ты же просто запускаешь прогу из-под DOS'а и напрямую на диске вписываешь "234" и чего - ты сломал _систему защиты_ ? нет, ты подменил ключевую информацию с использованием недоработок контроля доступа к диску и даже не касался самой системы защиты программы. Это уже аппаратная проблемма, а не программная

P.S. Win'PE - это windows preinstallation environment - типа "демо-версии" windows'XP которая занимает 150Mb и запускается прямо с CD чтобы проверить совместимо ли твоё железо с win'xp хотя бы в процессе загрузки win'xp.. но параллельно позволяет точно так же изменить сами файлы на уже установленной системе. Опять же, от чего защищают алгоритмы проверки безопасности в операционке - смотри выше, от "грубой силы путем дискеток которые ничего не делают кроме копирования своих файлов" смогут защитить аппаратные средства, но аппаратные средства обходятся путем физического удаления этих средств.. так что обходится любая защита.. попробую свою написать которую невозможно будет взломать "бит-хаком", но которая будет исключительно программной - может получится..

P.P.S. А пример такой дискетки - тот же Partition Magic, т.к. он тоже, если запускать на NT-подобной системе, втихоря ищет на FAT/NTFS разделах каталог winnt/windows, в нём ищет \system32\config\system (бинарный образ ветки реестра) и в реестре ищет HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductType и на его основе заполняет в своей внутренней структуре тип операционки для которой запустили PQMagic и если она LanmanNT или ServerNT, то выводит сообщение о том, что PQMagic не работает на серверной OS. Проверка такая правится путем замены 2 байт в функции проверки PQMagic'а (и после этого он работает на серверных OS, хотя для серверных у Powerquest'а есть отдельный, дороже PQMagic'а, продукт) и чего - мы 2 байтами послали нафиг всю маркетинговую политику авторов PQMagic'а ? Да, послали.. Но сам PQMagic подленько втихоря читал с диска реестр.. так что всё фигня, всё ломается

 

[Тень]

Дискетка эта тупо напрямую правит только файлы реестра и позволяет получить доступ только к локальным аккаунтам

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

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

я вообще-то не специалист и лишь давным давно, лет эдак пять назад, увлекался подобными вещами.
Про сейф пример понятен, но насколько он здесь уместен? Я ломаю не свой "сейф" этой дискеткой, а любые другие, попавшиеся под руку. Причем с завидной легкостью и отсутствием проблем. Почему так?
По поводу защиты доступа к паролю или к файлам пароля - вариантов масса. Столько же, сколько извилин в мозгу человека, который имеет способность соображать. В конце концов - зачем где-то хранить эти пароли? Почему бы не _шифровать_ этим паролем те самые файлы аккаунтов с этими же логинами? Ввел направильный пароль - расшифровка пойдет, но расшифрует неправильно - ошибка и аккаунт не загружается. Или зачем хранить эти файлы всегда в одном и том же месте с одним и тем же расширением и одним и тем же именем? Почему при установки ОС ей бы не забросить и не назвать их в хаотичном порядке? Тогда именно эта ОС будет знать, где они хранятся, а никакая дискетка этого знать не будет.

 

[unk]

Доступ к информации как таковой определяется в EFS наличием ключа для расшифровки. Попробуй зашифруй папку с помощью EFS в win'xp pro, потом через чудо-дискетку смени пароль юзера под которым шифровали и попробуй прочитать каталог шифрованный с новым паролем. Если не удастся - значит "доступа к информации как таковой" дискетка не даёт. Только и всего

Про сейф пример понятен, но насколько он здесь уместен? Я ломаю не свой "сейф" этой дискеткой, а любые другие, попавшиеся под руку.
Любые другие ? нет уж, не любые другие, а те которые "знает" дискетка (т.е. те которые хранят хеш пароля точно так же как та система с которой работает дискетка). Точно так же найдя "дрель" под конкретный тип замка/стенок сейфа можно будет ломать "любые другие сейфы попавшиеся под руку" (с таким же типок замка/стенок).. вот собственно к этому пример

способность соображать. В конце концов - зачем где-то хранить эти пароли? Почему бы не _шифровать_ этим паролем те самые файлы аккаунтов с этими же логинами?
"тем самым" это каким ? Ведь файл с паролями содержит все локальные пароли, т.е. должен быть универсальный пароль расшифровывающий этот файл и дальше уже из расшифрованного берутся и сравниваются хэши. это сделано ещё с, кажется, то ли четвёртого то ли третьего сервис=пака под NT 4.0: файлы с хешами аккаунтов _шифруются_, но в общем случае пароль для расшифровки хранится в том же реестре (чтобы система могла расшифровать при загрузке). Но попробуй такой вариант: запусти syskey (штатная утилита) и выбери "обновить" и "хранить ключ на дискете" и всё - файл с паролями будет зашифрован, но ключ к расшифрованию на дискете и без этой дискеты ты файл не расшифруешь. одно "но" - данные о том что ключ на дискете хранятся в реестре и никто тебе не помешает изменить информацию на "клюс хранится в реестре" и подсунуть в реестр нужный ключ. Ещё варианты есть (кроме шифрования файла с аккаунтами, т.к. это не вариант - признак того что файл с аккаунтами зашифрован хранится локально и его, признак, можно изменить) ? Кроме "хранить файл с аккаунтами на дискете и никаких вариантов других, локально ничего не храниться" - это подходит лишь для организаций небольших и там уже давно используются как раз для этого или usb-брелки или "таблетки" dallas'овские с памятью и подобное. но всё это (включая дискету) уже _аппаратная_ (дискетка - отдельное "аппаратное устройство" с ключом) защита, Приведи пример программной реализации которую, хотя бы теоретически, нельзя было сломать

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

 

[Тень]

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

нет, не так. Пусть файл зашифрован по определенному алгоритму с ключем "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]

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

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