tua-Mascot

Чтобы лучше понять "как" и "почему", для начала следует сформулировать задачу и рассмотреть пути решения.

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

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

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

Давайте поставим теперь себя на место злоумышленника. Располагая всем этим, как бы мы взламывали пароль?
1. Радужные таблицы (заранее сгенерированные таблицы "хэш -> значение").
2. Атака по словарю (сначала делается перебор по наиболее вероятным значениям).
3. Полный перебор.
Полный перебор хоть и решит задачу 100%, но это крайняя мера, крайне неэффективная, и, как правило, не рабочая, потому что пусть пароль и можно подобрать за десятки тысяч лет, злоумышленник столько не проживет (как и сама взламываемая система, и сам пользователь). Потому если мы обезопасились от пунктов 1 и 2 кое-как, то задачу, считай, решили.

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

Что нужно сделать, дабы исключить вариант использования радужных таблиц?
Сделать так, чтобы значения, подаваемые на вход хэш-функции, гарантированно в них отсутствовали. Для этого и придумали соль. В связи с этим к соли есть одно простое требование: соль должна быть сложно угадываемой.
То есть, если у нас есть пароль "password" и соль "111", то вероятность попадания строки "password111" в радужную таблицу все ещё очень высока, а значит подобная соль плохая. А вот соль "t%Lp-,DU4=w],9c7F.N$" хороша, потому что строку "passwordt%Lp-,DU4=w],9c7F.N$" в радужную таблицу никто записывать не будет.
Вывод: нам нужна соль для того, чтобы исключить поиск по хэшу в радужных таблицах.

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

Далее в арсенале злоумышленника остается атака по словарю.
Увы, полностью исключить данный вариант может только пользователь, если будет использовать стойкие и сложные к угадыванию пароли, у которых вероятность попадания в словари "крайне мала"(с).
Но на благоразумие всех пользователей надеятся не стоит, а обезопасить их как-то надо. И здесь у нас остается возможность "вставить палку в колесо" злоумышленнику, увеличив время выполнения алгоритма. То есть просто берем и хэшируем результат повторно надцать раз, пока время выполнения алгоритма не станет достаточно длинным, например, 500ms. Нам при аутентификации пользователя (да и самому пользователю) 500ms ждать не проблема, а вот злоумышленнику делать подбор пароля со скоростью 2 пароля за секунду, уже "ой-какая-головная-боль".
Вывод: повторяем хэширование много раз, дабы увеличить время выполнения алгоритма, что замедлит подбор паролей.

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

Дабы реализовать все вышесказанное, к велосипеду ручонки тянуть не нужно, именно из-за вышеуказанных "заморочек" в деталях алгоритмов. Криптография дилетанства не прощает. Тем более, что уже есть де-факто промышленные стандарты.
Например, bcrypt алгоритм (спасибо kpa6uu за упоминание). В PHP он реализован посредством стандартной password_hash() функции. В других языках тоже хватает реализаций.

Ну и наконец-то отвечая на Ваш вопрос "как лучше всего?", то на данный момент это алгоритм Argon2, победитель последнего Password Hashing Competition. С реализациями в языках, к сожалению, пока что не так все радужно как у bcrypt.

Сам себе отвечу. Прописываем в setting.json

"workbench.colorCustomizations": {
        "editor.selectionHighlightBackground": "#9b99af70",
        "editor.selectionHighlightBorder": "#9b99af00"
},

Какие задачи нужно уметь решать на чистом JS, перед тем как переходить к изучению библиотек и фреймворков?

Кроме синтаксических конструкций, математических и логических выражений, нужно знать:

• Область видимости переменных
  
• Замыкания
  
• Объектно-ориентированное программирование, в частности наследование через прототипы
  
• Шаблон проектирования "модуль"
  
• Операции над DOM
  
• Понимание принципов событийно-ориентированного программирования
  

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

Важно - инструменты программиста JavaScript
У тебя должен быть удобный инструмент для разработки (IDE, Integrated Development Environment), чтобы он тебе подсвечивал код (syntax highlight) и подсказывал о синтаксических ошибках (syntax check), о формальных параметрах функций (type hinting), о стиле кодирования (code style), помогал писать код (live templates).
Ты должен знать, как отлаживать скрипты в популярных браузерах (Firebug, Chrome Developer Tools и другое). Что такое точки останова, как управлять исполнением во время останова, как посмотреть и поменять содержимое переменных, как настроить останов по условию.

