xmoonlight

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

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

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

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

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

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

Много нюансов в вашем вопросе:
1. Смысл в open-source?
2. ПК, на котором будете шифровать, подключен к сети/интернету?
3. Операционка - доверенная и с открытым кодом?

Кратко:
1. Чтобы "спрятать" информацию, нужно предотвратить любую "утечку" данных до окончания процесса шифрования.
2. Чтобы не расшифровали через подбор "ключа", - избавиться от сигнатуры (например, перед шифрованием, превратить текст в набор хаотично расположенных символов и добавить "мусор").

В Windows-е один юзер.

это Ваша ГЛАВНАЯ и ЕДИНСТВЕННАЯ ОШИБКА.
Сделайте каждому своего юзера и конец проблеме.

Вариант 2: разные папки профилей в хроме: здесь.
Ну тогда придётся доступы к папкам регулировать сторонними утилитами.

Хорошие и передовые сервисы имеют множество средств защиты учётной записи.

Такими средствами - лучше НЕ пренебрегать и не отказываться от их использования!

1. Проверяйте, что пароль уходит ТОЛЬКО в зашифрованном виде или через SSL!
2. Пароль (любой и можно не менять) + E-MAIL + SMS + Google Authenticator + выставить фильтр по IP-адресу/подсети + OAuth/SSH-токены ещё бывают и т.д.

А вообще - вопрос хороший: надо черкануть статью: "Учётка в сейфе"))

UPD:
Создадим функцию (формулу):
Функция: логин, hash: sha1(домен+"соль"), текущая дата создания/смены пароля, алфавит всех возможных символов в пароле, требования для формирования пароля и своя "соль".
На вход: только домен.
Затем вычисляем hash и по hash'у - находим логин и после: вычисляем пароль.
На выходе: получаем логин и готовый пароль

Т.е., не зная домена и формулы - не узнать точного логина и пароля.
А пароль - нигде не хранится.

Текстовик на SFTP с доступом по ключу.

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

Сервис промежуточной авторизации - должен быть у Вас 100%.
Сессию - можно отдать, только тогда, когда будете уверены, что сотрудник не сможет поменять текущий пароль без знания старого и/или пин-кода в SMS, который приходит на мобилу (для подтверждения при важных операциях в аккаунте).

Проще - использовать хранилище сессий (плагин для FireFox):
https://addons.mozilla.org/en-US/firefox/addon/ses...
И затем расшарить сессию в общий доступ для компов.

Когда сотрудник захочет зайти - он просто переходит по ссылке и он уже будет автоматом авторизован в соц.сети (да и где угодно).

Также, можно разделить:
1. Создать разные сессии и положить файл каждой сессии в отдельную папку с разграниченным доступом.
2. Создать копии одной сессии в папках с разграниченным доступом.

Т.е. фактически: файл сессии здесь и будет токеном.

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

Если Вы хотите обезопасить свои пароли от кражи с Вашего ПК:
Обезопасить свои пароли от кражи с Вашего ПК какими-либо программами можно только с помощью "auth-session-wrapper".
Т.е. создаёте свой модифицирующий пакеты прокси и указывайте ему свои пароли к сервисам: связки "логин/пароль"->"URL","METHOD". Можете добавить USER-AGENT и/или другие заголовки браузера - по-вкусу.

И далее, обращаетесь к нему с другого ПК с передачей заголовков один-в-один/точь-в-точь этого (консольного) ПК при нажатии на кнопку LOGIN с пустыми полями. Получаете информацию о сессии, восстанавливаете на консольном и... Вы уже залогинены под своей учетной записью без ввода пароля на своём ПК.

Главное, чтобы ПК-враппер был в одной внутренней сети, что и консольный. Т.е. имел ТАКОЙ ЖЕ внешний IP-адрес, что и консольный. (т.к. в части случаев сессия бывает привязана к IP-адресу её инициатора)

Если же Вы сами строите закрытую зону, можно сделать по следующей схеме:
1. Вы жмете кнопку "Login" и система считывает текущий токен с вашего браузера/приложения, обновляет его.
2. Просит подтвердить ключом защиты: через другой канал (другой домен, SMS и прочее). Т.е. например, система может открыть окно к другому домену, где будет надпись: "Введите PIN на вход для сессии 31337". Например, 4 цифры: "4115"
3. После ввода - удалённый сервер сверяет связку полученную через два разных канала: ПИН+ТОКЕН+[временные интервалы/лимиты]
4. если все ОК - пускает в защищенную зону (ЛК и т.п.).

Дополню по теме: лучшая защита личного API от постороннего входа (со стороны сервера): port knocking

1. Сделайте коннект к промежуточному хосту (как прокси-хост), на нем пропишите соответствие login:pass (внутренний) -> host,login,pass,port (внешний)
2. Пропишите, что к промежуточному хосту доступ только с определенного IP (или сертификат).
3. Не открывайте доступ к этой связке хранения (файловая система, БД и т.д.)
Все это нужно делать обязательно на другом сервере (возможно виртуальная машина)

Если даже пароли украли - вы их смените в одно мгновение. (не меняя удаленные)
Если попытаются подключиться с украденными паролями, то доступ будет только с указанного IP. (ну и сертификат добавьте для более большей надежности)
--------------
Ну а по шифрованию - уже все и так здесь много полезного сказали.
Добавлю лишь: главное - защищайте "соль".