Виктория Бородина сделала неплохую базовую табличку по иммиграции, довольно интересно глянуть. Тема, конечно, сложная и много нюансов по каждому из пунктов, но в целом - маст си.

Польша улыбнула. Всё в целом закономерно и в двух словах - лучше там, куда сложнее всего уехать. Законы конкуренции они такие.

[20min] : https://www.youtube.com/watch?v=5aexqRQeLNE

#иммиграция

Очередное крутое интервью. Про работу в гугле, пет-проекты ну и в первую очередь личная история.

https://www.youtube.com/watch?v=53nKPT7L0Do

#video

Про goto: помнят многие олды (привет turbo pascal!) , но есть ещё более весёлая штука 😁😁 #радиот

Немного из мира сигналов. Которые по проводам бегают.

Если кто-то увлекается автомобилями и подписан на ютуб канал "ИЛЬДАР АВТО-ПОДБОР", те знают, что у него есть рубрика "оживление мертвеца". Её суть в двух словах : ребята выезжают на сложные "баги" в автомобилях и стараются найти их причину/пофиксать. Вы все понимаете, что более ли менее современный автомобиль состоит из сотен электронных систем/схем/блоков и так далее. И зачастую, по очень разным причинам это всё ломается и сбоит. Особенно со временем.

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

В данном ролике ребята оживляют BMW x5 e53, и используют осцилограф для дебага! Тут же и разъясняют как это всё работает. Оч крутой контент, имхо.

Советую к просмотру :) Таймкод проставлен, длительность просмотра ~5 минут.

https://youtu.be/06cWmc2Zpnk?t=1359

У Dev Jungles вышло очень крутое трёхчасовое видео в стиле "вопрос-ответ" по .net/C#. Имеет смысл смотреть всем дотнетчикам от middle+, много хардовых вопросов.

Было интересно, допустим, почему нельзя делать lock на string и в целом про интернированные строки, и например то, что

string s = "qwe"+"rty"+"uio";

будет на этапе компиляции развёрнуто в string.concat (есть нюансы, не всегда). Или по какой причине нельзя лочиться на структуры. + типичные области применения TCP vs UDP. В общем, много интересных моментов.

Единственное что, заметил, что перепутан ответ на вопрос про "Аутентификацию/Авторизацию/Идентификацию" - первое и второе нужно местами поменять в ответе. Авторизация - роли, Аутентификация - проверка логина/пароля.

Маст си, добавляйте в закладки, редкий контент. Ну и подписывайтесь на автора - хоть канал и молодой, незаслуженно мало подписоты.

#csharp #библиотека_знаний

https://www.youtube.com/watch?v=M32SEu0hY7w

Как бы вы реализовали форму логина и пароля/регистрации на сайте крупного заказчика?

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

Хорош этот вопрос потому что это задание можно сделать как "на коленке", так и "по всем канонам" - зависит от знаний конкретного дева и тз. А так же не привязывается к конкретному языку. Что nodejs, что .net, что PHP - на ответы это не влияет.

Попробуйте потратить минут 5-10 на обдумывание как бы вы ответили на этот вопрос, а после - пункт-за пунктом открывайте чеклист ниже и проверьте себя. Красным флагом 🚩помечены вопросы, на которых можно "засыпаться" и оставить плохое впечатление о себе :)

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

Опустим визуальную ui часть, допустим её предоставили. И так ... поехали!

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

Junior level

1) 🚩Нужно ли скрывать вводимый пароль на странице?
Это очевидно, но это и первый пункт! :) У input есть специальный аттрибут password для этого.

2) Должны ли вадидироваться поля для ввода на ui?
Как минимум на то, что поля не пустые - должно. Отправлять пустую формочку на сервер не комильфо, т.к. нагружает сервер почём зря 😉

3) Запрос идёт GET или POST'ом? Правильнее делать POST'ом.
Ничего вам не мешает сделать это любым другим методом, однако принято данные формы слать всегда POST'ом. Как минимум данные не шлются в URL, что может сыграть злую шутку при логировании. Плюс после POST запроса если у вас отвалится интернет соединение - браузер переспросит вас хотите ли вы заново отослать эту форму? - вы наверняка видели такую. Все GET запросы перепосылаются браузерами без подтверждения.

4) Сохраните ли вы в пароль при регистрации "как есть" в текстовом виде?
Если да - это очень плохо и непрофессионально. Пароли должны быть в идеале зашифрованы стойким алгоритмом по ключу, а в идеале хэшированы - без возможности их "восстановить" даже админами. И Base64 тут не подойдёт :) Не говоря уже о том, что если вашу базу сольют - у злоумышленника окажутся все пароли ваших пользователей.

