На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо, в яйце — игла, — смерть Кощея

Вот с технологиями примерно тоже самое. Есть сервис, который сделан с помощью другого сервиса, который сделан с помощью другого сервиса, который в свою очередь использует еще один сервис. Как в стандартной байке, что любая сложная задача в программировании решается добавлением еще одного уровня абстракции.

На прошлой неделе активно ковырял опенсорсные проекты.

1. Kong Gateway. Это API Gateway, который работает на OpenResty, который в свою очередь работает поверх Nginx. Написан на куче Lua кода. В целом его можно использовать, если всё достаточно оптимизировать, но это добавляет еще один уровень абстракции и еще одну зависимость.
2. Ory Oathkeeper. Это тоже еще один реверс прокси сервер, но который умеет проверять аутентификацию. Если его поставить перед всеми незащищенными сервисами и написать пару правил по доступу, то можно не кодить аутентификационные механизмы внутри микросервисов, потому что эту задачу он решит сам за себя
3. Emissary. API Gateway для кубернетиса, который сделан поверх Envoy. Блин, я всё еще не дошел до энвоя, но когда-нибудь дойду обязательно и сравню его с nginx.

Сделал простой пример бекенда на Kong+Oathkeeper+Kratos для того, чтобы получить Hello World Rest API с аутентификацией пользователя по кукам. Может поможет кому-то при построении архитектуры.

@retired_on_fire, Андрей Минкин

А царь то ненастоящий! (с) Иван Васильевич меняет профессию.

Программисты и прочие ойтишнеги подвержены синдрому самозванца. Синдром самозванца (англ. Impostor (imposter) syndrome) — психологическое явление (синдром), при котором человек не способен приписать свои достижения собственным качествам, способностям и усилиям. И в последнее время большинство вопросов связаны именно с этой темой. А еще с темой “Где взять мотивацию на постоянное развитие”.

Вообще, эти две темы звучат как хороший запрос к психотерапевту на беседу. Под этим часто скрываются проблемы с самооценкой или с тем, что выставлены неверные ориентиры. Один чувак на прошлом митапе задал вопрос: “Вот я смотрю на код другого человека и потом смотрю на свой и вижу, что мой код ужасен”, а потом переросло в том, что “как бороться с синдромом самозванца”

Вообще, спасибо нашему воспитанию, потому что мы часто сравниваем себя с идеалами. Идеальные мужчины, идеальные женщины (спасибо семье за это), идеальные тимлиды, идеальные продажники, идеальные *вставьте сюда свой вариант*. В своей оценке мы не можем дотянуть до идеала, который сами же придумали. Смотря какой-то код или читая какой-то блог мы часто видим уже результаты большого и сложного пути, который мы не знаем.

Или прокастинация и это “где найти время на обучение, я не могу себя заставить, как мне научиться хотеть себя заставлять?” ну и подобные вопросы. Обычно, я отвечаю на вопросы мотивации в лебедевской манере: “Никак. Оставайтесь там где сейчас”.

Основная вещь, что сравнения идут не с теми людьми. Да, конечно можно использовать какие-то ориентиры, но вы не тот человек, с которым вы себя сравниваете. Вот например, у меня был пример программиста, на которого нужно равнятся. Это Брэд Фитцпатрик. Это человек, который написал memcached, gearman, livejournal и был одним из кор контрибуторов в языке Go. У нас с ним разный путь. У него лучше образование, чем у меня, он работал с другими людьми и в других компаниях. Мне его не догнать. Да и зачем? Да, кого-то всегда будут ставить в пример, но единственный человек с кем стоит себя сравнивать — это вы же сами в прошлом

Не пытайтесь быть идеальным кем-то там, вы всё равно не станете, потому что всегда есть человек, который делает что-то лучше. Да и чаще задавайте вопрос себе, а чего хотите лично вы?

В заключение, есть парадоксальная теория изменений, которая говорит, что изменения начинаются тогда, когда вы знаете, где вы сейчас, а не куда вы хотите придти.

@retired_on_fire, Андрей Минкин

Describe a team experience you found disappointing. What would you have done differently to prevent this?
(с) Любое программерское интервью.

С подготовкой к интервью обычно всё просто. если мы говорим про техническую часть. Поведенческое интервью (на английском behavioral) проходить иногда сложнее и у некоторых могут возникнуть сложности с тем, чтобы придумать ответ на этот вопрос.

Есть хороший видос от jeff H Sipe, который рассказывает про STAR метод, который включает в себя

