Но вообще странная фича, интересно какой алгоритм они используют, так как если использовать например sha256, то на таких объемах данных есть шанс коллизий, любые изменения файла приводят к новому хешу,
Самое главное, не понятно что это за база хешей у Apple от куда ее взяли, да и возможно это контент других возможно уже осуждённых пользователей, то есть наличие его на телефоне другого человека явно не предотвратит уже произошедшие.
Ещё интересно как быть следователям которые по работе могут такой контент хранить на телефоне.
Давно разрабатывал несколько небольшие моды и даже занимался изменением самого кода Minecraft и были декомпелмрованныи и деобфусцирлванные исходники Minecraft и не помню что были с этим проблемы. (И они кстати были даже с комментариями Нотча)
Я не уверен но мне кажется а после покупки Majong большая часть модеров отказались от написания модов из-за усложнения в их написании. (Хотя думаю нужен комментарий от более опытные модеров)
Но это хороша новость, меня всегда уделяло что Majong не поддерживало сообщество модеров и утилит для модификации Minecraft.
Да, вы правы, это вполне себе неплохая дверь которую плохие программы скорее всего не рассчитаны открывать, но думаю преимущество это зашита от кейлогеров перед это как раз участие 2 устройств для авторизации.
Хотя, у меня есть вариант взлома (говорю уже с моменте когда злая программа силой магии попала на ваш компьютер):
Мы просто эмулируем подключения к вашему серверу для вас (такой странны консольный малварь).
И мне кажется повысить зашиты можно немного по другому. Это использовать 2 фактурную авторизацию при выполнении команд от root, и возможно даже написать отдельный протокол подтверждения команды с телефона.
Просто мне кажется вы не понимаете что хотите защитить, я не боюсь что кто-то подключить к серверу, я боюсь что кто-то получит доступам к файлам на этом сервере.
Немного не понимаю зачем нужна двухфакторная аутентификация для ssh если использовать вход по ключу и ключ можно зашифровать паролем, ну если только вы боитесь что кто-то ваш приватный ключ украдет + пароль он него, но если кто-то украл ваш приватный ключ то мне кажется стоит задуматься о том, а не делаете вы что-то неправильно и на сколько хорошо ваш спасет двух фактурная амортизация (если кто-то получил доступ к вашей машине)?
По мне так если париться, так сделать уведомления об подключения к серверу с нового ip или добавления нового публичного ключа на авторизацию.
Думаю удаления базы это даже хорошо, в плане нового опыта, все ошибающийся, и надеюсь сейчас уже:
`oh-my-war-server.cluster.gitlab.com` и `dev.cluster.gitlab.com `
Меня пугает:
1) По мне излишняя открытость, не стоит так открыто освещать проблему до её решения (да и когда был стрим процесса восстановления мне лично напомнило первую серию из черного зеркала).
2) Что они не могли восстановить из backup, сложилось впечатление что они не тестировали восстановления из backup и делали это для галочки.
Мне для неограниченное количество приватных репозиториев легче поднять VPS с Jenkins + Gitlab + Docker, да и уже прикрутить к этой балалайке Amazon Glacier и все будет прекрасно (пока не повторится история как с S3).
Кто пользуется GitLab не как локальной заменой GitHub?
Обычно ситуация такая, не хочешь платить и хочешь приватный репозиторий, тогда — bitbucket
Нужный публичный репозиторий — Github
Если нужен локальный репозиторий — разворачиваешь Gitlab на сервере.
не знаю как в данном плеере, вопрос к автору, по в FiiO X3 есть возможность просканировать SD кату на наличия аудио файлов и он уже формирует привычную библиотеку песен.
Всегда предоставляю отдельного пользователя специально для ТП, да и зачем сразу годами не меняю?
Самое важное то что пароль во время обработки тикета актуальный(иногда тикет активен около 3 дней), и как отследит кто получил доступ к серверу если с тикетом работало 5 человек и опять же повторюсь, взлом базы с тикетами и актуальные пароли уже у злоумышленника из активных на данный момент тикетов, когда если бы пароль предоставлялся только человеку который с этим сервером работает ответственность была только на этом человеке (и компании) и в случаи взлома злоумышленник не смог бы получить доступ к серверам.
имхо, но мне кажется что это огромная недоработка, пароль который был отправлен в тикете это как ключ под половиком, допустим поменялся сотрудник в ТП и ему присылают историю переписки с паролем или при получении доступа к тикету злоумышленник может получить доступ к серверу, а при этом уязвимость может быть в вашей системе, а не просто взлом аккаунта.
Под логированием я имел в виду то что система понимает что пользователь предоставил сотруднику пароль.
Я не претендую хотя бы на любительское мнение в области информационной безопасности, но мне кажется что пароль(желательно ключ) от сервера должен предоставляется только сотруднику который с этим сервером будет работать и не кому больше.
Хотел бы уточнить одну вещь, пароль от root предоставляется через специальную форму и вообще логируется что данному сотруднику был предоставлен root доступ от сервера?
Вообще имхо, но не вижу в этом не чего ужасного, арестовывал сервера у hetzner.com и VPS у digitalocean.com и были случаи когда предоставлял root, хотя обычно через специальную форму, а не просто в текит пароль сбрасывал.
Хотя хотелось бы увидеть всю переписку, а то складывается впечатления что они силой пытались доступ получить.
Но вообще странная фича, интересно какой алгоритм они используют, так как если использовать например sha256, то на таких объемах данных есть шанс коллизий, любые изменения файла приводят к новому хешу,
Самое главное, не понятно что это за база хешей у Apple от куда ее взяли, да и возможно это контент других возможно уже осуждённых пользователей, то есть наличие его на телефоне другого человека явно не предотвратит уже произошедшие.
Ещё интересно как быть следователям которые по работе могут такой контент хранить на телефоне.
Давно разрабатывал несколько небольшие моды и даже занимался изменением самого кода Minecraft и были декомпелмрованныи и деобфусцирлванные исходники Minecraft и не помню что были с этим проблемы. (И они кстати были даже с комментариями Нотча)
Я не уверен но мне кажется а после покупки Majong большая часть модеров отказались от написания модов из-за усложнения в их написании. (Хотя думаю нужен комментарий от более опытные модеров)
Но это хороша новость, меня всегда уделяло что Majong не поддерживало сообщество модеров и утилит для модификации Minecraft.
(Вот у Github (student pack), Jetbrains, Apple, Adobe — почту campus.mephi.ru принимают)
Хотя, у меня есть вариант взлома (говорю уже с моменте когда злая программа силой магии попала на ваш компьютер):
Мы просто эмулируем подключения к вашему серверу для вас (такой странны консольный малварь).
И мне кажется повысить зашиты можно немного по другому. Это использовать 2 фактурную авторизацию при выполнении команд от root, и возможно даже написать отдельный протокол подтверждения команды с телефона.
Просто мне кажется вы не понимаете что хотите защитить, я не боюсь что кто-то подключить к серверу, я боюсь что кто-то получит доступам к файлам на этом сервере.
По мне так если париться, так сделать уведомления об подключения к серверу с нового ip или добавления нового публичного ключа на авторизацию.
`oh-my-war-server.cluster.gitlab.com` и `dev.cluster.gitlab.com `
Меня пугает:
1) По мне излишняя открытость, не стоит так открыто освещать проблему до её решения (да и когда был стрим процесса восстановления мне лично напомнило первую серию из черного зеркала).
2) Что они не могли восстановить из backup, сложилось впечатление что они не тестировали восстановления из backup и делали это для галочки.
Мне для неограниченное количество приватных репозиториев легче поднять VPS с Jenkins + Gitlab + Docker, да и уже прикрутить к этой балалайке Amazon Glacier и все будет прекрасно (пока не повторится история как с S3).
Обычно ситуация такая, не хочешь платить и хочешь приватный репозиторий, тогда — bitbucket
Нужный публичный репозиторий — Github
Если нужен локальный репозиторий — разворачиваешь Gitlab на сервере.
Самое важное то что пароль во время обработки тикета актуальный(иногда тикет активен около 3 дней), и как отследит кто получил доступ к серверу если с тикетом работало 5 человек и опять же повторюсь, взлом базы с тикетами и актуальные пароли уже у злоумышленника из активных на данный момент тикетов, когда если бы пароль предоставлялся только человеку который с этим сервером работает ответственность была только на этом человеке (и компании) и в случаи взлома злоумышленник не смог бы получить доступ к серверам.
Под логированием я имел в виду то что система понимает что пользователь предоставил сотруднику пароль.
Я не претендую хотя бы на любительское мнение в области информационной безопасности, но мне кажется что пароль(желательно ключ) от сервера должен предоставляется только сотруднику который с этим сервером будет работать и не кому больше.
Хотя хотелось бы увидеть всю переписку, а то складывается впечатления что они силой пытались доступ получить.