5) Нужно ли проверять вводимые данные не только на UI стороне, но и на сервере? Двойная работа?
Главное правило веб разработчика - не доверяй клиенту (браузеру) - все данные/поля могут быть отосланы или подменены другими средствами, вам нужно обязательно делать полный цикл проверки на сервере.

6) Нужна ли валидация на сложность пароля или можно не париться?
Заставлять пользователя придумать пароль в соответствии с правилами - маст хэв. Но тут важна грань, т.к. знаю реальный пример, когда правила пароля настолько сложные, что пользователи потом хранят эти пароли в текстовых файлах на рабочих столах, т.к. запомнить их нереально. А это еще хуже :) Получается, заботились о безопасности, а по факту родили новый вектор атаки

Middle level

1) Соединение защищено по https?
Если нет, то у меня для вас плохие новости - ваш логин и пароль может быть легко перехвачен между браузером и сервером. Публичными вайфаями, на уровне провайдера или даже на уровне уязвимого роутера, которым вы пользуетесь. Весь сайт в теории может быть по http (лучше бы нет), но форма логина и регистрации - только https. Но даже в таком случае - токен аутентификации сможет быть перехвачен (но не логин и пароль). Весь сайт обязан быть https.

2) 🚩Нужно ли при неудачной попытке регистрации писать, что такой пароль уже существует в системе?
Конечно нет, это может говорить хакеру о том, что пароли хранятся в plain text и уже какой-то пользователь точно существует с таким паролем. Вы должны выдавать МИНИМУМ информации всего, что касается безопасности. Есть шуточная версия в виде сообщения "такой пароль уже используется пользователем %username%". Шутки шутками, но возможно где-то и написали.
На aws к слову максимальный уровень - после ввода логина, сразу же запрашивают пароль И второй фактор, т.е. злоумышленни даже может узнать что именно не подошло.

3) Если попытка входа была неудачная - нужно ли логировать данные формы для дальнейшего изучения проблемы?
Нельзя. Максимум - логин. Пароль - нельзя. Был уже ни один и не два инцидента, когда у крупных сервисов ломали системы логов и вытаскивали пароли, которые логировались в plain text (лог шёл всего реквеста).

4) Если хэшировать пароль, то как? Каким алгоритмом? Хорошо, если мидл назовёт парочку, допустим md5 или sha-1.
Вопрос чем они плохи - уже скорее сеньорский левел. Но для мидла и такой ответ ок. Так же плюсом в карму будет рассказ о том, что хэшировать нужно с солью. SALT - это что-то, что добавляется к паролю чтобы уменьшить риск его обратного преобразования в случае утечки данных. Многие популярные пароли уже находятся в базах (так называемые Rainbow tables и хеши к ним подобраны, поэтому реверснуть какой-нибудь md5 без соли - дело несложное.

Senior level

1) Каким еще способом нужно обезопасить форму? CSRF имеет смысл добавлять?
Это вопрос на самом деле в целом на понимание CSRF вида уязвимости, сеньор должен знать и понимать как это работает. Безусловно, запрос должен быть посылаться с CSRF токеном. Это гарантирует отправку формы тем же клиентом, что её и отобразил.

2) 🚩Что такое 2fa и нужна ли?
Вопрос для сеньора, но мидловский, т.к. 2fa уже прочно вошла в обиход. И будет плохим признаком, если вы ответите wtf. Для серьёзных сервисов - 2fa is a must, даёт серьёзный буст к возможности зайти в вашу учётку даже зная логин и пароль. 2fa - это "второй фактор" = токен - обычно, ваш телефон (апп или смс), но не ограничивается им. Могут быть usb флешки, блютуз девайсы, биометрические сканеры и тп.

3) Храните пароль в базе? Хешированным? Солёным?
Пароль должен быть захеширован, притом важен алгоритм. md5, sha-1 - уже не подходят в текущих реалиях. Используйте bcrypt, PBKDF2 или sha-256. Соль к паролю может быть одна для в всех - не худший вариант. Однако идеально, если соль состоит частично из данных самого пользователя. Плюсом будет, если упомянете о rainbow tables.

4) 🚩Сможете ли сами написать алгоритм для хранения пароля?
Правильный ответ тут - не нужно изобретать криптовелосипеды, если вы не бородатый математик! Слишком просто допустить критическую ошибку в алгоритме и снизить стойкость. Хорошо, если вы сможете привести пример несложного шифрования через XOR, но не более :)