Situation. Описание ситуации, в которой вы были и что вы решали. Тут важно, что описание должно быть конкретным и понятным.
Task. Какая была цель над которой вы работали?
Action. Какие дейсвия вы предпринимали
Result. К какому результату пришли

Ну и список ситуаций, которые можно обсуждать по этому фреймворку

— Отсутсвие инженерной культуры
— Люди не писали тесты
— Корп культура не позволяла говорить открыто
— были проблемы с доверием внутри команды и это влияло на перформанс общей команды (см пять пороков команды от Ленсиони)
— Не было поддержки новых идей по стеку или подходам к разработке
— Не писалась документация
— Было много созвонов, что влияло на рабочий климат в команде, хотя можно было заменить на обычный емейл
— Не было понятного фреймворка для разрешения рабочих конфликтов
— Не было понятного и девелопер френдли код ревью
— Не было код ревью в принципе
— Не было сиай сиди для поставки в прод
— Были сложные процессы поставки кода в прод с кучей бюрократии
— Было много техдолга и не уделялось время на его закрытие
— Не транслировалось понимание бизнесовой проблемы, которую нужно было решить и была излишняя технократия в проекте
— Не было развивающей обратной связи
— Не было постоянных 1-1 раз в месяц
— Не было карьерных 1-1
— Не уделялось достаточно времени на сбор требований перед оценкой проекта при оценке проекта
— Тимлид выгорел,потому что овертаймил и не было культуры ворклайф баланса
— Перед релизом ушел чувак и мы обосрались со сроками

А какую ситуацию добавите вы сами?

@retired_on_fire, Андрей Минкин

Никто не любит пианистов, все любят барабанщиков!

За последние семь дней было три выступления: в IT-Run, в КГЮА и в аттракторе напишу пару мыслей по этим выступлениям.

IT-RUN

Много прикольных и молодых ребят, которые задают обычные вопросы, на которые я пока еще не устал отвечать. Как устану — напилю пару бложиков и буду кидаться ссылками. Организация мероприятия была приятной, пришел заранее, посидел чуть чуть, ребята не опоздали и пришли тоже вовремя. Побеседовали и разошлись. Даже за выступление заплатили. Наконец-то я пришел к тому, что за выступления платят, хотя в обычную рутину переговоров добавился один вопрос: “Чем платите?”. В итоге, заплатили чуть чуть денег, дали кружку (Она прикольная, кстати. Спасибо большое).

В основном ребята интересовались карьерой и их интересуют всего два вопроса:

— Куда развиваться дальше после курсов
— Как найти первую работу

И я не очень люблю отвечать на эти вопросы, потому что когда я начинал мир был другим, а развиваться можно вообще в любое направление.

Attractor

Люблю обкатать свои доклады в Аттракторе. Он рядом с домом, там работают ребята, с кем мы сотрудничали или даже бухали вместе. Обкатал свой доклад Identity 101 и вышел со следующими выводами

1. Нужно высыпаться (спасибо, кэп). Так сложилось, что я поспал всего 3 часа в этот день, потому что “А давай зайду и сделаю пару квестиков на часик в WoW The Burning Crusade”. В итоге, мы зачистили пару данжей с ребятами на Firemaw реалме и я апнул аж целый уровень.
2. Нужно применять Zero Knowledge паттерн с некоторыми оговорками. В докладе нашел 4 места, где повествование обрывается. Ну и по структуре доклада он получился слабый. Не выходит рассказывать интересно с мемчиками, шутками на серьезные темы.
3. Говорить целую пару (час двадцать) сложно. Под конец доклада я уже сам думал, когда же он закончится.

Доклад нужно будет отправить на переделку и через пару недель думаю будет следующая итерация доклада, только нужно будет чуть чуть добавить интересных историй. Может быть даже за микросервисы получится поговорить.

До понедельника!

@retired_on_fire, Андрей Минкин

English motherfucker! Do you speak it? (c) Pulp Fiction

Let me speak from the bottom of my heart. Today is the unique moment in time 😂

Сегодня про английский. Так сложилось, что я несколько десятков лет учил английский и не говорил на нем. Читать было достаточно просто, понимать тесты тоже, а говорить сложно. Всё изменилось после того, как мой доклад приняли на FOSDEM в 2018м чтоли году. Ну и нужна заставила, ведь у меня было ровно два месяца на то, чтобы улучшить свой английский.

Я пошел сначала в English Zone и там начал просто говорить. Местами не грамотно, но начал. Потом взял подписку на ororo.tv и начал пересматривать все сериалы в оригинале. Познакомился с Диваном, начал с ним общаться и открыл для себя целый мир экспатов в Бишкеке. Узнал о паре баров, где можно встретить нейтив спикеров и так в общем-то понеслось.

