Наверное, я не совсем правильно выражаюсь, либо мы не понимаем друг друга. Я имею в виду, что хранить пароли без использования мастер-пароля небезопасно. Да, если использовать мастер-пароль для доступа к паролям, то все становится гораздо проще и безопаснее. Но именно от мастер-пароля я стремлюсь уйти. Да, не до конца: он представлен секретом для TOTP.
Про безопасность подробно описано в конце статьи, но я повторю кратно. Система использует три устройства для защиты паролей: само устройство пользователя, устройство с приложением-аутентификатором, а также сервер, на котором хранятся данные. Для получения возможности несанкционированно расшифровать пароль необходимо иметь доступ к устройству, с которого был создан пароль, а также еще одному из двух оставшихся. И при всем этом необходимо знать в каких сервисах какой логин пользователь использует.
Почему же это безопаснее, если рассматривать хранение данных локально без использования мастер-ключа (это не ваш случай, конечно, но я беру сравнимые случаи)? Потому что выработку ключа шифрования может повторить любое вредоносное ПО и получить доступ к паролям.
В случае использования мастер-ключа, не спорю, безопасность все равно обеспечивается, но ее уровень зависит от сложности ключа. Согласитесь, пользователю вряд ли понравится вводить с бумажки что-то сложное.
Поэтому в конце статьи и сделал оговорку, что хранить пароли от всего подряд не стоит, ровно как и рядовому пользователю будет работать не совсем удобно именно по причине потери доступа к паролям.
Со сканером отпечатков пальцев идея неплохая, я думал про нее. Но опять-таки, посмотрим на проблему слегка шире: где-то этот отпечаток пальца требуется хранить и создавать на его основании ключ доступа. И тут уже вопрос в том, насколько его реально выцепить. А еще в том, где пользователю взять сканер отпечатка пальцев, хотя эта проблема стоит в меньшей мере.
Что вы имеете в виду под "облаком"? Чужой компьютер? Ноду на Digital Ocean?
В данном случае - развернутый, например, компанией сервер. Как он развернут не так важно на деле в алгоритмической реализации: главное - разнести данные между устройством, на котором пароли используются, и устройством, на которых пароли хранятся.
Если два года назад я создал пароль на ноуте, а теперь он понадобился мне в аэропорту, а с собой только телефон -- иду я нафиг?
Как описал в конце, эта система для обычных пользователей не особо подходит и является выстрелом в ногу пользователя. С этой претензией вообще не спорю, что неудобно и не является полезным.
То, что для вас является удаленным файлом, является локальным относительно "облака". Его так же могут слить.
До общей реализации, как я понимаю, вы не дошли. Пароли шифруются ключом, зависимым от данных устройства, на котором пароль был создан. Без привязки к конкретному устройству. Поэтому даже если они сольются, расшифровать их невозможно. В то же время, если хранить их на локальном компьютере, для достижения цели этого требуется мастер-пароль, от использования которого я стремлюсь отказаться. Да, мастер-пароль будет секретом для TOTP. Но конечному пользователю их не нужно запоминать нигде, кроме приложения-аутентификатора.
Тоже сейчас копаюсь и пишу свой менеджер паролей. Статью пробежал лишь мельком, так что если про мои замечания было что-то написано, прошу не сильно ругать.
Для хранения паролей будет использоваться файл формата xml, который будет шифроваться методом AES-256 и храниться в облаке.
По итогу придется вытаскивать все пароли в оперативку и держать там. Не то, чтобы прям совсем критично, но из оперативки их тоже можно прочитать, насколько помню.
Для работы с API-диска требуется логин и пароль, но вместо того, чтобы каждый раз вводить их, был перехвачен токен авторизации и использовался для работы с облаком.
Это первое - срок действия токена авторизации может закончиться и придется заново получать токен.
Чтобы напрямую работать с массивом данными и не подгружать их каждый раз из файлов, эти массивы сразу импортируются в исполняемый файл. Для этого полученные файлы преобразовываются в объектные файлы, с помощью инструменты «objcopy» (инструмент поставляется вместе с MinGW), а потом линкуются в exe-файл.
Это то, с чем я долго боролся и получилось побороть только с костылем. На винде так делать очень плохо. Если кто-то получит доступ к exe файлу, а это может сделать любой вирус, нацеленный специально на атаку вашего менеджера паролей, то ключ шифрования будет получить достаточно легко. И хранить ключи просто в файлах тоже плохо: к ним также есть доступ. Вы используете PBKDF2, так выберите надежный пароль и уже с его помощью генерируйте ключи. Правда, на мой взгляд, подход "один пароль, чтобы править всем" тоже слегка странный. Также, как правильно отметили выше, использовать один и тот же IV для AES не особо правильно и безопасно.
На мой взгляд, наилучшим решением было бы написание своего сервера под хранение паролей со сквозным шифрованием. Причем каждый пароль шифровать своим ключом. В идеале, собрать систему "выстрели пользователю в колено", чтобы нельзя было идентифицировать, кому принадлежит пароль в базе, а получать конкретный пароль только после ввода названия сервиса и логина (хранить название сервиса и логин напрямую плохо, кстати). Да, это доставит неудобства пользователю, но в таком решении безопасность пароля максимальна, потому что: 1) Без идентификации пользователя, сервиса и логина, даже если пароль утечет и его каким-то чудом правильно дешифруют, это будет просто пароль, который неизвестно куда применять 2) Уникальные ключи шифрования дают возможность не переживать за то, что дешифрование одного пароля даст возможность узнать остальные пароли в базе 3) Даже если злоумышленник получит доступ к устройству пользователя, в котором был произведен вход в систему, без знаний о сервисах и логинах для которых есть записи в базе.
Aspire ориентирован на проекты, а не на решения. Поэтому самое простое - сделать репу под Aspire, в которую другие репы добавить как подмодули. Если не хочется тащить .sln файлы, либо там есть повторяющиеся проекты, подробнее отвечал тут (но на мой взгляд это решение слегка костыльное): https://habr.com/ru/articles/820435/#comment_26914799
Забыл добавить, что 0 шаг на самом деле не обязателен: Aspire ориентирован на проекты, то есть можно добавить весь репозиторий как подмодуль, но остальные шаги все равно все также обязательны для исполнения
В первой части статьи рассматривал переход как раз-таки из отдельных проектов, но там я просто перевел все проекты в новый репозиторий.
Но действительно может возникнуть проблема с тем, что разрабатывать все сервисы внутри Aspire решения может быть проблематично. Лично я собираюсь эту проблему решать так (не говорю, что метод оптимальный):
1) В решение каждого сервиса добавить проект ServiceDefaults, в builder'ах добавить AssServiceDefaults() 2) В Aspire добавить каждый сервис как подмодуль 3) В случае необходимости запуска сервисов по отдельности для тестов, вставить следующий костыль:
3.1) При запуске проекта через Aspire передавать переменную среды с заранее определенным именем и значением в случае, если запускается через Aspire. 3.2) Выделить AddServiceDefaults, а также всю информацию, получаемую из Aspire в if, в котором проверяется существование переменной среды и ее название. 3.3) Если данной переменной среды не существует, запускать так, как запускалось до перехода в Aspire
Но в этом своем решении не претендую на истину в последней инстанции.
Про проверку isspace тупо забыл, что существует, на плюсах не так часто пишу.
Вот этот мув совершенно не понял. То есть везде по коду используется std::string, но в этом месте вы решили ручками покопировать память. Зачем? Сделали ли бы string из сырой строки.
Согласен, так даже проще, просто этот кусок кода был написан до основной части компилятора.
Лучше перейти на string_view и считать оффсеты от текущей глобальной позиции лексера. Что-то вроде
Не совсем понял следующий момент: токен может быть более, чем из одного символа. Или вы хотите сказать, что по глобальной позиции лексера и смещению мы можем выделить кусок строки, который является текущим проверяемым токеном? А в таком случае не будет ли на каждом шаге создаваться своя строка? А с тем, что так проще для парсинга ошибок согласен, спасибо за совет.
До ваших статей, кстати, руки пока не дошли. Видел их и хотел прочитать, но пока не успел. Надеюсь, вы будете не против, если что-то после прочтения украду к себе в код/статью. С указанием ссылки, разумеется.
Все прозаично и, возможно, наивно: хотел попрактиковаться именно с ассемблером, некоторые его знания уже были. Я бы задал себе другой вопрос: почему я полез в ассемблер, который сейчас компилируется только в MS-DOS. Но на этот вопрос я сам не могу дать себе внятного ответа. Наверное проще было установить DOS, чем смотреть на отличия досовского asm от asm для винды.
Спасибо за фидбек, ради него в основном и писал статью, потому что пока только погружаюсь в эту тему.
Примеры программ могу буду добавить, но особо нет идей, что написать на этом языке. Разве что действительно какие-то достаточно примитивные модели.
Про неоднозначность грамматики спорить не буду, слишком глубоко не вдавался в ее построение, если быть совершенно честным, то писал свой компилятор на основе упомянутой статьи, поэтому просто взял грамматику отсюда, несколько поправив ее под мой случай.
У операций нет приоритета, это было упомянуто в статье. Единственный приоритет - это скобки.
С последним абзацем также соглашусь. Пока это минимальная версия того, на что можно получить ответ. Я планирую дальше дорабатывать этот компилятор, правда пока не знаю в каком ключе лучше двигаться. Пока думаю добавить глобальные функции, но не знаю действительно ли это позволить показать что-то большее, кроме семантики.
За оптимизацию кода компилятором вообще страшно браться: вряд ли пока дорос до такого.
Хотел только написать, что писал для того, чтобы разобрать основные моменты устройства компиляторов (правда пока не до всех руки дотянулись), а за меня уже все написали. Спасибо.
Но до минимальной версии мой компилятор пока не особо тянет, думаю. Сейчас пытаюсь разобраться с функциями (тоже в таком же простейшем виде: доступ только к глобальным функциям, со своими двадцати шестью переменными). Может через неделю-две напишу продолжение статьи. Там как раз уже и семантика будет.
База для данного пользователя превратилась в тыкву, увы. Доступ не будет получен, потому что нужно также получить доступ к аутентификатору
Наверное, я не совсем правильно выражаюсь, либо мы не понимаем друг друга. Я имею в виду, что хранить пароли без использования мастер-пароля небезопасно. Да, если использовать мастер-пароль для доступа к паролям, то все становится гораздо проще и безопаснее. Но именно от мастер-пароля я стремлюсь уйти. Да, не до конца: он представлен секретом для TOTP.
Про безопасность подробно описано в конце статьи, но я повторю кратно. Система использует три устройства для защиты паролей: само устройство пользователя, устройство с приложением-аутентификатором, а также сервер, на котором хранятся данные. Для получения возможности несанкционированно расшифровать пароль необходимо иметь доступ к устройству, с которого был создан пароль, а также еще одному из двух оставшихся. И при всем этом необходимо знать в каких сервисах какой логин пользователь использует.
Почему же это безопаснее, если рассматривать хранение данных локально без использования мастер-ключа (это не ваш случай, конечно, но я беру сравнимые случаи)? Потому что выработку ключа шифрования может повторить любое вредоносное ПО и получить доступ к паролям.
В случае использования мастер-ключа, не спорю, безопасность все равно обеспечивается, но ее уровень зависит от сложности ключа. Согласитесь, пользователю вряд ли понравится вводить с бумажки что-то сложное.
Поэтому в конце статьи и сделал оговорку, что хранить пароли от всего подряд не стоит, ровно как и рядовому пользователю будет работать не совсем удобно именно по причине потери доступа к паролям.
Со сканером отпечатков пальцев идея неплохая, я думал про нее. Но опять-таки, посмотрим на проблему слегка шире: где-то этот отпечаток пальца требуется хранить и создавать на его основании ключ доступа. И тут уже вопрос в том, насколько его реально выцепить. А еще в том, где пользователю взять сканер отпечатка пальцев, хотя эта проблема стоит в меньшей мере.
В данном случае - развернутый, например, компанией сервер. Как он развернут не так важно на деле в алгоритмической реализации: главное - разнести данные между устройством, на котором пароли используются, и устройством, на которых пароли хранятся.
Как описал в конце, эта система для обычных пользователей не особо подходит и является выстрелом в ногу пользователя. С этой претензией вообще не спорю, что неудобно и не является полезным.
До общей реализации, как я понимаю, вы не дошли. Пароли шифруются ключом, зависимым от данных устройства, на котором пароль был создан. Без привязки к конкретному устройству. Поэтому даже если они сольются, расшифровать их невозможно. В то же время, если хранить их на локальном компьютере, для достижения цели этого требуется мастер-пароль, от использования которого я стремлюсь отказаться. Да, мастер-пароль будет секретом для TOTP. Но конечному пользователю их не нужно запоминать нигде, кроме приложения-аутентификатора.
Тоже сейчас копаюсь и пишу свой менеджер паролей. Статью пробежал лишь мельком, так что если про мои замечания было что-то написано, прошу не сильно ругать.
По итогу придется вытаскивать все пароли в оперативку и держать там. Не то, чтобы прям совсем критично, но из оперативки их тоже можно прочитать, насколько помню.
Это первое - срок действия токена авторизации может закончиться и придется заново получать токен.
Это то, с чем я долго боролся и получилось побороть только с костылем. На винде так делать очень плохо. Если кто-то получит доступ к exe файлу, а это может сделать любой вирус, нацеленный специально на атаку вашего менеджера паролей, то ключ шифрования будет получить достаточно легко. И хранить ключи просто в файлах тоже плохо: к ним также есть доступ. Вы используете PBKDF2, так выберите надежный пароль и уже с его помощью генерируйте ключи. Правда, на мой взгляд, подход "один пароль, чтобы править всем" тоже слегка странный. Также, как правильно отметили выше, использовать один и тот же IV для AES не особо правильно и безопасно.
На мой взгляд, наилучшим решением было бы написание своего сервера под хранение паролей со сквозным шифрованием. Причем каждый пароль шифровать своим ключом. В идеале, собрать систему "выстрели пользователю в колено", чтобы нельзя было идентифицировать, кому принадлежит пароль в базе, а получать конкретный пароль только после ввода названия сервиса и логина (хранить название сервиса и логин напрямую плохо, кстати). Да, это доставит неудобства пользователю, но в таком решении безопасность пароля максимальна, потому что:
1) Без идентификации пользователя, сервиса и логина, даже если пароль утечет и его каким-то чудом правильно дешифруют, это будет просто пароль, который неизвестно куда применять
2) Уникальные ключи шифрования дают возможность не переживать за то, что дешифрование одного пароля даст возможность узнать остальные пароли в базе
3) Даже если злоумышленник получит доступ к устройству пользователя, в котором был произведен вход в систему, без знаний о сервисах и логинах для которых есть записи в базе.
Aspire ориентирован на проекты, а не на решения. Поэтому самое простое - сделать репу под Aspire, в которую другие репы добавить как подмодули. Если не хочется тащить .sln файлы, либо там есть повторяющиеся проекты, подробнее отвечал тут (но на мой взгляд это решение слегка костыльное): https://habr.com/ru/articles/820435/#comment_26914799
Забыл добавить, что 0 шаг на самом деле не обязателен: Aspire ориентирован на проекты, то есть можно добавить весь репозиторий как подмодуль, но остальные шаги все равно все также обязательны для исполнения
В первой части статьи рассматривал переход как раз-таки из отдельных проектов, но там я просто перевел все проекты в новый репозиторий.
Но действительно может возникнуть проблема с тем, что разрабатывать все сервисы внутри Aspire решения может быть проблематично. Лично я собираюсь эту проблему решать так (не говорю, что метод оптимальный):
0) Если в репозитории лежит все решение, а не отдельный проект, выделить проект в подмодуль. Например так: https://web.archive.org/web/20170813014246/http://ishmuradov.ru/page/git-otdelit-direktoriju-v-otdelnyj-repozitorij
Также можно добавить полный существующий репозиторий как подмодуль в Aspire, и просто из него взять проекты, но зачем тащить .sln файл?
1) В решение каждого сервиса добавить проект ServiceDefaults, в builder'ах добавить AssServiceDefaults()
2) В Aspire добавить каждый сервис как подмодуль
3) В случае необходимости запуска сервисов по отдельности для тестов, вставить следующий костыль:
3.1) При запуске проекта через Aspire передавать переменную среды с заранее определенным именем и значением в случае, если запускается через Aspire.
3.2) Выделить AddServiceDefaults, а также всю информацию, получаемую из Aspire в if, в котором проверяется существование переменной среды и ее название.
3.3) Если данной переменной среды не существует, запускать так, как запускалось до перехода в Aspire
Но в этом своем решении не претендую на истину в последней инстанции.
Ни разу не работал со string_view, так что не знал. Теперь знаю несколько больше)
Согласен, что лучше переписать код таким образом.
Про проверку isspace тупо забыл, что существует, на плюсах не так часто пишу.
Согласен, так даже проще, просто этот кусок кода был написан до основной части компилятора.
Не совсем понял следующий момент: токен может быть более, чем из одного символа. Или вы хотите сказать, что по глобальной позиции лексера и смещению мы можем выделить кусок строки, который является текущим проверяемым токеном? А в таком случае не будет ли на каждом шаге создаваться своя строка? А с тем, что так проще для парсинга ошибок согласен, спасибо за совет.
До ваших статей, кстати, руки пока не дошли. Видел их и хотел прочитать, но пока не успел. Надеюсь, вы будете не против, если что-то после прочтения украду к себе в код/статью. С указанием ссылки, разумеется.
Все прозаично и, возможно, наивно: хотел попрактиковаться именно с ассемблером, некоторые его знания уже были. Я бы задал себе другой вопрос: почему я полез в ассемблер, который сейчас компилируется только в MS-DOS. Но на этот вопрос я сам не могу дать себе внятного ответа. Наверное проще было установить DOS, чем смотреть на отличия досовского asm от asm для винды.
Спасибо за фидбек, ради него в основном и писал статью, потому что пока только погружаюсь в эту тему.
Примеры программ могу буду добавить, но особо нет идей, что написать на этом языке. Разве что действительно какие-то достаточно примитивные модели.
Про неоднозначность грамматики спорить не буду, слишком глубоко не вдавался в ее построение, если быть совершенно честным, то писал свой компилятор на основе упомянутой статьи, поэтому просто взял грамматику отсюда, несколько поправив ее под мой случай.
У операций нет приоритета, это было упомянуто в статье. Единственный приоритет - это скобки.
С последним абзацем также соглашусь. Пока это минимальная версия того, на что можно получить ответ. Я планирую дальше дорабатывать этот компилятор, правда пока не знаю в каком ключе лучше двигаться. Пока думаю добавить глобальные функции, но не знаю действительно ли это позволить показать что-то большее, кроме семантики.
За оптимизацию кода компилятором вообще страшно браться: вряд ли пока дорос до такого.
Хотел только написать, что писал для того, чтобы разобрать основные моменты устройства компиляторов (правда пока не до всех руки дотянулись), а за меня уже все написали. Спасибо.
Но до минимальной версии мой компилятор пока не особо тянет, думаю. Сейчас пытаюсь разобраться с функциями (тоже в таком же простейшем виде: доступ только к глобальным функциям, со своими двадцати шестью переменными). Может через неделю-две напишу продолжение статьи. Там как раз уже и семантика будет.