Воскресный юмор: пароли в Twitter

12. December 2010, 20:02 Занимательное, Компьютеры и ПО

Между прочим, идея о хранении паролей от разных онлайн-сервисов в записях Twitter – идея в меру здравая, но требующая приложения технической хитрости в реализации. Конечно, просто “постить” пароли в открытом виде нельзя. Нужно их зашифровать каким-нибудь симметричным шифром (3DES, Blowfish и т.п.), используя мастер-пароль, и преобразовать в Base64, чтобы получить текстовое представление, пригодное для отправки на страницы Twitter.

Зашифровать и преобразовать легко – используем openssl, поддерживающий все нужные шифры и коды. Мастер-пароль, понятно, придётся запомнить. Логины можно либо помнить, либо шифровать вместе с паролем (одной строкой, как обычно). Но возникает резонный вопрос: как найти нужную запись? Оказывается, очень просто: генерируем хеш (MD5, например) от названия ресурса, логин/пароль для которого сохранён в данной записи, и часть строки со значением хеша добавляем в качестве “индекса”, через пробел, или можно использовать “#” (как это принято в “Твитере”). Для экономии места можно использовать пять или семь последних символов от значения хеша. Теперь найти запись можно стандартным поиском “Твитера”.

Использовать для “индексации” записей фрагменты URL-ов онлайн-сервисов – не так занимательно, как куски от сумм MD5, и не так секретно. Да, можно тривиальным способом построить таблицу с MD5 от названий всех сколь-нибудь популярных интернет-ресурсов и тем самым восстановить некоторую информацию о назначении записей. Но это не страшно. Более того, столь же тривиальна защита: просто “солим исходник” – перед вычислением MD5 добавляем к названию ресурса секретный суффикс.

Итак, получается бесплатное онлайновое хранилище паролей, доступное из всех концов Интернета. Впрочем, только в порядке юмора.

Как восстановить зашифрованные пароли на своей машине – понятно: взял и восстановил (непонятно, впрочем, почему же тогда не воспользоваться локальным хранилищем). А вот получить доступ к паролям на произвольном компьютере, подключенном к Интернету – сложно. Ведь дешифровать пароли нужно локально (иначе снижается секретность), но на компьютере может отсутствовать подходящий инструментарий. Даже для поиска пароля потребуется вычислить MD5.

Конечно, можно подготовить и опубликовать веб-страницу, включив в её состав javascript-библиотеку, реализующую нужную криптографию в браузере, на клиентской стороне. Но тогда и зашифрованные пароли лучше хранить на такой странице, а не в “Твитере”.

(Кстати, кроме шуток, если использовать “облачные” сервисы для хранения данных, то данные нужно шифровать, прежде чем отдавать в “облако”. Достаточно быстрые, с учётом доступа через Интернет, реализации стойких шифров сейчас есть. А вот если вы захотите ещё и обрабатывать зашифрованные данные в облаке, то тогда возникнет интересная проблема: далеко не всегда возможно и обработку данных вести в зашифрованном виде; даже если возможно, то придётся написать довольно сложную программную систему, выполняющую такую обработку.)

Адрес записки: https://dxdt.ru/2010/12/12/3446/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 13

  • 1. 13th December 2010, 00:25 // Читатель jno написал:

    https://www.clipperz.com/beta/ – вот вам и оно, шифрованное на клиенте и живущее “в облаке”…

    для менее параноидального подхода – lastpass.com

  • 2. 13th December 2010, 13:56 // Читатель Temiy написал:

    Поздравляю! Вы только что изобрели keymemo.com.

  • 3. 13th December 2010, 15:17 // Александр Венедюхин:

    Да я и не сомневался, что уже реализован второй вариант. Нужно вот только посмотреть как именно, насколько хорошо. Там зачем-то https в keymemo – явно избыточно.

  • 4. 13th December 2010, 18:10 // Читатель jno написал:

    > Там зачем-то https в keymemo ? явно избыточно.

    видать, для авторизации на самом сайте – некузяво голые креденшалз по сети гонять…

  • 5. 13th December 2010, 18:51 // Читатель Temiy написал:

    SSL избыточен? Сертификат тогда тоже изыточен? Не ожидал от вас =).

  • 6. 13th December 2010, 19:06 // Александр Венедюхин:

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

  • 7. 13th December 2010, 22:34 // Читатель jno написал:

    ну, как-то определить кому чьи данные казать надо?
    а это – авторизация :)

  • 8. 14th December 2010, 13:26 // Александр Венедюхин:

    Все данные нужно показывать всем. Для изменения нужна авторизация. В этом же и был смысл – абсолютно публичное хранение паролей. Простое хранение паролей на сервере – это не то.

  • 9. 14th December 2010, 17:58 // Читатель jno написал:

    > абсолютно публичное хранение паролей
    в теории – красиво, а на практике лениво качать чужие и ненужные “гигазы варезов” и потом искать в них свои крохи…
    отсюда – традиционная авторизация и отбор “своих” записей.

  • 10. 14th December 2010, 18:01 // Александр Венедюхин:

    Ну что там искать – есть же DNS: сделал адрес типа dxdt.ru/mypwd – вот и всё.

  • 11. 15th December 2010, 00:10 // Читатель jno написал:

    > адрес типа dxdt.ru/mypwd
    а где тут DNS? :)
    может, имелось в виду mypwd.dxdt.ru?
    но DNS’ом часто рулит не тот же чел, что и сайтом сервиса…

  • 12. 15th December 2010, 13:15 // Александр Венедюхин:

    DNS тут в dxdt.ru и вообще – везде.

    Если рулит “не тот чел”, то сам по себе не поможет https с чужой машины (потому что не ясно, что за сертификаты там стоят). Подписать же данные можно без https, и человек с DNS не сможет смешать карты.

    А кроме того, если данные подменили – то это, в данном конкретном механизме, эквивалентно потере доступа к паролям, а не подмене авторизационной информации (или адресов сайтов).

    Вот как.

  • 13. 15th December 2010, 17:00 // Читатель jno написал:

    > сам по себе не поможет https с чужой машины

    машина может быть и не совсем чужая (VDS/VPS, к примеру)
    но правила обслуживания зоны – они разные бывают: “пушка за угол стрЕльнет, но наклонять её запрещено по уставу”.

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