Преодолеть барьер помогло просто понять, что на русском говорю также безграмотно, как и на английском и с этого начался мой путь.

Кратко о грамматике английского.

1. В любом предложении всегда есть глагол. Нет глагола — нет предложения. Когда нет глагола, то всегда есть глагол to be.
2. Вопросов в английском языке всего пять типов и они достаточно просты
2.1 Общий или закрытый вопрос. На него можно ответить коротко, например Do you drink beer?
2.2 Вопросы, начинающиеся со специального слова (wh*). What did you do yesterday?
2.3 Таговые вопросы, которые хороши для сарказма или уточненения. Строятся по формулам -, +? или +, -?. You don’t like beer, do you? или You are always calm in stress situations, don’t you?
2.4 Альтернативные вопросы, где есть слово или. Например: Do you or does she go to school?
2.5 Ну и как костыль, который во-время порефакторили в английском — это исключения из симплов. Если вопрос начинается на Who и у нас время либо презент, либо паст симпл, то можно дропнуть вспомогательный глагол. Who catches the dog?
3. Английский язык достаточно хорошо спроектирован и в нем меньше говнокода, чем в русском и все предложения чаще всего строятся по SVOMPT (Кроме случаев инверсии, но инверсия нужна только магистру Йоде)

В продолжение последнего пункта, предложения всегда строятся по следующей формуле

1. Подлежашее
2. Сказуемое
3. Дополнение
4. Временные ключевые слова

Кстати. Времена в английском — это не время в привычном понимании, а больше задокументированные случаи передачи контекста. О, а самое любимое, что в целом можно встретить достаточно странные грамматические конструкции, типа

1. Are you dead yet?
2. Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo
3. James while John had had had had had had had had had had had a better effect on the teacher

Так что в любом языке есть свои приколы.

Продолжаю делиться советами по изучению английского и поддержания формы.

Хорошо помогают в изучении английского

— Duolingo и LinguaLeo. По 10-15 минут можно потратить на поддержание формы в том или ином языке. Кстати, перед поездкой во Францию я французский учил по Duolingo, однако когда попал во Францию, то понял, что произношение в приложении и в жизни — два разных понятия. Например досвидания au revoir (о ревуа) часто произносится как оэуа.
— Сказки. Читать и слушать. Обычно там простой язык и можно хорошо натренировать мозг. Можно смотреть с субтитрами, но если мы занимаемся и прокачиваем Listening, то желательно выключать субтитры, записывать что услышал и потом проверять с тем, что написано в субтитрах. А еще хорошо читать Хемингуэя в оригинале. Он прост. Он краток. Он быстро погружает в контекст рассказа.
— Изучать разные диалекты. Есть ньюансы в диалектах и часто даже нейтивы друг друга не понимают. Ну или вот тоже хороший прикольный пример

@retired_on_fire, Андрей Минкин

Надо больше контента богу контента

Чем больше англоязычного контента вы будете поглощать, тем лучше.

— У Джеймса с Engvid куча полезного контента с хорошими советами по грамматике и оборотам.
— Хорошей идеей может быть приобретение подписки на netflix и смотреть все сериалы в оригинале. Обычно это два разных сериала в зависимости от озвучки.
— Акцент — это последнее о чем нужно переживать. Весь мир говорит коряво. Чтобы убедиться в этом, достаточно просто поговорить с жителями индии, хотя у нас в команде есть SRE с очень понятным произношением.
— Диалекты. Чем больше диалектов вы узнаете, тем лучше. Иногда смотрю канал Спик изи и он мне помогает в общении с людьми из разных регионов.
— Писать на английском. Если нет постоянной разговорной практики английского языка, то можно заменить сочинительством. Можно пилить или блогпосты, или писать какие-то рассказы, главное писать. Особенно гуглдоки или граммарли хорошо помогают в написании контента и расширении словарного запаса.

Чтобы говорить на английском — нужно говорить на английском, а не ходить на курсы, где вас будут дрючить грамматикой и правилами.

@retired_on_fire, Андрей Минкин

Современное стартаперство для валидации идеи должно быть дешевым и благо, что есть куча сервисов, которые позволяют это сделать. Вот любой сервис можно сделать и хостить почти бесплатно до определенных лимитов.

1. Чтобы сделать аутентификацию есть Ory Cloud или Auth0. Просто подключил и даже особо настраивать не нужно
2. Для того, чтобы сделать API на Graphql, которая будет удобной и безопасной есть hasura.io
3. СМСки отправлять можно через twilio, также как и делать звонки.
4. Любое облако позволяет делать хостинг эффективным с помощью их облачных функций. Например Cloud Functions от Google Cloud Platform или AWS Lambda от AWS.
5. Для лендосов есть тильда или WiX. Или связка Hugo+github pages.
6. Для платежей есть stripe

