Bafloker
@Bafloker
Просто человек

Надежен ли такой метод хранения паролей?

Способ мой заключается в следующем: каждый пароль сохраняется в отдельный текстовой файл, все файлы помещаются в шифрованный, запороленный архив (пароль сложный), когда нужен пароль, открывается архив, вводится пароль, затем берется нужный пароль, копируется в буфер обмена и вставляется (потому-что пароли у меня длинные и вводить руками не вариант). Безопасен ли такой метод, включая способ вставки через буфер обмена, или все же мне начать пользоваться менеджерами паролей?
  • Вопрос задан
  • 813 просмотров
Пригласить эксперта
Ответы на вопрос 2
@nirvimel
Что только люди не придумают, чтобы не использовать KeePass.

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

Кроме того, весь софт, запущенный под тем же юзером имеет достаточно привилегий для чтения содержимого буфера обмена в любой момент (теоретически эти привилегии можно отозвать, но большая часть софта не рассчитана на такое и будет вылетать с дикими ошибками). Многие кейлоггеры очень пристально следят за изменениями в буфере, хранение и посылка на сервер всех изменений обходится им "дешевле", чем съемка скриншотов. И даже скрипты на веб-странице могут в некоторых случаях читать из буфера (в зависимости от браузера и от настроек).
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
На сегодня есть только один вариант безопасного входа: токен/сертификат, полученный при регистрации в системе с двухфактороной аутентификацией через PIN.
Но на сегодня это работает на ничтожном проценте от всех сайтов...

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы