Что самое забавное, правила на длину пароля, большие/маленькие символы, цифры и спецсимволы были введены для противостояния всего-навсего одному из векторов атаки - брутфорсу. Все эти ухищрения ни разу не помогают от кейлоггеров и приводят к концентрации паролей или в менеджере паролей или на бумажке или шаблонизации паролей.
Вообще концептуально безопасность определяется ответами на вопросы "Кто я", "Что я имею" и "Что я знаю" и их комбинацией. Пароль это типичный представитель "Что я знаю", 2ФА это как правило комбинация "Что я знаю" + "Что я имею" (телефон, цифровой аутентификатор). "Кто я" это всякого рода биометрия и даже в какой-то мере digital fingerprint устройства.
Ну так и опишите что видите проблему в читаемости кода, желательно такими словами который можно понять и принять. Механическое ограничение на длину строки эту проблему не решает от слова совсем.
IT позволяет либо снижать издержки, либо поддерживать рост. В условиях когда роста быть не может, а издержки можно срезать просто скинув ЗП рядовому персоналу, как-то не выглядит что «программист в домике»
Когда соревнуются маркетологи, инженеры отдыхают. А там либо шах, либо ишак - без разницы - деньги уже проедены. С учётом что даже на стороне заказчика куда важнее отчитаться об истории успеха нежели иметь её по факту, очень непохоже что что-то изменится ближайшие двадцать лет.
Там еще забавный факт был что Маск не участвовал своими акциями в принятии решения по SolarCity. Он выступил что это типа missing link и «надо брать», но своими акциями он не голосовал.
Верно, я про это и говорю! Нужен сторонний канал. А насчет Encryption Key и общего ключа, это индикация что ключ не перехвачен еще кем-то кроме владельцев мессенджера.
Есть алгоритмы стеганографии устойчивые к пережатию. Много конечно туда не засунешь но на текст хватит. Я помню читал (вроде близзы) встраивали в Alpha/Closed Beta релизы чтобы иметь возможность отследить утечку. Там народ издевался и с пережатием и кропы и еще чет делали, были очень удивлены как долго watermark выдерживал. Ссылку разумеется сейчас не найду.
Всем нужно уметь пользоваться. Просто если у вас есть недоверенный канал передачи данных, лучшее что вы можете сделать - замаскировать одно сообщение в другом. Стеганография не панацея, там тоже нужно обменяться секретами для начала, а это возвращает нас к вопросу второго канала
Отнюдь, тут вопрос как мы доверяем каналу передачи. Если мы генерируем на обоих сторонах публичный и приватный ключ, но не контролируем канал передачи, то нет гарантии что мы скачаем публичные ключи друг друга а не злоумышленника. Это и есть MITM.
Взять SSL Handshake - ровно та же ситуация. Мы доверяем certificate authority или ручками впихиваем то что мы считаем доверенным сертификатом в трастстор. Если посмотрите на сайты с дистрибутивами, часто рядом со ссылкой прикладывают хэшкод. Типа качай и проверяй а то ли ты скачал. Но если сайт взломан и хэшкод подменить нет проблем.
Поэтому я и говорю, что нужен второй канал связи, неконтролируемый мессенджером. Голубиная почта там, дым костра и т.п.
Любой месенджер который передает ключ шифрования сам не может считаться безопасным априори. Во всех системах безопасности есть некий "доверенный центр" (certificate authority), скомпрометировав который вся безопасность идет лесом. Что симметричное, что асимметричное шифрование, если есть MITM ваша надежда только на стеганографию.
У нас все было проще, поменяли spring-boot-dependencies с 2.5.2 на 2.5.7 и все заработало. Не надо затягивать с апгрейдом, тогда боль будет лёгкая и равномерная. Сейчас уже на 2.6.1 сидим
Что самое забавное, правила на длину пароля, большие/маленькие символы, цифры и спецсимволы были введены для противостояния всего-навсего одному из векторов атаки - брутфорсу. Все эти ухищрения ни разу не помогают от кейлоггеров и приводят к концентрации паролей или в менеджере паролей или на бумажке или шаблонизации паролей.
Вообще концептуально безопасность определяется ответами на вопросы "Кто я", "Что я имею" и "Что я знаю" и их комбинацией. Пароль это типичный представитель "Что я знаю", 2ФА это как правило комбинация "Что я знаю" + "Что я имею" (телефон, цифровой аутентификатор). "Кто я" это всякого рода биометрия и даже в какой-то мере digital fingerprint устройства.
Запрет на прием аудиосообщений
Вы наволонтерили на 45 лет строгого режима
/sarcasm off
Ну так и опишите что видите проблему в читаемости кода, желательно такими словами который можно понять и принять. Механическое ограничение на длину строки эту проблему не решает от слова совсем.
Как вам там в прошлом? Как доживете до 2009 купите биткоин.
80 символов на строку был стандарт во времена мониторов 4:3. Сейчас стандарт скорее 120, хотя я встречал .editorconfig и 180.
Забавно видеть, как нарушив мыслимые и немыслимые международные договора и соглашения, население России ожидает их соблюдения от других.
Когда соревнуются маркетологи, инженеры отдыхают. А там либо шах, либо ишак - без разницы - деньги уже проедены. С учётом что даже на стороне заказчика куда важнее отчитаться об истории успеха нежели иметь её по факту, очень непохоже что что-то изменится ближайшие двадцать лет.
а там не в exif данные хранятся
https://jit.ndhu.edu.tw/article/download/1681/1689
Это следующий слой паранойи )) собирать из исходников прошедших аудит самому.
Верно, я про это и говорю! Нужен сторонний канал. А насчет Encryption Key и общего ключа, это индикация что ключ не перехвачен еще кем-то кроме владельцев мессенджера.
Есть алгоритмы стеганографии устойчивые к пережатию. Много конечно туда не засунешь но на текст хватит. Я помню читал (вроде близзы) встраивали в Alpha/Closed Beta релизы чтобы иметь возможность отследить утечку. Там народ издевался и с пережатием и кропы и еще чет делали, были очень удивлены как долго watermark выдерживал. Ссылку разумеется сейчас не найду.
Всем нужно уметь пользоваться. Просто если у вас есть недоверенный канал передачи данных, лучшее что вы можете сделать - замаскировать одно сообщение в другом. Стеганография не панацея, там тоже нужно обменяться секретами для начала, а это возвращает нас к вопросу второго канала
Отнюдь, тут вопрос как мы доверяем каналу передачи. Если мы генерируем на обоих сторонах публичный и приватный ключ, но не контролируем канал передачи, то нет гарантии что мы скачаем публичные ключи друг друга а не злоумышленника. Это и есть MITM.
Взять SSL Handshake - ровно та же ситуация. Мы доверяем certificate authority или ручками впихиваем то что мы считаем доверенным сертификатом в трастстор. Если посмотрите на сайты с дистрибутивами, часто рядом со ссылкой прикладывают хэшкод. Типа качай и проверяй а то ли ты скачал. Но если сайт взломан и хэшкод подменить нет проблем.
Поэтому я и говорю, что нужен второй канал связи, неконтролируемый мессенджером. Голубиная почта там, дым костра и т.п.
Любой месенджер который передает ключ шифрования сам не может считаться безопасным априори. Во всех системах безопасности есть некий "доверенный центр" (certificate authority), скомпрометировав который вся безопасность идет лесом. Что симметричное, что асимметричное шифрование, если есть MITM ваша надежда только на стеганографию.
Когда пять предложений в комментарии дают больше информации чем статья
У нас все было проще, поменяли spring-boot-dependencies с 2.5.2 на 2.5.7 и все заработало. Не надо затягивать с апгрейдом, тогда боль будет лёгкая и равномерная. Сейчас уже на 2.6.1 сидим