Это очень сильно экономит время, чтобы понять взлетит идея или нет. Пришел микрофон и звуковая карта, подтянут свои скиллы монтажа и накидайте пожалуйста темы или вопросы, которые хотелось бы раскрыть? Я закину это на свой ютюб канал.

@retired_on_fire, Андрей Минкин

Convey. Don’t convince.

Вот эта фраза максимально продуктивно работает в моем случае. Если перевести дословно, то “Сообщай, передавай, но не убеждай”.

Большинство продавцов часто пытаются впарить и говорят красиво, как Сека в этом мемчике. Во фразе выше вспоминается история на моем первом хайлоаде. Были два стенда одних и тех же продуктов конкурентов, которые делали какой-то продукт рядом с аналитикой.

Разговор с первым чуваком был примерно следующий

— Привет, мы такой-то продукт, делаем вот это и это
— ОК, а чем можете быть полезны?
— Вот у вас какое среднее время ответа от ваших API?
— 20мс
— Мы можем это улучшить.


Второй чувак напротив вел следующий диалог
— Привет, а что вы делаете?
— Тоже, что и они
— А чем вы лучше?
— Да ничем почти
— А как вы можете нам помочь?
— У вас какое среднее время ответа от ваших API?
— 20 мс
— Улучшать нужно?
— Неа
— Мы вам не нужны

Я не помню какие были компании, но помню второго чувака. В этом случае он продал лучше продукт, потому что он не впаривал, а узнавал решит ли это мою проблему или нет?

Так вот, сейчас я пользуюсь принципом Convey. Don’t convince, просто потому что мне нужно выстраивать долгосрочные и доверительные отношения со своими клиентами.

Я же айтишник. Зачем мне изучать законы?

Поговорим про законы и остальные вещи, которые лежат вне кода. Программирование похоже на постройку дома и для любой программы нужен хороший фундамент. Если фундамент плох, то поддержка продукта будет печальной. Когда планируется и строится архитектура, то нужно учитывать пять вещей

1. Безопасность.
2. Доступность
3. Цена поддержки
4. Производительность
5. Легкость эксплуатации.

Однако, очень часто накладываются дополнительные ограничения в виде правовых актов (например закон о хранении персональных данных) и требования дополнительных коплайнсов: PCI-DSS, HIPAA, GDPR

Знать комплайнсы хорошо, потому что они добавляют множество ограничений на наш продукт и могут сэкономить нам время и деньги. К сожалению, многие команды упускают очень важный этап сбора требований и ресерча вокруг архитектуры. Достаточно найти пару подходящих решений и этого хватает для старта проекта. А дальше всё приводит к тому, что проект обрастает, становится монструозным и приводит к тому, что “а давай всё с нуля перепишем”.

в Modern Application Framework есть шесть вопросов, которые хороши для того, чтобы ограничить себя в выборе инструментов

- What are your business priorities? Этот вопрос хорош хотя бы тем, что получив ответ в двух-трех предложениях становится понятно что делает продукт.
- What is the worst possible scenario? Помогает минимизировать риски утечек данных и понять что на самом деле важно
- What are your immovable constraints? Этот вопрос обычно как раз про комплайнсы и Legal часть. Я надеюсь все знают, что данные банковских карт нельзя хранить в незимененном виде
- What data is this solution storing/processing? Помогает при проектировании систем контроля доступа
- What skills does your team have? Важный вопрос, потому что в любом случае нужно будет тратить время либо на обучение команды, либо убирать сложные решения
- What is the timeline for the project? Ну, без дедлайнов никуда.

Эти шесть вопросов заставляют искать оптимальные решения для проектов.

@retired_on_fire, Андрей Минкин

Советы для тех, кто хочет стать программистом.

К сожалению есть много сообществ программистов, которые захвачены вахтёрами или людьми с этим синдромом. Вместо помощи обычно просто отправляют читать документацию. Такое есть и в англоязычных и в русскоязычных сообществах. Но в последних это встречается чаще всего.

Начинать можно с любого языка программирования, но стоит начать изучение с английского. Он в любом случае будет нужным в вашей жизни, так что комментировать тут не вижу смысла ничего. Просто начните изучать английский.

Следующим пунктом нужно прокачивать дисциплину. Дисциплина это важный столп, который помогает воспитать в себе самостоятельность и находчивость. По этой теме лучше всего подойдет почитать книгу Jocko Willink - Discipline Equals Freedom.

