Сегодня ходил смотреть на море. Потому что похолодало на пять градусов — уже не адские тридцать шесть, а всего лишь около тридцати-двадцати девяти. А возможно, это просто акклиматизация. А предполагал что придется идти медленно и набирать высоту метра 3 на километр. А ощущение было — будто я спускаюсь. Я вышел из села и оказался на дороге, обходящей ферму. Навстречу попался сосед на «Газели»: мы приветливо помахали друг другу, но так не поняли,что каждый тут делает. Если наверно вчера я бы помирал от жары - сегодня было просто тепло.Единственный вывод, который я могу по этому поводу сделать — адски жарко становится тогда, когда температура приближается к температуре тела или превышает её.
Дорога накатана мотоциклистами, есть ещё одна — с другой стороны лесополосы, но та, по которой пошёл я, — это дорога вдоль крутого спуска к железной дороге. Чем ближе к Морскому Чулёку — тем уже становится дорога. Но совсем рядом с Морским Чулёком кто-то додумался поставить скамейку, и ещё метров через 300 — вторую скамейку со столиком. Сидишь за столиком, тут вроде бы всего 100 метров до деревни, но тихо, слышны птицы, иногда собаки лают в деревне.
Дорога накатана мотоциклистами, есть ещё одна — с другой стороны лесополосы, но та, по которой пошёл я, — это дорога вдоль крутого спуска к железной дороге. Чем ближе к Морскому Чулёку — тем уже становится дорога. Но совсем рядом с Морским Чулёком кто-то додумался поставить скамейку, и ещё метров через 300 — вторую скамейку со столиком. Сидишь за столиком, тут вроде бы всего 100 метров до деревни, но тихо, слышны птицы, иногда собаки лают в деревне.
🔥6👍5❤1
Сегодня день системного администратора (последняя пятница июля). Например в Екатеринбурге лет 20 назад мы просто собирались в Дендрарии в центре и тусовались, иногда какие-то конторы пытались возглавить это мероприятие, но так ни к чему и не приходили. Я сколько не старался так и не выяснил происходит на Нижнем Дону что-то подобное или нет
Но немного истории. Тогда был сайт sysadmin.mail.ru и была простая ежегодная тусовка с пивком в дендре ( Дендропарк в центре , сейчас напротив Гринвича). Развлекались тем что пили пиво, кидали мыши на дальность. Некоторые ошивались с бубнами. Я ходил в каске root. Через пару лет парк "закрутил гайки" и начал выгнять эту толпу красноглазиков в девять вечера. К тому времени появился вполне официальный памятник клавиатуре. Из дендры до памятника можно было добраться за десять минут пешком. Соответственно, тусовка продолжалась уже там. Кому-то пришло в голову сжигать символического юзера и с тех добавилась такая сисадминская масленица.
У меня видимо мышка решила что хочет полетать и поэтому сегодня сдохла.
На фото: 2007 год от начала тусовки до сотворения пользователя.
Но немного истории. Тогда был сайт sysadmin.mail.ru и была простая ежегодная тусовка с пивком в дендре ( Дендропарк в центре , сейчас напротив Гринвича). Развлекались тем что пили пиво, кидали мыши на дальность. Некоторые ошивались с бубнами. Я ходил в каске root. Через пару лет парк "закрутил гайки" и начал выгнять эту толпу красноглазиков в девять вечера. К тому времени появился вполне официальный памятник клавиатуре. Из дендры до памятника можно было добраться за десять минут пешком. Соответственно, тусовка продолжалась уже там. Кому-то пришло в голову сжигать символического юзера и с тех добавилась такая сисадминская масленица.
У меня видимо мышка решила что хочет полетать и поэтому сегодня сдохла.
На фото: 2007 год от начала тусовки до сотворения пользователя.
👍8🔥2😁2
Что-то началось.
Как известно, я не только алкаш, который ходит в👁 бар, но иногда чё-то даже шарю в компьютерной безопасности.
Есть такой сервис — Proton Mail, который отличился благодаря Эдварду Сноудену: тот пользовался по слухам именно им. А я сегодня на Хабре увидел публикацию про их приложение для двухфакторной аутентификации типа Google Authenticator. Софтина называется Proton Authenticator — и она open-source. Так что можно, например, утащить её к себе, собрать, провести аудит алгоритмов, потом авторизоваться.
Я кликаю по ссылке в статье и вижу в браузере картинку № 1. Проблема с сертификатом — смотрю, какой именно сертификат, вижу картинку № 2. Кто-то пытается подменить сертификат посредине. Если я соглашусь, этот кто-то сможет расшифровать весь мой трафик.
Я что не выучил список запрещенных сайтов? И этот сайт запрещен?
Как известно, я не только алкаш, который ходит в
Есть такой сервис — Proton Mail, который отличился благодаря Эдварду Сноудену: тот пользовался по слухам именно им. А я сегодня на Хабре увидел публикацию про их приложение для двухфакторной аутентификации типа Google Authenticator. Софтина называется Proton Authenticator — и она open-source. Так что можно, например, утащить её к себе, собрать, провести аудит алгоритмов, потом авторизоваться.
Я кликаю по ссылке в статье и вижу в браузере картинку № 1. Проблема с сертификатом — смотрю, какой именно сертификат, вижу картинку № 2. Кто-то пытается подменить сертификат посредине. Если я соглашусь, этот кто-то сможет расшифровать весь мой трафик.
Я что не выучил список запрещенных сайтов? И этот сайт запрещен?
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔4👍2❤1👎1😁1
Вчера обещал рассказать, как устроена современная авторизация. Но сначала — история.
В древние времена в США можно было попасть на сервер, который тогда называли мейнфреймом, просто зная его IP и список доверенных пользователей. Примеры протоколов — Rlogin. Классический случай взлома — атака Кевина Митника на Цутому Симомору.
Позже появились пароли — секретный набор символов, известный лишь пользователю и серверу. Оптимально, когда пользователь хранит пароль исключительно в памяти головного мозга и подключается через устройства, сертифицированные по безопасности. Пользователь получил больше удобства: теперь не нужно было каждый раз заходить с одного и того же терминала. Однако администраторов эта ситуация озадачила сильнее: любой пользователь теоретически мог стать суперпользователем всего тремя командами.
Так появилось хеширование. Хеш-функция работает только в одном направлении.
Например, у операции умножения есть обратное действие — деление, а вот хеширование идёт строго односторонне. Зная результат хеширования, невозможно легко определить изначальные данные (хотя подбор возможен). Простая аналогия — расчёт контрольной суммы:
Имеем ряд значений:
3,0,4,7,5,9,2,8,3,9,1,1,9,7,3,8,0,6,6,2,4,9,5
Сложив цифры:
3+0+4+7+5+9+2+8+3+9+1+1+9+7+3+8+0+6+6+2+4+9+5=111
Берём последнюю цифру: 1. Это наша контрольная сумма. Измените хотя бы один знак в ряду — изменится итоговая сумма. Обратное восстановление набора цифр по контрольному значению невозможно. Например, последовательность 3,0,4,4 даёт сумму 11, и соответственно, тоже значение 1 по описанному методу. Это называется коллизией.
Компьютерное хеширование устроено чуть сложнее, но принцип похожий.
Следующим этапом защиты стал шифрованный канал передачи паролей, защита хранилищ хеш-сумм и усложнение самих алгоритмов хеширования. Основные атаки превратились в кражи готовых хеш-значений и последующий локальный подбор паролей. Важно здесь именно длина пароля: если потенциальный пароль содержит до 32 различных символов длиной шесть знаков, возможных комбинаций будет ровно 32 в степени 6=1,073,741,824. Перебирая по 10 тысяч вариантов в секунду, понадобится порядка 107 тысяч секунд (≈30 часов).
Наконец пришёл массовый интернет с красивыми сайтами, которыми мы сейчас уже начинаем пользоваться реже в пользу социальных сетей. Но об этом — в следующем посте.
В древние времена в США можно было попасть на сервер, который тогда называли мейнфреймом, просто зная его IP и список доверенных пользователей. Примеры протоколов — Rlogin. Классический случай взлома — атака Кевина Митника на Цутому Симомору.
Позже появились пароли — секретный набор символов, известный лишь пользователю и серверу. Оптимально, когда пользователь хранит пароль исключительно в памяти головного мозга и подключается через устройства, сертифицированные по безопасности. Пользователь получил больше удобства: теперь не нужно было каждый раз заходить с одного и того же терминала. Однако администраторов эта ситуация озадачила сильнее: любой пользователь теоретически мог стать суперпользователем всего тремя командами.
Так появилось хеширование. Хеш-функция работает только в одном направлении.
Например, у операции умножения есть обратное действие — деление, а вот хеширование идёт строго односторонне. Зная результат хеширования, невозможно легко определить изначальные данные (хотя подбор возможен). Простая аналогия — расчёт контрольной суммы:
Имеем ряд значений:
3,0,4,7,5,9,2,8,3,9,1,1,9,7,3,8,0,6,6,2,4,9,5
Сложив цифры:
3+0+4+7+5+9+2+8+3+9+1+1+9+7+3+8+0+6+6+2+4+9+5=111
Берём последнюю цифру: 1. Это наша контрольная сумма. Измените хотя бы один знак в ряду — изменится итоговая сумма. Обратное восстановление набора цифр по контрольному значению невозможно. Например, последовательность 3,0,4,4 даёт сумму 11, и соответственно, тоже значение 1 по описанному методу. Это называется коллизией.
Компьютерное хеширование устроено чуть сложнее, но принцип похожий.
Следующим этапом защиты стал шифрованный канал передачи паролей, защита хранилищ хеш-сумм и усложнение самих алгоритмов хеширования. Основные атаки превратились в кражи готовых хеш-значений и последующий локальный подбор паролей. Важно здесь именно длина пароля: если потенциальный пароль содержит до 32 различных символов длиной шесть знаков, возможных комбинаций будет ровно 32 в степени 6=1,073,741,824. Перебирая по 10 тысяч вариантов в секунду, понадобится порядка 107 тысяч секунд (≈30 часов).
Наконец пришёл массовый интернет с красивыми сайтами, которыми мы сейчас уже начинаем пользоваться реже в пользу социальных сетей. Но об этом — в следующем посте.
❤3👍2👎1👏1
Продолжение , начало
С приходом веба эволюция с паролями повторилась. Конечно, появилось несколько решений для интернет-банков с авторизацией по сертификатам. Но поначалу веб представлял собой простой протокол HTTP — без какого-либо шифрования. Уровень разработчиков, конечно, снизился: теперь это были уже не опытные программисты на C, а больше на скриптовых языках типа Perl, PHP.
На первых порах использовали встроенную в HTTP-аутентификацию. Потом стали создавать красивые формочки. Аутентификация в вебе представляла собой отправку методом POST по HTTP двух полей из формы на веб-странице — логина и пароля. Никакого шифрования, и любой, кто немного напрягал мозги и пользовался снифером, наслаждался тоннами соседских паролей из локальной сети.
Нешифрованные соединения были повсюду: http, smtp, pop3, ICQ. HTTPS был чем-то редким. Банки боролись с этим собственными решениями. Например, в 1999 году — мой банк предлагал специального клиента, становящегося прокси у браузера (и, разумеется, собственную пластиковую карту). В банках помимо паролей раздавались печатные наборы слов. Чтобы зайти в интернет-банк, вводили логин и пароль, после чего дополнительно указать одно из слов набора. Никакие SMS ещё не использовались. На банковских серверах хранилась копия набора слов, а у пользователей имелся распечатанный бумажный список. Это защищало от ситуации, когда начинающие хакеры могли бы подложить клавиатурного шпиона и украсть пароль. И банки старались шифровать соединений.
Потом SMS и сотовые подешевели, а мобильник превратился из предмета роскоши в обычную нужную вещь. К логину и паролю добавились СМС. Сейчас это используют для простой цифровой подписи (типа подписываешь документы, вводя код из СМС). Работает это просто: сервер генерирует случайное число и запоминает его, затем отправляет по СМС. Далее — ввод логина, пароля и кода из СМС. Серверу нужно лишь сравнить то, что он запомнил, и то, что вы ввели из СМС.
Но времена меняются — теперь сервисы не хотят отправлять SMS («капиталисты хотят экономить»). Да и с появлением Android получить доступ к сообщениям на устройстве стало довольно просто. В итоге они придумали программную реализацию старых методов с набором кодовых слов.
Теперь при первой регистрации или аутентификации — считается, что всё защищено должным образом (HTTPS и прочие меры). Система выдаёт случайный набор цифр, который сохраняется в мобильное приложение (например через QR код). Во время последующей авторизации нужно ввести соответствующее слово из мобильного приложения. Само приложение выбирает нужное слово исходя из текущего времени устройства. Но обычно используют вариант с цифрами вместо слова — экономят на локализации.Синхронизация точного времени давно стала стандартной задачей. Если даже немного сбить часы устройства (хотя бы на час), HTTPS перестанет корректно функционировать (точнее не скажу, пусть будет час).
Пример функции с цифрами: есть, например, время — 02.08.2025, 23:05:50 (MSK). На мобильнике пользователя и на сервере разница пусть будет 20 секунд. Разница в 20 секунд легко достижима, если специально не менять настройки мобильника. Алгоритм, скажем, приведёт это время по Гринвичу — 02.08.2025, 20:05:50 (UTC), отбросит секунды — получится 02.08.2025, 20:05. Затем сложим всё вместе:
0 + 2 + 0 + 8 + 2 + 0 + 2 + 5 + 2 + 0 + 0 + 5 = 26
Полученное значение 26 умножим на заранее запомнённое устройством число, допустим, 10. Получится 260. Эту цифру покажем пользователю. Обычно чисел больше, алгоритм сложнее, но общий принцип тот же самый.
То же самое проделывает сервер, пользователю остаётся лишь шустро ввести числа с мобильного устройства, а сервер сравнит полученный результат с переданным значением. В отличие от пароля такие числа каждый раз будут разными.
Задавайте вопросы! Если интересно — расскажу, что ещё придумали злые программисты для аутентификации.
С приходом веба эволюция с паролями повторилась. Конечно, появилось несколько решений для интернет-банков с авторизацией по сертификатам. Но поначалу веб представлял собой простой протокол HTTP — без какого-либо шифрования. Уровень разработчиков, конечно, снизился: теперь это были уже не опытные программисты на C, а больше на скриптовых языках типа Perl, PHP.
На первых порах использовали встроенную в HTTP-аутентификацию. Потом стали создавать красивые формочки. Аутентификация в вебе представляла собой отправку методом POST по HTTP двух полей из формы на веб-странице — логина и пароля. Никакого шифрования, и любой, кто немного напрягал мозги и пользовался снифером, наслаждался тоннами соседских паролей из локальной сети.
Нешифрованные соединения были повсюду: http, smtp, pop3, ICQ. HTTPS был чем-то редким. Банки боролись с этим собственными решениями. Например, в 1999 году — мой банк предлагал специального клиента, становящегося прокси у браузера (и, разумеется, собственную пластиковую карту). В банках помимо паролей раздавались печатные наборы слов. Чтобы зайти в интернет-банк, вводили логин и пароль, после чего дополнительно указать одно из слов набора. Никакие SMS ещё не использовались. На банковских серверах хранилась копия набора слов, а у пользователей имелся распечатанный бумажный список. Это защищало от ситуации, когда начинающие хакеры могли бы подложить клавиатурного шпиона и украсть пароль. И банки старались шифровать соединений.
Потом SMS и сотовые подешевели, а мобильник превратился из предмета роскоши в обычную нужную вещь. К логину и паролю добавились СМС. Сейчас это используют для простой цифровой подписи (типа подписываешь документы, вводя код из СМС). Работает это просто: сервер генерирует случайное число и запоминает его, затем отправляет по СМС. Далее — ввод логина, пароля и кода из СМС. Серверу нужно лишь сравнить то, что он запомнил, и то, что вы ввели из СМС.
Но времена меняются — теперь сервисы не хотят отправлять SMS («капиталисты хотят экономить»). Да и с появлением Android получить доступ к сообщениям на устройстве стало довольно просто. В итоге они придумали программную реализацию старых методов с набором кодовых слов.
Теперь при первой регистрации или аутентификации — считается, что всё защищено должным образом (HTTPS и прочие меры). Система выдаёт случайный набор цифр, который сохраняется в мобильное приложение (например через QR код). Во время последующей авторизации нужно ввести соответствующее слово из мобильного приложения. Само приложение выбирает нужное слово исходя из текущего времени устройства. Но обычно используют вариант с цифрами вместо слова — экономят на локализации.Синхронизация точного времени давно стала стандартной задачей. Если даже немного сбить часы устройства (хотя бы на час), HTTPS перестанет корректно функционировать (точнее не скажу, пусть будет час).
Пример функции с цифрами: есть, например, время — 02.08.2025, 23:05:50 (MSK). На мобильнике пользователя и на сервере разница пусть будет 20 секунд. Разница в 20 секунд легко достижима, если специально не менять настройки мобильника. Алгоритм, скажем, приведёт это время по Гринвичу — 02.08.2025, 20:05:50 (UTC), отбросит секунды — получится 02.08.2025, 20:05. Затем сложим всё вместе:
0 + 2 + 0 + 8 + 2 + 0 + 2 + 5 + 2 + 0 + 0 + 5 = 26
Полученное значение 26 умножим на заранее запомнённое устройством число, допустим, 10. Получится 260. Эту цифру покажем пользователю. Обычно чисел больше, алгоритм сложнее, но общий принцип тот же самый.
То же самое проделывает сервер, пользователю остаётся лишь шустро ввести числа с мобильного устройства, а сервер сравнит полученный результат с переданным значением. В отличие от пароля такие числа каждый раз будут разными.
Задавайте вопросы! Если интересно — расскажу, что ещё придумали злые программисты для аутентификации.
❤3👍3🍾2✍1🤝1