Проблема кажется типичной для ситуации когда вокруг одного "источника истины" навтыкали кучу сервисов, обозвали их микросервисами, а потом задолбались масштабировать этот "источник". (типа у нас микросервисы и типа warehouse :) )
Визуально напоминает монолит, который начали пилить на сервисы и новые рядом пристраивать, вешая всё на один источник данных.
Архитектурная ошибка, которую как бы поглубже закапали за ещё одним уровнем представления данных.
Код сервера вообще не при чём. Если внимательно прочитать статью, то речь идет о том, что код телеграмма в гите равен коду приложения (клиента), а для других мессенджеров это проверить нельзя.
Вот это "боль" инженеров асутп) С нетерпением жду от вас статей по проблемам асутп и их решениям)
Так может, корень зла как раз в асутп и находится? И начинать надо не с 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» — я писал в предыдущем посте и считаю, что так и есть логичнее.
Если мой пост вызовет у пользователей негатив — чему быть, того не миновать.
Проблема кажется типичной для ситуации когда вокруг одного "источника истины" навтыкали кучу сервисов, обозвали их микросервисами, а потом задолбались масштабировать этот "источник". (типа у нас микросервисы и типа warehouse :) )
Визуально напоминает монолит, который начали пилить на сервисы и новые рядом пристраивать, вешая всё на один источник данных.
Архитектурная ошибка, которую как бы поглубже закапали за ещё одним уровнем представления данных.
З.Ы. поправьте, если не прав
Читайте ниже, частный дом, так что парой будете на улице жить. Готовы вступить в семью? )
Код сервера вообще не при чём. Если внимательно прочитать статью, то речь идет о том, что код телеграмма в гите равен коду приложения (клиента), а для других мессенджеров это проверить нельзя.
Вот это "боль" инженеров асутп) С нетерпением жду от вас статей по проблемам асутп и их решениям)
Так может, корень зла как раз в асутп и находится? И начинать надо не с AR очков и распознавания картинок на Питоне, а проблем модернизации, мониторинга и контроля АСУТП?
Это жестокая реальность. Поэтому есть ощущение, что произврдству лучше субподряды заключать с ИТ-компаниями для решения проблем автоматизации, а у себя содержать небольшой штат тех.обслуживания этих решений.
А какие есть варианты "зарабатывать недостающие деньги" в этом случае?
У Сбера есть ит-дочка Сбертех, которая работает над их сервисами, вероятно это их творение.
Да и nfc сейчас модно и мало кого удивишь - все привыкли вроде.
Это по этому обычные рублёвые переводы даже внутри одного банка между клиентами занимают до 3х банковских дней? ?
Не всегда вопрос в желании обмануть или украсть - не все так относятсяк работе и обязанностям. Есть человеческий фактор - "не распознал" или "не успел".
Ставить ещё одного контроллера это +1 ставка на смену с таким же фактором риска, что экономически не целесообразно. Поэтому если проблему решать, то средствами, способными эти риски снизить.
Нет, что бы читать Лермонтова, Достоевского и статьи на Хабре в оригинале. )
По результатам видно, что там хранится и брутится SHA-1 хэш, а вот размер ключа 256 байт (но это не делает из SHA-1 SHA-256).
Кроме того, Ваша цитата относится к протоколу передачи сообщений и может не иметь ничего общего с принципами аутентификации для доступа к хранилищу.
Кто писал этот «официальный FAQ» для меня загадка, откровенно говоря, можно было написать, всё что угодно. Если в одном месте используют SHA-1 хэши, протокол передачи тоже попадает под сомнения.
Аналогично, позиция о root-доступе — это субъективное мнение. У меня оно другое. В данном случае, о том, что root снижает надежность предупредили, но сами понадеялись, что это никогда не случится. Как я уже писал, суть в подходе.
Статья читается тяжело в силу употребления автором специфического стиля повествования и изложенных эмоций (в том числе употребление сокращений и знаков пунктуации). Чтобы читалось легче и было понятнее, заинтересованным лучше перейти по указанной в статье ссылке на предыдущую статью автора, где он как раз с описанием начала его исследования вводит некоторые сокращения. Всё становятся понятнее: с чего началось, откуда сокращения, откуда эмоции и вектор атаки.
Тем кто, жаловался — вы читали статью, вырванную из контекста. (Ага, это типа продолжение и в контексте :) )
Здесь много рассуждений о том, уязвимость это или нет и имеет ли она смысл, если для этого нужен рут. На мой взгляд, — это определенно уязвимость. Когда данные, которые позиционируются как защищенные (по договору публичной оферты оглашается, что это так) и для доступа к ним нужен пароль, становятся доступными без пароля — это уязвимость.
И эта уязвимость состоит в том, что мобильное приложение идентифицирует владельца данных по биометрическим данным на устройстве, что не означает их валидность для предоставления доступа, т.к. изначально шифрование проходило по паролю и на другом устройстве.
Даже допущу, что в качестве ключа приложение просто использует сохраненный SHA1 хэш пароля после того как идентифицирует пользователя по введенному паролю (сравнивает вычисленный хэш) или по другим «системным» параметрам — отпечатку, лицу, жесту, зрачку глаза (чему угодно).
С одной стороны, это удобно для идентификации владельца любым удобным ему средством, с другой — небезопасно и может быть использовано как лазейка третьими лицами или соответствующими органами.
В любом случае, подход к аутентификации «владелец девайса», мне кажется неверным и уязвимым. Владельцев много, девайсов ещё больше, а данные могут мигрировать между ними любым способом по множеству различных причин.
Ожидается, что хорошие будут учить и выпускать хороших в хорошем положительном соотношении. А далее всех, кого сочли «хорошим» и «настоящим» будут приглашать на работу с целью писать хорошие отечественные продукты. И всё это при хорошем спонсировании или грантировании от правительства.
Вы отлично умеете искать информацию на официальных сайтах, поэтому вам не составит труда убедиться в ошибочности высказывания о том, что если Maven написан на Java, то для Java он и предназначен. Поэтому ваши суждения о размещении данных постов также ошибочны.
Для примера, Maven успешно используется для «сборок проектов» на PHP, Ruby, С++.
Почему пост(ы) находятся в хабе «Программирования», а не «JAVA» — я писал в предыдущем посте и считаю, что так и есть логичнее.
Если мой пост вызовет у пользователей негатив — чему быть, того не миновать.
И, если вы читали, рассказывает о другом.