Любознательность. Основа любого обучения — это интерес к теме. Без любознательности никуда. Особенно в программировании, где множество пересечений разных сфер и технологий. У нас есть и e-commerce, и fintech, и edtech, и еще куча всяких *tech.

Самостоятельность. После 18 лет вас никто не обязан учить. Вы сами по себе и вы взрослый человек. А значит за всё, что происходит в вашей жизни нужно будет отвечать только вам и никому больше. Эту простую вещь мало кто понимает и почему-то до сих пор встречаются еще “А за что я деньги плачу?” при обучении. А еще хуже, когда это в работе. Была поставлена задача, тобой был озвучен срок. Значит нужно уложиться в этот срок, либо передвинуть его предложив план Б. Детский сад разводить не стоит и говорить что “Это вообще-то менеджер делать должен”. Так вот, в интернете действительно есть много информации и задавать вопросы нужно уметь, также как и находить решение проблемы самостоятельно.

Упорство перед лицом проблемы. Программирование — это решение проблем. В коммерческой разработке — это решение проблем бизнеса. Бизнес платит вам деньги за то. что вы решаете проблему с которой он столкнулся прежде всего. Чем больше проблем с которыми вы столкнулись вы решите — тем опытнее вы станете. По опыту скажу, что люди, которым дается обучение дается сложнее, но они берут упорством добиваются куда более интересных позиций в своей карьере, чем те, которым дается всё легко.

@retired_on_fire, Андрей Минкин

Небольшая история аутентификации (это часть моего доклада Identity 101)

— В начале 60х годов не было паролей вообще. Потому что нужды не было
— Хотя в начале 60х придумали пароли для Compatible Time Sharing Machine. Они хранились в открытом виде
— В конце 60х придумали хоть какое-то шифрование паролей.
— В начале 70х придумали ассиметричное шифрование, которое повышало безопасность и криптостойкость паролей
— В середине 80х придумали алгоритмы для TIme Based One Time Password (Это генерация одноразового пароля в приложениях типа Google Authenticator), который был сделан поверх HOTP (HMAC based one time password). Разница в том, что HMAC использовала обычный счетчик, а TOTP использует системное время для генерации паролей
— В конце 90х годов была придумана инфраструктура для обмена публичными ключами
— В середине 90х придумали капчу
— В начале нулевых придумали MultiFactor authentication и Single Sign-on
— В начале 10х стала популярна биометрия для аутентификации (Фейс айди, тач айди и так далее)

Сейчас же лучшей практикой является использование MFA везде, причем по приложениям типа Google Authenticator, потому что SMS не так безопасно.

SMS передается обычным текстом без шифрования и его можно легко перехватить.

@retired_on_fire, Андрей Минкин

Ну, теперь я на фронте. Сижу, прогаю спокойно себе фронтенд для проекта сокращения ссылочек с аутентификацией из коробки.

Сижу, смотрю туториалы всякие и люди до сих пор программируют аутентификацию по логину и паролю на бекенде, даже используя стандартные инструменты.

Есть ошибочное мнение, что аутентификация через соц. сеточки заменит аутентификацию по логину/паролю, просто потому что ничего не нужно будет кодить дополнительно. Однако, это не так.

В любом процессе аутентификации нужно:

1. Проверять телефон или емейл (в зависимости от того, что мы делаем) послав на указанный реквизит сообщение для подтверждения. Валидация нужна в современном мире для любого продукта.
2. Нужна фича смены пароля. Пользователь может его забыть. Восстанавливать можно либо по почте, либо по смс.
3. Любые пароли сейчас нужно шифровать и хранить в зашифрованном виде, желательно посолив
4. Работая с социальной аутентификации нужно сохранять пользователю возможность либо восстановления пароля, либо аутентификации по паролю, если у него привязана почта.

Почему важен последний пункт? На это есть несколько причин

1. Пользователя может забанить Фейсбук или любой другой провайдер социальной аутентификации
2. Пользователь может передумать и отвязать свою учетку, сославшись на свое решение.
3. Не всегда соц.сети выдают емейл, который чаще нужен для бизнеса при аутентификации, либо нужно пройти дополнительный путь для этого.

А с фронтендом у меня пока хорошо. Для простых проектов без дизайна и когда ты что-то пилишь сам сейчас всё достаточно просто, если пользоваться фреймворками, типа Tailwindcss. Не нужно помнить про кучу свойств в CSS и просто сосредоточиться на построении интерфейса.