Хотелось бы узнать что это за задачи(упомянутые вами 80%)

Реальные задачи джунов:

1. Возьми из сборника задач по javascript любой скрипт случайно и вслух расскажи, что он делает.
   Важно - читать и понимать чужой код намного важнее, чем писать свой. И на работе тебе это приддётся делать чаще, чем ты думаешь. Чтобы подключить к своему проекту чужую JS либу, нужно понимать что она делает, как она конфигурируется, как управлять её поведением. Скажу точно, что написать свой скрипт, который строит графики, намного сложнее, чем понять, как настраивается highcharts.
   
   
2. Напиши скрипт на JS, который в заданном тексте удалит один или два символа, выбранных случайно
   
   1. Усложнение: удалять можно только буквы в словах, а знаки пунктуации и цифры удалять нельзя
      
   2. Усложнение: принять, что этот текст является программной на Javascript, удалить одну-две команды JS, но только если они не в строковых литерах (break как команду удалить можно, а в строке "break my heart" нельзя)
      
   3. Усложнение: воспользуйся этим скриптом и "попорти" код какого-нибудь другого скрипта на Javascript, а потом отладь, найди ошибку и восстанови работоспособность
      
   Важно - этим обычно все и занимаются - ищут баги. Только в реальной жизни они и без этого скрипта появляются. И не по одному, а прям пачками.
   
   
3. На страницу HTML нужно встроить график курса доллара по отношению к рублю. Формат входного массива значений курса определи сам, исходя из своего скрипта для построения графиков.
   
   1. Усложнение: на одном графике должны быть два курса, по разным шкалам. Наприме, курс доллара к евро и курс юаня к рублю
      
   2. Усложнение: первоначально график вывести в детализации по месяцам, но чтобы можно было "приблизить" (drilldown) детализацию до дней
      
   3. Усложнение: первоначально график вывести текущем месяце, но чтобы можно было загрузить данные для предыдущего месяца без перезагрузки страницы (AJAX)
      
   
   
4. При клике по картинкам, вставленным в текст HTML, показывать всплывающее окно для просмотра увеличенной картинки.
   
   1. Усложнение: в всплывающем окне сделать навигацию по картинкам, вперёд/назад и к нужной картинке
      
   2. Усложнение: в всплывающем окне вместо картинки показать видео-ролик с Youtube
      
   3. Усложнение: в всплывающем окне показать текст HTML
      
   
   
5. По клику на кнопку "Click me" показать всплывающую форму.
   
   1. Усложнение: реализовать проверку данных на корректность перед отправкой формы (непустое значение, минимальное количество символов, максимальное количество символов, минимальное числовое значение, максимальное числовое значение)
      
   2. Усложнение: если в значении текстового поля встретилась гиперссылка, то считать её за 22 символа при любой длине этой ссылки (как в твитере)
      
   3. Усложнение: реализовать отправку формы на сервер через AJAX, без перезагрузки страницы
      
   4. Усложнение: саму форму в виде HTML загрузить с сервера через AJAX, в момент клика по кнопке "Click me", правила проверок данных должны как-нибудь "извлечься" из самой загруженной формы, например из аттрибутов полей ввода
      
   
   
6. К форме ввода данных на поле ввода даты "навешать" всплывающий календарь для выбора даты.
   
   1. Усложнение: сделать форму календаря мультиязычной. Хотя бы через настройки на том же JavaScript
      
   2. Усложнение: сделать так, чтобы с помощью календаря можно было выбрать диапазон дат, чтобы она была привязана к двум полям формы "дата начала" и "дата окончания", и чтобы значение в поле "дата начала" обязательно была меньше чем в поле "дата окончания"
      
   3. Усложнение: сделать так, чтобы с помощью в календаре можно было видно визуально этот диапазон
      
   4. Усложнение: диапазон может быть открытым, но не пустым, то есть пользователь должен задать хотя бы дату начала или дату окончания.
      
   
   
