avva: (moose)
[personal profile] avva
Немного из недавнего и накопившегося:

  • Learning to Program: What are the best sites for learning programming?

    Неплохой обзор сайтов с подробными уроками программирования (где видеоуроками, где просто) для тех, кто совсем не умеет и хочет научиться.


  • Data Compression Explained.

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


  • You Are Dangerously Bad At Cryptography.

    Отличная запись о том, почему опасно самому наивно использовать криптографические алгоритмы, с несколькими наглядными примерами.

    В дискуссии на HN есть тоже немало интересного. В частности, Томас Птачек напоминает, что его компания Matasano продолжает предлагать широкой публике Crypto Challenges - набор упражнений по прикладному криптоанализу, не требующих предварительных знаний в криптографии. Я сам не пытался пока делать Crypto Challenges, не нашел на это времени, но несколько моих знакомых, которым я доверяю, очень и очень их хвалят. Думаю, что всем, кому хочется больше знать в этой области, стоит попробовать.

Date: 2013-05-28 01:31 pm (UTC)
From: [identity profile] trueblacker.livejournal.com
1. В таком случае, я вас снова не понял.
>я пользватель,
...
Я должен хранить его сертификат, который вы мне выдали

кого "его" ? Если вы пользователь, то, да, вам нужно "хранить" свой сертификат. Это проблема?

>И вот как мне его хранить непонятно

у каждого браузера свои способы. Их, вобщем, масса.

>И я не вижу принципиальной разницы что я буду хранить -- сертификат или пароль. И я не вижу принципиальной разницы что я буду хранить -- сертификат или пароль.
...
"Перехватить" его действительно нельзя, он никуде не ходит, сидит на месте. Но защитить его ничем не проще, чем пароль.

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

Date: 2013-05-28 01:46 pm (UTC)
From: [identity profile] meshko.livejournal.com
1) Ну да, хранить проблема. И она не меняется от того, что я храню -- пароль или сертификат. В смысле так хранить, чтобы его было сложно уркасть.

2) Пароль тоже не нужно пересылать, можно делать challenge-response.

Date: 2013-05-28 01:51 pm (UTC)
From: [identity profile] trueblacker.livejournal.com
1) От того, как вы называете хранимый секрет действительно ничего не меняется. А от того, нужно ли его знать кому-то ещё - меняется.

2) Challenge-response в случае пароля действительно избавляет от необходимости явно высылать пароль, однако подразумевает, что он уже заранее известен на сервере. Т.е. известен, потенциально, его админу и ещё куче народу.
Вы понимаете разницу между симметричным и асимметричным секретом?

Date: 2013-05-28 06:11 pm (UTC)
From: [identity profile] huzhepidarasa.livejournal.com
А нагенерировать из воздуха кучу валидных пользовательских сертификатов админ не может, что ли?

Date: 2013-05-28 11:43 pm (UTC)
From: [identity profile] trueblacker.livejournal.com
манипуляция типа "сгенерировать кучу валидных сертификатов" малоотличима от прямой правки пользовательского профиля. Грубо говоря, против злонамеренного админа нет вообще никаких средств, он может и пользвателя удалить и данные его украсть или исправить. Однако в случае пароля, админ имеет возможность сделать все так, как будто хакер добыл пароль у пользователя и сделал все легальным путем, не прибегая к его, админа, помощи. Ему достаточно "подсмотреть", не нужно ничего править.

Date: 2013-05-28 05:01 pm (UTC)
cat_mucius: (Default)
From: [personal profile] cat_mucius
Если вы пользователь, то, да, вам нужно "хранить" свой сертификат. Это проблема?
Вообщем-то да, проблема.

