Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
А не лучше ли вместо этого всего контрол с адресом разбить на два контрола: спереди хеш, сзади — сам адрес? Хеш и адрес можно сокращать многоточием в середине. Юзер будет проверять первые и последние цифры и хеша, и адреса. Математика позволяет добиться похожего адреса, обладающего похожим хешом?
Так об этом, собственно и расписано, просто материалов было очень много, я на все не сослался в статье:
Как люди сравнивают отпечатки:
Perrig, Song. Hash Visualization: a New Technique to Improve Real-World Security. 1999. https://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf
Исходное предложение показывать хэш картинкой (Random Art), потому что люди сравнивают изображения лучше, чем строки. Отправная точка всей области и hh.
Hsiao, Lin, Studer, Studer, Wang, Kikuchi, Perrig, Sun, Yang. A Study of User-Friendly Hash Comparison Schemes. ACSAC 2009. https://netsec.ethz.ch/publications/papers/visual_hash_acsac09.pdf
Онлайн-исследование более 400 человек, десять способов показа хэша. При одинаковых 24 битах T-Flag (8 блоков, 8 цветов, различимых при дальтонизме) дал 85 % верных ответов на трудных парах, Flag Extension (цвет плюс форма в блоке) 88 %, а Flag с 64 мелкими оттенками упал до 50 %, то есть до случайного угадывания. Отсюда правила hh: мало категориальных цветов, форма поверх цвета, никаких тонких оттенков.
Olembo, Kilian, Stockhardt, Hülsing, Volkamer. Developing and Testing a Visual Hash Scheme. HAISA 2013. https://huelsing.net/wordpress/wp-content/uploads/2013/05/haisa-visualhash.pdf
Отмечает, что люди надёжно различают не более примерно 30 бит существующих визуальных хэшей, и строит CLPS (цвета, линии, узоры, фигуры) на 60 бит. Трудные пары распознаны верно в 96,6 % случаев рядом в лаборатории, но в 73,4 % в реалистичной проверке электронного голосования и в 78,6 % при проверке сертификата HTTPS. Поэтому hh считает картинку дополнением к проверке текста и требует сравнения бок о бок.
Dechand, Schürmann, Busse, Acar, Fahl, Smith. An Empirical Study of Textual Key-Fingerprint Representations. USENIX Security 2016. https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_dechand.pdf
1 047 участников и шесть текстовых форматов: привычная шестнадцатеричная запись сильнее других уязвима для атак частичного совпадения, а изменения люди замечают в основном на «якорях» (начало, конец, переносы строк). Именно эту слабость использует отравление адресов.
Ну так, вот это:
Исходное предложение показывать хэш картинкой (Random Art), потому что люди сравнивают изображения лучше, чем строки. Отправная точка всей области и hh.
выглядит очень сомнительно. По крайней мере, конкретно в этой реализации (не огорчайтесь на меня). Научно всё разнесено, а визуально цвета не контрастируют. Я и так, и этак с ними играл… пробовал обводить слияние пустых квадратиков, как в тетрисе, чтобы отличие лучше видеть, пробовал задавать цвет фона, и результат мне всё равно не понравился.
Как человек я бы гораздо лучше сравнивал так, как показано ниже.
Было:
[ d9a1…3a91 ]
[ d9a1…3a91 ]
Стало:
[ f563…3a91 ] [ d9a1…3a91 ]
[ 12d0…6b02 ] [ d9a1…3a91 ]
Мне кажется, самое главное - подсветить проблему, показать пример решения, объяснить разработчикам и пользователям. А по итогу конечный пользователь выберет наиболее удобное решение: можно ведь разные словари использовать: картинки, тэги, emoji, хеши и т. д.
Научно всё разнесено, а визуально цвета не контрастируют.
Не только цвета. Квадрат-круг, треугольники в разные стороны - тоже не так чтобы визульно друг от друга отличаются.
Вообще, тут смешано три случая
1) Сравнить битовые строчки по устному/текстовому каналу. Тут вообще больше подходят разны текстовые кодировки.
2) Визуально убедиться что произвольные битовые строчки совпадают.
3) Находить нужную, не ошибаясь, но в конечном списке. Тут вообще полный хэш выводить не надо. Достаточно выводить наименьший попарно различный элемент.
Грубо говоря, для текста: если в списке есть только один Саша Какой-То - то его в списке можно просто Сашей звать. А Саши два - то выводить их фамилии, не имя. А если еще кто-то с такой фамилией есть - то писать для них Имя-Фамилия.
Для визуальных хэшей - что-то аналогичное. (Если он в списке есть только один, начинающийся с квадрат-треугольник, то остальное можно не рисовать)
Представление становится зависимым от окружения, но зато становится значительно короче и легче для попарного сравнения.
3) Находить нужную, не ошибаясь, но в конечном списке. Тут вообще полный хэш выводить не надо. Достаточно выводить наименьший попарно различный элемент.
Если предполагается, что элементы списка должны совпадать, а они различаются, то выводить надо не наименьший попарно различный элемент, а большой алярм об угрозе.
Но в случае с History, по-моему, ничего такого не предполагается. Может, и зря. Может ли такое происходить в норме? Чтобы два адреса различались только серединой? Если нет, вполне можно просто предупреждать юзера.
Но в случае с History, по-моему, ничего такого не предполагается
В случае истории нам нужно, чтобы совпадающие(по адресу) позиции - выглядели одинаково, а различные - по разному.
Если брать ту картинку, что был, можно сообразить что-то вроде (подсвечиваем минимальный набор, который всех отличает)
Такого
не заставляя пользователя все 16 фигур хэша визуально сравнивать. Тут сразу видно что первый и второй - разные.
Разумеется, если предпологается, что подтом нужно будет сравнить картинку на постороннем устройстве с тем что в списке видно - так делать нельзя. Это именно для сценария 'понять кто тут то же самое, а что нет'.
Ну и нужно, очевидно, починить вот эти 0x9A1..3a91. Добавляя в пропуск буквы (можно не те же самые, что там реально стоят, а просто индикаторные). Чтобы если полный адрес разный - то и сокращения были разными.
Я совершенно далек от всяких криптовалют - зашел посмотреть на очередной identicon, т.к. они полезны.
И проблемного сценария не понял. Точнее, не понял, откуда оно вообще взялось.
Описано как
Злоумышленник следит за переводами. Вы платите Алисе. Через несколько минут в вашей истории появляется новая строка с адресом, который начинается и заканчивается так же, как адрес Алисы. В следующий раз, когда вы платите Алисе, вы открываете историю, копируете «её» адрес, а он не её.
И дальше картинка "Слева: то, что показывает большинство кошельков." с этой самой историей c одними HEX что справа что слева.
Сдается мне, что тут создатели кошельков создали сами себе проблему на ровном месте. Там сразу должно бы рисоваться что-то в духе "неизвестный контрагент".
Более того, мне непонятно желание искать адрес счета Алисы в этом самом списке, а не в оригинальном сообщении от нее "Деньги слать сюда". Причем искать по адресу отправителя(чтобы попасться на адрес злодея), а не получателя.
Более того, мне непонятно желание искать адрес счета Алисы в этом самом списке
Тут возможны различные сценарии:
1. Использование блокчейн эксплорера вместо списка транзакций кошелька (ну они зачастую быстрее или когда открыто окно отправки транзакции, неудобно лезть в другой фрейм)
2. Автодополнение адреса самим кошельком, с сортировкой по времени транзакций (такая проблема была в Trust Wallet, но вроде пофиксили)
Почему взяли шаблон 4х4, а не 3х3?
Вот специально сравнивал представленные наборы и постоянно ловил себя на том, что сравниваю только фигуры на углах квадрата, а торцевые, и тем более центральные - гораздо меньше. Ибо "многабукаф, глазки ленятся".
А вот сетку 3х3 визуально сравнить гораздо проще и наглядее - глаз сам находит несоответствие.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атаки с подменой адреса: Никто не проверяет 42 символа