7. Сделать пред-просмотр веб-страницы HTML с разными темами. Тему страницы выбирать через селектор на javascript, а показывать в фрейме.
   
   1. Усложнение: сделать селектор "тип устройства", чтобы менять размер фрейма (например, "iPhone 5c 1136x640") и "чекбокс" для смены ориентации страницы "горизонтальная" или "вертикальная" (соответственно 1136x640 или 640x1136)
      
   2. Усложнение: в селекторе тем предусмотреть поиск тем по подстроке, и аналогично поиск устройств по части названия (авто-дополнение, auto-complete)
      
   3. Усложнение: тема страницы должна меняться без перезагрузки фрейма
      
   
   

Задачи повышенной сложности, исходя из личного интереса

1. Реализовать форму для многошагового мастера: форма должна состоять из нескольких страниц (шагов), пользователь может переключать страницы через какие-нибудь элементы управления "вперёд/назад" или "перейти на страницу".
   
   1. Усложнение: реализовать функциональную связь значений, когда некоторые данные зависят друг от друга (ввёл число в поле "количество" и в поле "сумма" значение пересчиталось)
      
   2. Усложение: доступность некоторых полей ввода должна зависеть от данных (например, если указал "есть личный самолёт", то значит можно ввести "марка самолёта")
      
   3. Усложение: видимость некоторых страниц должна зависеть от данных из предыдущих страниц (например, если указал "есть личный самолёт", значит появилась страница "ТТХ самолёта"; иначе страница должна скрыться)
      
   
   
2. Реализовать однопользовательскую браузерную игру "змейка", "тетрис", "найди пару"
   
3. Реализовать многопользовательскую браузерную игру "крестики-нолики", "морской бой" на два игрока в режиме "hot seat"
   
   1. Усложнение: два игрока на разных компьютерах, ходы передаются по websocket
      
   2. Усложнение: ограничение на ожидания окончания хода 15 секунд, по окончании ожидания автоматически делается случайный ход
      
   
   
4. Реализовать todo-list. Пользователь вводит список, затем он превращается в строки с "чек-боксами". Когда "чекбокс" включен, строка зачёркивается.
   
   1. Усложнение: пользователь может переименовывать, удалять, добавлять строки
      
   2. Усложнение: список хранить в localStorage браузера, чтобы при перезагрузке страницы он восстанавливался
      
   3. Усложнение: пользователь может иметь несколько независимых списков todo
      
   
   
5. Реализовать простой графический редактор. Пусть рисуется точка в месте, где пользователь кликнул.
   
   1. Усложнение: добавить переключатель режимов "точка"/"линия", в режиме "линия" рисуются линии между двумя последовательно кликнутыми точками
      
   2. Усложнение: можно менять толщину, цвет линий, размер точек
      
   3. Усложнение: последовательность кликов можно воспроизвести ещё раз с самого начала, равномерно или с реальной задержкой между кликами, с обычной скоростью или ускоренно
      
   4. Усложнение: можно выгрузить получившийся рисунок в формате PNG или SVG, причём SVG c анимацией воспроизведения
      
   
   

Можно использовать любую существующую библиотеку.
Например,
для построения графиков www.highcharts.com
для загрузки и передачи данных через AJAX: jquery.com + что-нибудь на сервере
для всплывающих диалогов с картиками, видео и формами: fancyapps.com/fancybox и https://jqueryui.com/dialog/
для валидации форм rickharrison.github.io/validate.js
для календаря https://jqueryui.com/datepicker/
для автодополнения https://jqueryui.com/autocomplete/
для передачи данных между несколькими пользователями socket.io или обычный AJAX

Потому что оно не ноль :)

предположим что -1 это signed Int
то у числа такой вид 0xFFFFFFFF = 11111111 11111111 11111111 11111111
не похоже на 0 (false) да?

0 так выглядет
0x00000000 = 00000000 00000000 00000000 00000000

вам нужно более низкие языки посмотреть , чтобы понять как оно работает

false это нет сигнала , нет напряжения (0)
true есть сигнал (1)

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

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

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API - это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем UI. Объедините все прямоугольники с API и обзовите слоем сервисов.

Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.

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

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

Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

А дальше - детально прорабатывайте каждый маленький квадратик. Всё.

Собсна
<!-- eslint-disable-next-line -->
Помог на отличненько

Решил проблему написанием юзерскрипта
https://github.com/Taraflex/Back2stackoverflow