файл отрицательного размера

Как выяснилось, эти лапочки не просто скрыто перенаправляют запросы с мобильных браузеров некоторых моделей телефонов через свои прокси-серверы (как это открыто делает Opera Mini), но Nokia вдобавок дешифрует там HTTPS, пользуясь доверенными сертификатами, заблаговременно встроенными в эти мобильные браузеры.
Естественно, всё это не слежки ради, а чисто по просьбам трудящихся для удобства пользователей. Типа, страницы оптимизируют, чтоб сэкономить пользователям мобильный трафик.

На языке информационной безопасности это называется “атака типа man-in-the-middle”.

В общем, спасибо, родные, сюда я больше не ездец.

Ссылки по теме:
https://gaurangkp.wordpress.com/2013/01/09/nokia-https-mitm/
https://gigaom.com/2013/01/10/nokia-yes-we-decrypt-your-https-data-but-dont-worry-about-it/
https://www.zdnet.com/article/nokia-hijacks-mobile-browser-traffic-decrypts-https-data/
http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799

Оригинал этой записи в личном блоге.

Мне тут вчера о паролях напомнили.. Так у меня вопрос есть про хранение пользовательских паролей на сервере.

Обычным способом является хранение хэша от пароля с приклеенной солью и самой соли открытым текстом. Иногда ещё используется дополнительная соль,  индивидуальная для экземпляра системы. Но суть в том, что хэш от всего этого считается один раз.

А в одном из веб-движков используется такая схема: hash(hash(password) . salt).

Вопрос: в чём смысл двойного хэширования?

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

С точки зрения подбора пароля по известному хэшу и соли – да, трудоёмкость операции увеличивается вдвое, но стоит ли овчинка выделки?

Умный человек ivlad предположил, что это делается для защиты от атаки с помощью предварительно рассчитанных “недохэшей”. Скажем, для мд5 длина блока данных 512 бит (64 байта). А пароли, даже вместе с солью, обычно сильно короче. Соответственно, при однократном хэшировании большая часть блока данных имеет известные значения, что позволяет применять некоторые атаки, сокращающие время подбора. А при использовании вышеуказанной схемы для второго хэширования будет взято 16 байт данных (или 32, если использовать текстовое представление) + соль. Всё ж побольше первоначального пароля. Фактически это получилась такая зачаточная PBKDF, увеличивающая длину ненулевых данных перед финальным хэшированием. Закат солнца вручную вместо использования проверенного профессионалами способа.

А ещё у кого-нибудь есть мысли, зачем это могло быть сделано?

Оригинал этой записи. Комментировать можно тут или там.

Some of the OpenSSH server host keys on this system were generated with a version of OpenSSL that had a broken random number generator. As a result, these host keys are from a well-known set, are subject to brute-force attacks, and must be regenerated.

Users of this system should be informed of this change, as they will be prompted about the host key change the next time they log in. Use 'ssh-keygen -l -f HOST_KEY_FILE' after the upgrade has changed to print the fingerprints of the new host keys.

The affected host keys are:

/etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_dsa_key

User keys may also be affected by this problem. The 'ssh-vulnkey' command may be used as a partial test for this. See /usr/share/doc/openssh-server/README.compromised-keys.gz for more details.

так сказала мне сегодня машинка при установке апдейтов

Важным преимуществом новой версии является технология, получившая название «виртуальный eToken» – она незаменима для пользователей, находящихся вне офиса и/или утративших свой персональный ключ eToken. В случае успешной проверки администратором подлинности удаленного пользователя ему может быть предоставлен «виртуальный eToken» – файл-аналог физического ключа eToken c ограничениями по времени использования.

Я раньше думал, что вся прелесть eToken'а заключается как раз в том, что он не дает возможности вытащить хранящиеся в нём приватные ключи, а умеет сам производить некоторые криптографические операции, выдавая наружу только результат.

В случае файла все эти операции должны производиться непосредственно на компьютере, а для этого необходим ключ, следовательно, его можно из файла вынуть. В чём тогда прелесть этого решения?

Или я чего-то не понял?

openssl s_client -connect сервер:порт
При необходимости можно добавить -CApath/-CAfile, -cert, -key, и вообще man 1 s_client.

о котором в недалёком прошлом было столько шума.
https://it.slashdot.org/story/05/11/15/2037232/md5-collision-source-code-released

а лучше скажите, существует ли в природе продукт, который живет под линуксом/фрёй и умеет общаться с Lucent'овским VPN-сервером по его разновидности IPSec, причем из-за NAT'а и с использованием pre-shared keys?

Родной люсентовский IPSec клиент есть только под винду, и эта сволочь после коннекта отрубает всю локальную сеть, а оставляет только шифрованное соединение.

Upd: гуглить пробовал, не помогает :(

Upd2: сменить сервер на нормальный не предлагать, это данность :(

https://www.schneier.com/blog/archives/2005/03/more_hash_funct.html
Коллизии в MD5. Eight hours on 1.6 GHz computer
Это кирдык, да?

via ivlad