На JS стало программировать приятнее благодаря TypeScript. Но, пока я на начале пути и может быть мнение мое еще изменится. Но блокироваться тем, что я не хочу/не могу/не умею во фронтенд уже больше не хочу. Пока что ковыряю связку Vue+Nuxt+TailWindCSS. Посмотрим что получится

@retired_on_fire, Андрей Минкин

Безопасная аутентификация в вебе на сегодняшний день никак не одходится без MFA.

MFA — это мультифакторная аутентификация. Ее еще иногда называют 2FA (типа двухфакторная). Но всё же 2FA — это частный случай MFA.

Чтобы понять в чем тут дело, расскажу про аутентифкационные факторы. Они бывают следующих видов:

— Фактор знаний. То, что мы знаем. Тут может быть пароль или часть пароля, passphrase, персональный идентификационный номер (ИИН), ответ на сесурный вопрос или что-то еще, что знает пользователь.

— Фактор владения. Например телефон, со встроенным хандварным токеном для аутентификации, браслет, USB-донгл, ID карта, имплантированный девайс

— То, чем мы являемся. Это цепочка ДНК, подпись, голос или любая другая биометрия.

Когда мы звоним в банк, чтобы узнать состояние счёта или задать вопрос и когда проходим процедуру идентификации, то мы обычно пользуемся фактором знаний. Например: ответ на секретный вопрос, предъявите ваш клиентский номер, назовите фамилию имя и отчество.

Если мы аутентифицируемся по логину и паролю без дополнительных шагов — это тоже однофакторная аутентификация. Даже если вводим ответ на секретный вопрос или какой-нибудь дополнительный пароль, который мы знаем.

Пример двухфакторной аутентификации — это прохождение погнаничного контроля с дополнительными вопросами от пограничника. Мы предъявляем пасспорт (то, чем мы владеем) и дальше пограничник может задать дополнительный вопрос, например меняли ли вы фамилию и какой она была до смены?

В вебе пример двухфакторной аутентификации — это использование приложения, которое генерирует одноразовый пароль, например гугл аутентификатор, который безопаснее чем SMS. Вот хорошая статья почему SMS небезопасно для аутентификации

@retired_on_fire, Андрей Минкин

Опять немного языковая тема. В русском языке значение слова может поменяться в зависимости от поставленного ударения, например трусы. В английском есть тоже самое. Например record. Но это еще не самые прикольные вещи в английском.

— Bow и Bow могут произноситься по-разному. Это и боу (в значении стрела) и бау в значении поклониться. Это пример, когда слова пишутся одинаково, но происносятся по-разному
— Bow и Bough пишутся по-разному, но произносятся одинаково
— ough окончание может ломать мозг даже нейтивам. Yes, English can be weird. It can be understood through tough thorough thought, though
— New direction звучит также как nude erection
— Есть тройные сокращения. Например you'dn't've, что произошло от you + wouldn't (would + not) + have.
— Laid is pronounced like paid but not said and said is pronounced like bread but not bead and bead is pronounced like lad but not lead
— Есть еще предложения из одного слова. Например Police police Police police Police police Police police. Зачем? Я хз.
— Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo
— Доставка по морю называется Cargo (car + go), хотя доставка по суше называется Shipment(ship+ment). Есть еще приколюхи типа we bake cookies and cook bacon
— James while John had had had had had had had had had had had a better effect on the teacher
— Машины паркуются на driveway и едут по parkway 😄
— Polish — это и поляк и полировать. Using chemicals to remove the polish. Это хорошее предложение. Но, using chemicals to remove the Polish, это не очень хорошее предложение и очень опасное =)

Так что… учите разные языки. А какие приколюхи вы знаете в английском или любом другом языке?

@retired_on_fire, Андрей Минкин

Продолжим говорить про аутентификацию.

В прошлых статьях мы рассмотрели всё, вплоть до аутентификационных факторов. Однако, мы не рассматривали еще безопасное хранение паролей. Так вот, пароли нужно хранить в зашифрованном виде, без возможности расшифровки и желательно еще посолив. В современном мире криптостойкость md5 и sha уже под вопросом и поэтому стоит посмотреть на bcrypt и scrypt. Но в любом случае, щепотка рандомных данных в алгоритме шифрования не помешает.

Помимо этого стоит держать в голове, что в принципе ничего ненадежно и есть следующие векторы атак на наш сервис аутентификации

1. Подбор пароля
2. Перехват данных
3. Фишинговые атаки
4. Атаки социальной инженерии
5. Внутренние угрозы

О противостоянии угрозам я расскажу в следующем посту, но если что, то правильная реализация конфигурации хранения паролей, TLS и настройка 2fa решает большинство проблем.