Senior+ level

1) Что делать в случае коллизий паролей при хэшировании?
Избежать этого невозможно, однако шанс стремится к нулю. Но если уж вопрос задан - чем длиннее хэш, тем меньше шанс этой коллизии. Именно md5 и sha-1 не обеспечивают этой длины в сегодняшнем мире. Так же можно упомянуть про двойное хеширование и метод цепочек - внутрянку знать не обязательно, просто знать, что методы есть.

2) Если принято решение шифровать пароль, то какой тип шифрования выберете? Почему?
Вопрос на знание отличий симметричного vs ассиметричного типа. Вы должны понимать разницу. Ответ на самом деле - it depends, зависит от системы взаимодействия. Обычно, используют симметричное, т.к. ассиметричное подразумевает валидацию второй стороной, которой скорее всего не будет. Нужно так же дополнить, что шифрование не замена хэшированию и должно применяться только в крайних случаях в нашем кейсе.

3) В связи с пунктом два - одинаков ли по стойкости 128-битный ключ для симметричного и ассиметричного способа?
Нет, не одинаков. Природа ассиметричного шифрования подразумевает, что ключ должен быть намного длиннее. Эквивалент 128 битного симм. ключа = 2048 ассим. Хорошо бы еще рассказать про плюсы и минусы каждого из подходов.

4) Хорошая ли идея вынести авторизацию на openid?
Безусловно да, если на сайте множество поддоменов и сервисов - это позволит упростить коммуникацию разных бэкендов/сервисов, а так же фрагментирует точки отказа в случае их возникновения - если ляжет авторизация, всё остальное скорее всего будет работать независимо. Т.е. функция не размана по множеству бэкендов. Плюс это более скейлбл решение и добавляет изолированности этой важной функции. Если на авторизацию будет один из векторов атаки - это не затронет остальные компоненты системы. К слову это частая точка для ддоса, т.к. обычно грамотная аутентификация кушает и память и cpu и может легко положить всю систему, если она гвоздями прибита к основной группе сервисов. Хорошо бы еще упомянуть и про oauth 2.0 - это второй по популярности протокол.

5) Rate Limit?
Да, штука отличная. В случае брутфорса или же ддоса - позволит отсекать вредных клиентов и не аффектать "хороших". Все большие ребята следят за этим. Часто авторизацию прячут (как и весь сайт) за cloudflare, который берёт это на себя эту функцию.

Пожалуй, это основные моменты, которые известны мне. Если что-то пропустил или где-то не прав, вэлкам в комменты ;) Всем, кто дочитал - респектушка и похлопывание по плечу ^^ Раскидайте знакомым и проверьте их 😉

и правда кек

#habr

🔐 Что такое SSL/TLS и как он работает? И немного про асимметричное шифрование на пальцах.

Друг тут на днях провёл ликбез и расставил точки над i на эту тему (были определенные чёрные дыры в понимании), за что ему большое спасибо ^^ Делюсь закаточкой с вами.

SSL (secure sockets layer) - это криптографический протокол, обеспечивающий безопасное общение пользователя и сервера по небезопасной сети. Он работает между транспортным уровнем (TCP) и уровнем программы/клиента (http/ftp и тд).

Если на пальцах - TCP это такой "автобус", который везёт ваши данные от вокзала (сервера) до вашего дома (браузер) и назад. И всё бы неплохо, если бы не одно но - все вокруг могут видеть кто и куда едет в автобусе. Зеваки, камеры на дороге, полиция, государственные чины, воры и жулики - любой, кто находится на пути автобуса может просканировать весь автобус. Неприятно, правда же.

SSL - это силовое поле вокруг автобуса, через которое видно только куда "примерно" автобус едет и ... само силовое поле. Извне автобуса непонятно кто едет и едет ли вообще хоть кто-то. Не видно какие инструкции у водителя и к какой именно подстанции он подъедет на самом вокзале. Все мы иногда ездим по подстанциям, которые не хотелось бы афишировать, правда? 😉 Это наше личное дело - касается только нас и вокзала. Всем незнакомым личностям по пути следования знать детали совсем не обязательно. А часто - и опасно. Для нас.

Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer) и является его улучшенной версией. От SSL уже почти отказались, но название прижилось, поэтому если вы сегодня слышите SSL - подразумевается скорее всего TLS.

Итак. Как же это работает?

В основе протокола лежат асимметричное шифрование (для аутентификации) и симметричное (для сохранения конфиденциальности). Первый тип шифрования более ресурсоемкий/медленный, поэтому его комбинация с симметричным алгоритмом помогает делать всё красиво быстро.

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

