Код сервера вообще не при чём. Если внимательно прочитать статью, то речь идет о том, что код телеграмма в гите равен коду приложения (клиента), а для других мессенджеров это проверить нельзя.
Вот это "боль" инженеров асутп) С нетерпением жду от вас статей по проблемам асутп и их решениям)
Так может, корень зла как раз в асутп и находится? И начинать надо не с AR очков и распознавания картинок на Питоне, а проблем модернизации, мониторинга и контроля АСУТП?
Это жестокая реальность. Поэтому есть ощущение, что произврдству лучше субподряды заключать с ИТ-компаниями для решения проблем автоматизации, а у себя содержать небольшой штат тех.обслуживания этих решений.
Не всегда вопрос в желании обмануть или украсть - не все так относятсяк работе и обязанностям. Есть человеческий фактор - "не распознал" или "не успел".
Ставить ещё одного контроллера это +1 ставка на смену с таким же фактором риска, что экономически не целесообразно. Поэтому если проблему решать, то средствами, способными эти риски снизить.
На счет SHA-256 или SHA-1 об этом было сказано в первой статье:
Read the salt (32 bytes), encrypted data and sha1 of decrypted data from a file.
Compute a PKCS5_PBKDF2_HMAC_SHA1 on the UTF8 (passcode), using the salt, 4000 iterations, keysize of 256 bytes
Use a Telegram-specific KDF to get the AesKey and AesIV (Relatively cheap — bunch of memcpy and 4x sha1)
По результатам видно, что там хранится и брутится SHA-1 хэш, а вот размер ключа 256 байт (но это не делает из SHA-1 SHA-256).
Кроме того, Ваша цитата относится к протоколу передачи сообщений и может не иметь ничего общего с принципами аутентификации для доступа к хранилищу.
Кто писал этот «официальный FAQ» для меня загадка, откровенно говоря, можно было написать, всё что угодно. Если в одном месте используют SHA-1 хэши, протокол передачи тоже попадает под сомнения.
Аналогично, позиция о root-доступе — это субъективное мнение. У меня оно другое. В данном случае, о том, что root снижает надежность предупредили, но сами понадеялись, что это никогда не случится. Как я уже писал, суть в подходе.
После некоторых размышлений всё таки решил написать комментарий к статье, а не к другим комментариям.
Статья читается тяжело в силу употребления автором специфического стиля повествования и изложенных эмоций (в том числе употребление сокращений и знаков пунктуации). Чтобы читалось легче и было понятнее, заинтересованным лучше перейти по указанной в статье ссылке на предыдущую статью автора, где он как раз с описанием начала его исследования вводит некоторые сокращения. Всё становятся понятнее: с чего началось, откуда сокращения, откуда эмоции и вектор атаки.
Тем кто, жаловался — вы читали статью, вырванную из контекста. (Ага, это типа продолжение и в контексте :) )
Здесь много рассуждений о том, уязвимость это или нет и имеет ли она смысл, если для этого нужен рут. На мой взгляд, — это определенно уязвимость. Когда данные, которые позиционируются как защищенные (по договору публичной оферты оглашается, что это так) и для доступа к ним нужен пароль, становятся доступными без пароля — это уязвимость.
И эта уязвимость состоит в том, что мобильное приложение идентифицирует владельца данных по биометрическим данным на устройстве, что не означает их валидность для предоставления доступа, т.к. изначально шифрование проходило по паролю и на другом устройстве.
Даже допущу, что в качестве ключа приложение просто использует сохраненный SHA1 хэш пароля после того как идентифицирует пользователя по введенному паролю (сравнивает вычисленный хэш) или по другим «системным» параметрам — отпечатку, лицу, жесту, зрачку глаза (чему угодно).
С одной стороны, это удобно для идентификации владельца любым удобным ему средством, с другой — небезопасно и может быть использовано как лазейка третьими лицами или соответствующими органами.
В любом случае, подход к аутентификации «владелец девайса», мне кажется неверным и уязвимым. Владельцев много, девайсов ещё больше, а данные могут мигрировать между ними любым способом по множеству различных причин.
На видео в треде говорится, что будет изменяться «институт» получения качественных программистов. Правительство ставит на Яндекс и хороших программистов, которые там работают, как на отечественный аналог другой компании с хорошими программистами. Поэтому планируется открывать институты подготовки качественных кадров.
Ожидается, что хорошие будут учить и выпускать хороших в хорошем положительном соотношении. А далее всех, кого сочли «хорошим» и «настоящим» будут приглашать на работу с целью писать хорошие отечественные продукты. И всё это при хорошем спонсировании или грантировании от правительства.
Да, только, «сажанием» или созданием фейковых мест этот процент не изменить. БОльшая часть обсуждений сводится именно к достижению цели «как получить 1млн программистов», а не к достижению цели «как получить качественное отечественное ПО».
По-моему, в комментариях обсуждается совершенно другая тема. «Месседж» был в том, что правительство планирует изменить процент импортного ПО на отечественное. А не запрещать программистам уезжать или сажать, или создавать фейковые рабочие места, курсы и липовые зар.платы.
Значит, к сожалению, мне так и не удалось донести свою мысль до вас.
Вы отлично умеете искать информацию на официальных сайтах, поэтому вам не составит труда убедиться в ошибочности высказывания о том, что если Maven написан на Java, то для Java он и предназначен. Поэтому ваши суждения о размещении данных постов также ошибочны.
Для примера, Maven успешно используется для «сборок проектов» на PHP, Ruby, С++.
То, что можно найти информацию о которой я писал на официальных источниках, я не сомневался. Так можно написать о многих статьях в сети. Я лишь поделился своим опытом, чтобы людям не пришлось тратить время на поиск.
Почему пост(ы) находятся в хабе «Программирования», а не «JAVA» — я писал в предыдущем посте и считаю, что так и есть логичнее.
Если мой пост вызовет у пользователей негатив — чему быть, того не миновать.
Читайте ниже, частный дом, так что парой будете на улице жить. Готовы вступить в семью? )
Код сервера вообще не при чём. Если внимательно прочитать статью, то речь идет о том, что код телеграмма в гите равен коду приложения (клиента), а для других мессенджеров это проверить нельзя.
Вот это "боль" инженеров асутп) С нетерпением жду от вас статей по проблемам асутп и их решениям)
Так может, корень зла как раз в асутп и находится? И начинать надо не с AR очков и распознавания картинок на Питоне, а проблем модернизации, мониторинга и контроля АСУТП?
Это жестокая реальность. Поэтому есть ощущение, что произврдству лучше субподряды заключать с ИТ-компаниями для решения проблем автоматизации, а у себя содержать небольшой штат тех.обслуживания этих решений.
А какие есть варианты "зарабатывать недостающие деньги" в этом случае?
У Сбера есть ит-дочка Сбертех, которая работает над их сервисами, вероятно это их творение.
Да и nfc сейчас модно и мало кого удивишь - все привыкли вроде.
Это по этому обычные рублёвые переводы даже внутри одного банка между клиентами занимают до 3х банковских дней? ?
Не всегда вопрос в желании обмануть или украсть - не все так относятсяк работе и обязанностям. Есть человеческий фактор - "не распознал" или "не успел".
Ставить ещё одного контроллера это +1 ставка на смену с таким же фактором риска, что экономически не целесообразно. Поэтому если проблему решать, то средствами, способными эти риски снизить.
Нет, что бы читать Лермонтова, Достоевского и статьи на Хабре в оригинале. )
По результатам видно, что там хранится и брутится SHA-1 хэш, а вот размер ключа 256 байт (но это не делает из SHA-1 SHA-256).
Кроме того, Ваша цитата относится к протоколу передачи сообщений и может не иметь ничего общего с принципами аутентификации для доступа к хранилищу.
Кто писал этот «официальный FAQ» для меня загадка, откровенно говоря, можно было написать, всё что угодно. Если в одном месте используют SHA-1 хэши, протокол передачи тоже попадает под сомнения.
Аналогично, позиция о root-доступе — это субъективное мнение. У меня оно другое. В данном случае, о том, что root снижает надежность предупредили, но сами понадеялись, что это никогда не случится. Как я уже писал, суть в подходе.
Статья читается тяжело в силу употребления автором специфического стиля повествования и изложенных эмоций (в том числе употребление сокращений и знаков пунктуации). Чтобы читалось легче и было понятнее, заинтересованным лучше перейти по указанной в статье ссылке на предыдущую статью автора, где он как раз с описанием начала его исследования вводит некоторые сокращения. Всё становятся понятнее: с чего началось, откуда сокращения, откуда эмоции и вектор атаки.
Тем кто, жаловался — вы читали статью, вырванную из контекста. (Ага, это типа продолжение и в контексте :) )
Здесь много рассуждений о том, уязвимость это или нет и имеет ли она смысл, если для этого нужен рут. На мой взгляд, — это определенно уязвимость. Когда данные, которые позиционируются как защищенные (по договору публичной оферты оглашается, что это так) и для доступа к ним нужен пароль, становятся доступными без пароля — это уязвимость.
И эта уязвимость состоит в том, что мобильное приложение идентифицирует владельца данных по биометрическим данным на устройстве, что не означает их валидность для предоставления доступа, т.к. изначально шифрование проходило по паролю и на другом устройстве.
Даже допущу, что в качестве ключа приложение просто использует сохраненный SHA1 хэш пароля после того как идентифицирует пользователя по введенному паролю (сравнивает вычисленный хэш) или по другим «системным» параметрам — отпечатку, лицу, жесту, зрачку глаза (чему угодно).
С одной стороны, это удобно для идентификации владельца любым удобным ему средством, с другой — небезопасно и может быть использовано как лазейка третьими лицами или соответствующими органами.
В любом случае, подход к аутентификации «владелец девайса», мне кажется неверным и уязвимым. Владельцев много, девайсов ещё больше, а данные могут мигрировать между ними любым способом по множеству различных причин.
Ожидается, что хорошие будут учить и выпускать хороших в хорошем положительном соотношении. А далее всех, кого сочли «хорошим» и «настоящим» будут приглашать на работу с целью писать хорошие отечественные продукты. И всё это при хорошем спонсировании или грантировании от правительства.
Вы отлично умеете искать информацию на официальных сайтах, поэтому вам не составит труда убедиться в ошибочности высказывания о том, что если Maven написан на Java, то для Java он и предназначен. Поэтому ваши суждения о размещении данных постов также ошибочны.
Для примера, Maven успешно используется для «сборок проектов» на PHP, Ruby, С++.
Почему пост(ы) находятся в хабе «Программирования», а не «JAVA» — я писал в предыдущем посте и считаю, что так и есть логичнее.
Если мой пост вызовет у пользователей негатив — чему быть, того не миновать.
И, если вы читали, рассказывает о другом.