Стандарты для 2FA:

— U2F
— HOTP
— TOTP

Но, если предположить, что нет паролей — нет проблем, то привет еще следующие чуваки:

— UAF
— FIDO2/Webauthn

Чуть подробнее расскажу про аутентификацию без пароля в следующем посте

@retired_on_fire, Андрей Минкин

В прошлом посте мы говорили про векторы атак и про какие-то непонятные стандарты для аутентификации. Так вот, чуть подробнее о каждой теме.

Группа “Угадай пароль за 300”

— Брутфорс. От брутфорса защищаться достаточно просто и нужно всего-лишь добавить задержку на следующую аутентификацию, желательно, чтобы еще был Exponential backoff. А еще проверять пароль на силу. Хотя, последнее сомнительно, потому как лучше проверять пароль по базе утекших паролей при регистрации
— Угадывание по словарю. В дополнение можно напилить сервис антифрода, но вполне хватает рекомендаций от брутфорса
— Радужные таблицы. Использовать bcrypt и правильные политики работы с солью. Это усложнит подбор пароля

Группа “Перехват данных”

— Снифинг вай-фая. От этого хорошо защищает SSL. Не самоподписанный, а вполне себе легальный
— Man-in-the-middle. Вполне хватает SSL для защиты
— KeyLogger на компьютере жертвы. Вот тут как раз таки привет 2FA. 2FA защищает еще и от следующего типа атаки
— Шпионим за экраном.
— Утечка куки. Казалось бы я иногда бешусь с того, что gitlab у меня постоянно отваливает сессию, однако короткая жизнь сессии в этом случае может защитить от этого вида атаки. Помимо этого еще можно втащить Oauth2. Но в любом случае разделение привилегий тут обязательно
— SSL уязвимости. Тут нужна процедура аудита безопасности и проверки конфигурации SSL
— Утечка истории браузера/Referer хедеров. В этом случае урлы не должны содержать персональных данных.

По последнему пункту прям спасибо GDPR и HIPAA комплаенсов. Сразу накладывают ограничения и делают интернет чуть чуть более безопасным местом

Фишинговые атаки

— Фишинг страниц аутентификации. Привязывать куку к айпи адресу пользователя
— Подмена Man-in-the-Middle и DNS Poison. Как защиту использовать SSL вместе с PKP и HSTS. Хотя PKP уже задепрекейтили в пользу Certificate Transparency
— От Browser Poison поможет настроенная 2FA работающая на OCRA
— Перехват Connect. CSRF токены тут помогут на всех формах аутентификации

Социальная инженерия

— Если так получилось что вашу базу с настройкой 2fa слили, то дополнительные фичи в виде уведомлений о пользовательской активности могут быть хорошей защитой для ваших пользователей. А также сервисы антифрода и процедуры блокирования активности
— Утечка пароля. 2FA и Oauth. Еще было бы неплохо логгировать попытку логина с непонятного места
— Атака через восстановление доступа.
— Кража устройства. Процедуры разрешения/блокирования доступа

Внутренние угрозы

— Утечка сессий со стороны сервера решается короткой жизнью сессии
— Утечка паролей с сервера. Решается использованием bcrypt с правильным использованием соли
— Перехват внутреннего трафика. Решается тем, что используете SSL между сервисами, внедряете менеджмент ключей и сертификатов ну и еще короткое время жизни сертификатов может тут помочь
— Утечка логов. Нельзя писать личные данные в логи, особенно креденшлы и секреты.

Чем дополните?

@retired_on_fire, Андрей Минкин

Виды аутентификации без пароля.

— Магическая ссылка, которую отправили на верифицированный емейл или номер телефона. Обычно в нее зашифрована сессия или токен, проверив который мы можем просто залогинить человека, если он перешел по ней. Так иногда делают в рассылках.
— Аутентификация по SSL сертификатам. В этом случае у нас на сервере хранится сертификат, которым мы подписываем все остальные сертификаты и выдаем их пользователям. Может быть достаточно сложной по времени процедурой
— Аутентификация по публичным ключам. Работает почти также, как и аутентификация по сертификатам, только занимает чуть меньше времени.

Добавить хочу еще разницы между U2F(Universal second Factor) и FIDO 2 с поста на этой неделе. Как работает U2F?

— Мы вводим логин и пароль, как обычно.
— Система требует у нас дополнительный ключ.
— У нас есть какая-то флеха, на которой записан ключ.
— Ее нужно воткнуть в компьютер
— Далее по протоколу CTAP вся эта балалайка проверяется
— Нас пускает в случае успеха в систему.

