Media Player Classic Home Cinema — open source программа, так что можно собрать под свои потребности версию с бОльшим числом закладок. Навскидку, надо будет внести изменения в файл AppSettings.h (строки 158 и 165):
поставить числа побольше, например 99 и закладок, создаваемых средствами плеера, станет больше. А ваш опыт будет полезен для программ с закрытыми исходниками, где такой трюк не пройдёт, из-за отсутствия исходников (хотя остаётся возможность пропатчить бинарник, но это часто сложнее, да и обычно противозаконно).
Про GUID и его генерацию в Windows уже давно расписано. Использовать его в качестве идентификатора не рекомендуется в силу предказуемости и возможности подбора за приемлемое время в зависимости от используемой реализации.
То есть вместо проверки того, совпадает ли этот хэш с хэшем конкретного пользователя, мы проверяем только то, есть ли такой хэш в системе вообще.
Напомнило боян: Извините, Вы не можете использовать указанный пароль. Такой пароль уже использует пользователь %username%. Пожалуйста, придумайте другой пароль.
Чисто формально получается, что у каждого пользователя в системе теперь не 1 пароль (пренебрегая коллизиями хеш-функции), а очень-очень много (достаточно совпадения с любым из хэшей). Безопасность схемы теперь во многом зависит от качества случайной генерации соли и её уникальности. Без уникальности соли всё совсем плохо. В самом деле если в базе есть некий admin_hash, полученный из пароля admin_password и соли admin_salt, который используется аккаунтом admin, то хакер, регистрируя кучу аккаунтов (предположим схема используется на web-сайте с открытой регистрацией) с фиксированным паролем hacker_password добавляет в базу кучку хэшей своего пароля с разной солью. Если в какой-то момент времени при регистрации аккаунта сгенерированная соль совпадёт с admin_salt, то хакер спокойно войдёт под аккаунтом admin и паролем hacker_password, т.к. в базе будет и H(admin_salt+hacker_password). Далее, в этой схеме с удалением аккаунтов тоже всё не так просто, особенно если соль имеет переменную длину и для хэширования используется метод H($salt.$password). Допустим, есть 2 аккаунта: user1 salt='pass', password='word' и user2 salt='pas', password='sword'. Соли как мы видим различны, но хэши совпадут H('password'). Теперь если удалить любой из аккаунтов, то могут быть 2 ситуации в зависимости от реализации:
1. Классический случай — помимо пользователя мы удаляем и его хэш, после чего оставшийся 2й пользователь не сможет залогинится, т.к. вход обоих пользователей обеспечивался одной строчкой в базе, которой больше нет.
2. (более вероятный случай, т.к. схема категорически приветствует захламление таблицы хэшей) Мы оставляем хэш, но удаляем все данные из таблицы с пользователями. Допустим удалили user1, теперь его соль 'pass' снова «свободна», т.е. может быть выдана генератором для некого вновь создаваемого user3 не нарушая свойств уникальности. Если такое произойдёт, то у user3 волей-неволей будет как минимум 2 пароля — тот который он задаст, и конечно же 'word', доставшийся «в наследство» от почившего user1 (хэш H('password') мы не стёрли). Отсюда следует, что в данной схеме соль, помимо случайности и уникальности должна быть однократно используемой, т.е. при удалении пользователя его соль должна оставаться «на память», раз уж мы оставляем хэш. Иначе хакер зарегает кучку аккаунтов со своим hacker_password с целью «застолбить» побольше солей, потом удалит аккаунты и если его хэши останутся, а соли нет, будет ждать пока его соли не раздадут новым пользователям, у которых помимо своего пароля будет подходить ещё и hacker_password.
И да, смена пароля в данной схеме тоже забавна — как было показано ранее одна строчка в таблице хэшей теперь вовсе не означает что она отвечает за единственного пользователя, т.к. мы сами сознательно by design нарушили отношение 1:1 между пользователями и хэшами и мы не знаем какой хэш каким пользователям соответствует. Так что перезаписывать совпавший хэш чревато влиянием на других пользователей. Если же мы просто добавим хэш от нового пароля, то старый действовать не перестанет, т.к. стирать старый хэш опасно да и против наших правил о захламлении таблицы хэшей. Так что, как вариант, остаётся при смене пароля «выдавать» пользователю новую соль, тогда старый пароль перестанет подходить.
Тоже копался в редакторе карт, методом «тыка», т.к. интернета тогда у меня не было. Чаще всего брал одну из готовых карт за основу и начинал менять различные вещи. Как-то провёл забавный эксперимент — добавил золотым рудникам пассивную ауру (как у Иллидана), которая обжигала рабочих при входе и выходе за золотом. После чего начал играть на свежесозданной карте против компьютера выбрав обоим расы, у которых рабочие входят в рудник (люди, орки), т.к. на других расах эффекта бы не было, в связи с расовыми особенностями добычи золота. Тогда же и понял, что компьютерному AI тяжеловато приходится в таких нестандартных условиях. Понятное дело, что по возможности нужно как можно скорее построить здание обучающее целителей, после чего возле каждого рудника, где идёт добыча, поставить несколько лекарей с лечением на автокасте. И тогда смертность среди рабочих прекратится. Но компьютерный AI до этой простой идеи, к сожалению, не доходил :( Ну а до обучения целителей золото добывается «потом и кровью» в буквальном смысле, других вариантов особо-то и нет (читы не в счёт) — «мыши кололись и плакали, но продолжали грызть кактус». Зато этот момент, как мне тогда казалось, добавляет немного реалистичности — рабочий на прииске выматывается до чёртиков и может умереть от изнеможения, если его не опекать.
В случае пластиковых клавиш всё ещё печальнее, там даже последовательность можно узнать. Правда в исследовании не учтён момент, что кроме pin-кода с клавиатуры могут вводиться другие данные (например снимаемая сумма), что несколько снижает эффективность метода, хотя и не очень сильно, так как для снятия предустановленных сумм в большинстве банкоматов сделаны отдельные кнопки.
Меня вот интересует почему CVV пишут прямо на карте, а не выдают в конверте по аналогии с PIN'ом? Это ж всё равно что бумажку с паролем на монитор клеить.
>Пользуемся программой весь срок эксплуатации (если нужны файлы, которые создаёт программа — выносим их из песочницы путём «восстановления»)
Думается, это неплохая лазейка для авторов триальных программ, которые результаты деятельности программы сохраняют в своём проприетарном формате — добавлять дату/количество запусков/etc в файлы с данными. А после открытия такого файла триальная программа в песочнице вдруг «поймёт» что её обманывают. Другой вопрос, что это пока не распространено и не для всех программ подходит.
Открыл WinHEX'ом, пропустил первые 8 байт, остальное скопировал в новый файл, к нему применил Edit->Convert->zlib inflate и распаковал 1ю флешку. В распакованной флешке поискал байты CWS, нашлись по смещению 0x241, опять же пропустил 8 байт, со смещения 0x249 начинаются сжатые данные и продолжаются до смещения 0x4FA (после глазами явно видны нули), опять копируем диапазон 0x249-0x4FA и распаковываем. Ну а дальше глазками смотрим и видим по смещению 0x29C байт 0x06 затем название класса String, байт 0x14 (длина строки) и сама строка «UFO appears suddenly».
Существует схема, которая не боится кражи базы паролей с сервера — Lamport hash chain. Другой вопрос, что мне неизвестны реальные продукты, в которых бы она применялась. Возможно, отпугивает необходимость вычислений на клиентской стороне. Или солёные хэши + многократное хэширование просто привычнее и проще для понимания.
поставить числа побольше, например 99 и закладок, создаваемых средствами плеера, станет больше. А ваш опыт будет полезен для программ с закрытыми исходниками, где такой трюк не пройдёт, из-за отсутствия исходников (хотя остаётся возможность пропатчить бинарник, но это часто сложнее, да и обычно противозаконно).
Неспроста раньше правители платили придворным лекарям только пока были здоровы. Так что скорейшее выздоровление пациента было в интересах врача.
Напомнило боян:
Извините, Вы не можете использовать указанный пароль. Такой пароль уже использует пользователь %username%. Пожалуйста, придумайте другой пароль.
Чисто формально получается, что у каждого пользователя в системе теперь не 1 пароль (пренебрегая коллизиями хеш-функции), а очень-очень много (достаточно совпадения с любым из хэшей). Безопасность схемы теперь во многом зависит от качества случайной генерации соли и её уникальности. Без уникальности соли всё совсем плохо. В самом деле если в базе есть некий admin_hash, полученный из пароля admin_password и соли admin_salt, который используется аккаунтом admin, то хакер, регистрируя кучу аккаунтов (предположим схема используется на web-сайте с открытой регистрацией) с фиксированным паролем hacker_password добавляет в базу кучку хэшей своего пароля с разной солью. Если в какой-то момент времени при регистрации аккаунта сгенерированная соль совпадёт с admin_salt, то хакер спокойно войдёт под аккаунтом admin и паролем hacker_password, т.к. в базе будет и H(admin_salt+hacker_password). Далее, в этой схеме с удалением аккаунтов тоже всё не так просто, особенно если соль имеет переменную длину и для хэширования используется метод H($salt.$password). Допустим, есть 2 аккаунта: user1 salt='pass', password='word' и user2 salt='pas', password='sword'. Соли как мы видим различны, но хэши совпадут H('password'). Теперь если удалить любой из аккаунтов, то могут быть 2 ситуации в зависимости от реализации:
1. Классический случай — помимо пользователя мы удаляем и его хэш, после чего оставшийся 2й пользователь не сможет залогинится, т.к. вход обоих пользователей обеспечивался одной строчкой в базе, которой больше нет.
2. (более вероятный случай, т.к. схема категорически приветствует захламление таблицы хэшей) Мы оставляем хэш, но удаляем все данные из таблицы с пользователями. Допустим удалили user1, теперь его соль 'pass' снова «свободна», т.е. может быть выдана генератором для некого вновь создаваемого user3 не нарушая свойств уникальности. Если такое произойдёт, то у user3 волей-неволей будет как минимум 2 пароля — тот который он задаст, и конечно же 'word', доставшийся «в наследство» от почившего user1 (хэш H('password') мы не стёрли). Отсюда следует, что в данной схеме соль, помимо случайности и уникальности должна быть однократно используемой, т.е. при удалении пользователя его соль должна оставаться «на память», раз уж мы оставляем хэш. Иначе хакер зарегает кучку аккаунтов со своим hacker_password с целью «застолбить» побольше солей, потом удалит аккаунты и если его хэши останутся, а соли нет, будет ждать пока его соли не раздадут новым пользователям, у которых помимо своего пароля будет подходить ещё и hacker_password.
И да, смена пароля в данной схеме тоже забавна — как было показано ранее одна строчка в таблице хэшей теперь вовсе не означает что она отвечает за единственного пользователя, т.к. мы сами сознательно by design нарушили отношение 1:1 между пользователями и хэшами и мы не знаем какой хэш каким пользователям соответствует. Так что перезаписывать совпавший хэш чревато влиянием на других пользователей. Если же мы просто добавим хэш от нового пароля, то старый действовать не перестанет, т.к. стирать старый хэш опасно да и против наших правил о захламлении таблицы хэшей. Так что, как вариант, остаётся при смене пароля «выдавать» пользователю новую соль, тогда старый пароль перестанет подходить.
Сразу вспомнился суровый способ камуфляжа содержимого экрана
(цитата)
«Если микросхема Фрица проникнет в центральный процессор, то ее оттуда больше не «выкурить».»
Думается, это неплохая лазейка для авторов триальных программ, которые результаты деятельности программы сохраняют в своём проприетарном формате — добавлять дату/количество запусков/etc в файлы с данными. А после открытия такого файла триальная программа в песочнице вдруг «поймёт» что её обманывают. Другой вопрос, что это пока не распространено и не для всех программ подходит.
AT+CRSM=176,28448,0,0,8