Какая тут проблема в контексте интернета? А проблема в том, что а как передать этот секретный ключ из дома на вокзал чтобы никто по пути не перехватил его? Ответ : Асимметричное шифрование. Именно оно и нужно нам чтобы обменяться ключами между вашим браузером и сервером так, чтобы злоумышленники по пути не перехватили его. Как это сделать? Тут и начинается магия. Магия математики.

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

Круто, не правда ли? Т.е. то, что шифруется публичным ключом - расшифровать может только сервер с приватным. Именно этот публичный ключ и "зашивается" в специальный сертификат сервера, который скачивается при попытке установления соединения вашим браузером.

#security #библиотека_знаний

Итак... давайте отправлять автобус на порнхаб вокзал! (немного упрощенный сценарий на основе RSA, детали и другие варианты можно будет найти по ссылке в конце) :

1)🏠 ............🚌->........................................... 🏣[🔑🎫]
Вы отправляете на вокзал пустой автобус, водителя которого просите привезти сертификат с публичным ключом вокзала.

2) 🏠 ...................................<-🚌[🎫]........... 🏣[🔑]
Вокзал присылает автобус к вам домой, в нём лежит сертификат вокзала.

3) 🕵️ [🎫] => ✅ 🏠🚌............................. 🏣[🔑]
Вы проверяете, чтобы сертификат был красивым и ровно от того вокзала, в который вы отправляли автобус. Так же проверяете лицензионную голограмму (корневой сертификат, выданный надёжным центром сертификации) и срок годности.

4) 🕵️🏠............[🔐] 🚌->............................ 🏣 [🔑]
Если с сертификатом всё ок, вы генерируете симметричный ключ на своей стороне и шифруете его публичным ключом из сертификата. Отправляете автобус с вашим секретом. Уже на этом этапе никто по пути следования не сможет узнать ваш секретный ключ (помните, да? расшифровать это может только владелец приватного ключа, а владеет им только вокзал)

5) [🔑]🏠..........<-🚌[🔐boobs🔐].......... 🏣 [🔑]
Вокзал расшифровывает своим приватным ключиком сообщение. А там - уже ваш секретный симметричный ключ.

Всё. Теперь у вокзала и у вас есть ключ, о котором никто не знает. Этим ключом и создаётся то самое "энергетическое поле" вокруг вашего автобуса. Дальше уже работает только быстрое симметричное шифрование. Красиво, не правда ли?

Вот тут и тут можно найти более техническое и детальное описание процесса handshake'а. Так же очень советую глянуть (5min) визуализацию и объяснение работы алгоритма Диффи-Хеллмана.

#security #библиотека_знаний

Это определенно должно быть интересное интервью. Всего пять часов свободного времени выделить нужно 😎

Бегом смотреть!

https://www.youtube.com/watch?v=0xtEdIy2j88

#айтиборода #интервью

Интересный вектор атаки на packages подметили в последнем подкасте #радиот.

В двух словах - хацкеры сканят пакаджи, грепают все те, которые были зарегистрированы/залиты с кастомных доменных емейлов и проверяют а не истёк ли домен. В случае, если истёк - регистрируют, создают там нужную почту и льют новую версию package'а с вредоносом.

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

Как заявил сам автор - получилось собрать около 1000 переменных окружения, ну а что все там хранят? Правильно, секреты, конн стринги и прочие креды.

Вообще, атака на емейлы такого рода стара как мир, пакеты - лишь один из сценариев. К слову, совсем недавно чей-то бот купил истёкший домен аргентинского Google. В тот раз домен быстренько изъяли назад, однако you know, если даже гугл забывает продлять, то что уже говорить про остальные компании.

Будьте аккуратны с кастомными доменами и не забывайте их продлять 😉

#security

Как живётся в США "айтишнику". Три года спустя.

Автор довольно в позитивном ключе и детально рассказывает о трёхлетних итогах своей релокации из РФ в США. Рекомендую тем, кто посматривает в ту сторону - статья, пожалуй, даст вам плюс пару баллов в копилку ваших мыслей.

Отдельно, конечно же советую читать комментарии (1200+), там много информации и рассуждений.

https://habr.com/ru/post/666914/

#habr #usa #relocate

Я считаю, это прекрасно :

Как стать мидлом или сеньором-разработчиком, обучаясь на любых курсах по программированию?

https://habr.com/ru/company/hexlet/blog/670114/

#habr