FIDO2 позволяет позволяет нам не использовать внешний аутентификатор, а использовать наш девайс и его внутренние механизмы аутентификации, например фейс айди на телефоне или любую другую биометрию.

В отличие от U2F, где есть пароли, в FIDO2 аутентификация идет только по публичным ключам. Правда, пока как это всё дело менеджить я не разобрался. Как разберусь, обязательно расскажу о впечатлениях. Но демку можно поковырять на главной webauthn.io

@retired_on_fire, Андрей Минкин

Больше контента богу контента.

Разобрался я со своим сетапом Shure SM7b + Focusrite. Установил дрова, выкрутил гейн и поигрался со всякими настройками для звука. Могу сказать, что это одна из лучших покупок в последнее время. Качество звука улучшилось в разы (правда этого не скажешь на примере с конгом, где звук только в правом ухе.

Покрутил настройки и в OBS и в премьере, позалипал в обучалки по обработке звука и на ютюб канале готов пилить кучу контента и на русском языке тоже.

В планах сделать несколько видосов на русском/английском языках. Примерные темы

- IAP Proxy. Что это, зачем, когда использовать и вообще зачем сейчас весь этот Zero Trust
- Что есть в опенсорсе, что можно использовать сейчас и сэкономит вам время
- Обзор Planetscale, Hasura, Supabase как БД для проекта.
- Что-то про карьеру? По-хорошему стоит запилить пару видосов на эту тему, но тут нужна помощь аудитории.

С обучающимися на курсах всё понятно. Им нужно найти работу. Кстати, если есть прям начинающие ребята, которым не помешает помощь с резюме и кто будет рад поделиться своим резюме как примером, то напишите в личку плиз. Хочется сделать сравнительный обзор по резюме, чтобы советы были более дельными.

Для джунов и миддлов я не знаю что рассказывать. Какие темы стоит осветить? Накидайте в комментариях плиз

Не могли бы Вы пожалуйста дать рекомендации новичку. Что угодно - книги, видосы, планирование времени(или сколько времени в день нужно уделять именно кодингу), прокачка скиллов для работы - что вообще поможет стать хорошим специалистом с Вашей точки зрения.

Спасибо за вопросы в личку. Если вы не знали, то меня можно просить о чем-то ответить в этом уютном бложике просто написав в телеграме и задав вопрос. Я на него подробно отвечу. Так что в течение этой недели отвечаю на вопрос про рекомендации новичкам

Начать нужно с того, что в процессе любого обучения нужно знать про свою конечную цель. Вот вы начали обучаться программированию, а дальше что? Будете свой стартап пилить? Или вы хотите работать программистом? Или что-то еще? Если работать, то где? В стартапе? В большой компании? Звучит просто как хороший вопрос для того, чтобы посидеть, подумать, поресерчить плюсы и минусы работы в той или иной компании и начать потихоньку готовиться к интервью.

Также, отдельным пунктом нужно добавить выбор области. Это веб разработка или что-то другое (фронтенд, бекенд, мобилки, дата сайнс, МЛ и АИ). К сожалению, программирование на Javascript затронет всех в этой жизни и от этого никуда не деться =(

Выбор первого языка программирования — это английский, потому что это единственный универсальный язык в индустрии и самый популярный на текущий момент. В любом случае за карьеру вы смените не один язык программирования. В моем случае были C/C++/C#/Perl(прости хоспаде)/.NET compact framework/JS/Ruby/Python/Go/и немного Erlang. На всех этих языках я либо делал какие-то прототипы, либо запускал код в продакшн. Но в любом случае принципы программирования остаются в любом случае одни и те же.

Дальше, стоит выбрать вашу любимую IDE/редактор текста. Тут в любом случае можно пойти либо от монструозных продуктов типа Jetbrains, которые могут упрастить вам жизнь, так и ухудшить вашу производительность. Кому-то нормально программировать на ViM, кому-то норм пользоваться автодополнением и всякими сниппетами, кому-то нет. Я сижу на ViM по ряду причин:

— Я печатаю быстрее, чем мне пытается подсказать редактор текста
— Автоподсказки иногда советуют не то и приходится исправлять
— У ViM куда больше инструментов для редактирования текста, например удалить всё в кавычках или до фигурной скобки. Ну и пока ни один другой редактор текста не переплюнул функционал

Выбрав язык изучайте сначала простые фундаментальные вещи и начинайте присматриваться к фреймворкам. Но сначала нужно изучить фундамент.

Дальше расскажу про дополнительные ресурсы для обучения

@retired_on_fire, Андрей Минкин