1. Если хранить его програмно, то при наличии доступа к компьютеру его можно украсть. В виде пруфа позволю себе ещё одну ссылку на свой уютненький, если не возражаете.
2. Эта проблема решается криптоконтейнерами, из которых ключ нельзя извлечь. Таких в общем два: смарткарты и TPM. Но с ними свои траблы:
2.1 Смарткарты - это ридеры, драйвера, проблемы совместимости, короче, деньги и нервы.
2.2. TPM - штука хорошая, но с програмным обеспечением для него швах: я это дело активно копал, нахлебался. Вот разве что на Windows 8 возлагаю надежды, у них там virtual smartcards появились, использующие TPM.
3. Допустим, юзеру надо поменять станцию. Смарткарту перенести с компа на комп легко - но если ключ хранится програмно или в TPM, то это процедура.
4. Если мы используем сертификат не только для аутентификации, но и для шифрования (S/MIME, EFS, ...), то недостаточно запихать его в криптоконтейнер - нужно обязательно ещё и бэкап хранить. А то потеряется смарткарта - и аминь.
5. А если он ещё и expired - то это ещё геморрой.

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

Из-за всего этого потенциал PKI и не используется толком, чего мне сильно жаль. Я и сам-то на работе, при всём энтузиазме, его не внедряю толком, из-за всех этих соображений.

Date: 2013-05-29 12:01 am (UTC)
From: [identity profile] trueblacker.livejournal.com
это все известные проблемы, однако они занимаются проблематикой, до которой обычная password-based аутентификация не доросла в принципе. У вас тут речь уже не о MIM, а о прямых атаках на рабочее место легального пользователя. Да, такие атаки тоже возможны, но:
1. password-based аутентификация не имеет тут никаких преимуществ и так же является уязвимой (и снова БОЛЕЕ уязвимой, чем аутентификация на основе асимметричной криптографии)
2. в PKI этими вопросами по крайней мере занимаются специально обученные люди и могут предложить варианты, из которых можно выбрать, балансируя между уровнем защищенности и сложность использования, тогда как у симметричной аутентификации выбор гораздо быстрее упирается в довольно низкий потолок защищенности, выше которого прыгнуть невозможно

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

Date: 2013-05-29 07:19 am (UTC)
cat_mucius: (Default)
From: [personal profile] cat_mucius
password-based аутентификация не имеет тут никаких преимуществ и так же является уязвимой
Ну вот разве что сбросить пароль можно быстрее, чем отозвать сертификат - апдейт и распространение CRL берёт время.

О новых технологиях: есть infocards - это такой любопытный гибрид между PKI и claim-based authentication. Все их аспекты я пока не понимаю, но там есть моменты, которые удачно облегчают жизнь по сравнению с традиционным PKI. Микрософт их имплементировала под названием Windows CardSpace, а потом почему-то списала в утиль и дальше поддерживать не будет. Мне жаль, что распространения infocards не получили - идея-то хорошая.

Ещё есть такая новая штука, как U-Prove - Микрософт на неё собирается заменять CardSpace. Там много интересного, разбираюсь потихоньку.

Date: 2013-05-29 07:24 am (UTC)
From: [identity profile] trueblacker.livejournal.com
>Ну вот разве что сбросить пароль можно быстрее, чем отозвать сертификат - апдейт и распространение CRL берёт время.

OCSP.

Про новые технологии спасибо за наводку, ознакомлюсь

Date: 2013-05-29 07:31 am (UTC)
cat_mucius: (Default)
From: [personal profile] cat_mucius
А знаете, как работает микрософтовский OСSP Responder? Будете смеяться - он читает CRL. :-)

Но в принципе OСSP это решение, конечно. Но оно убивает то преимущество сертификатов, что сторона удостоверителя не должна быть доступна в сети постоянно. Плюс там ещё всякие соображения от privacy.

Date: 2013-05-29 07:46 am (UTC)
From: [identity profile] trueblacker.livejournal.com
>А знаете, как работает микрософтовский OСSP Responder? Будете смеяться - он читает CRL. :-)

недостатки реализации не являются недостатками технологии :-)
Впрочем, доступность актуального CRL для OCSP Responder - вполне выполнимое, кмк, требование

December 2025

S M T W T F S
  123 4 56
78 9 10 11 1213
1415 1617181920
21 22 23 24 2526 27
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Dec. 29th, 2025 10:49 am
Powered by Dreamwidth Studios