Для современных криптографических хеш-функций найти коллизию сложнее, чем подобрать пароль адекватной длины. Для Argon2нужно перебрать 2^256 вариантов. Это, конечно, не 10^100, но 10^77 тоже неплохо.
Ну так это и есть скорость. И комбинация длинного пароля, соли и ресурсоемкого хеша делает невозможным как взлом конкретного пароля, так и создание радужных таблиц для перебора сразу всех.
Так для этого и нужен длинный пароль, чтобы каждым хешем надо было заниматься отдельно, а не за пару часов перебрать всю базу в сотню-другую тысяч пользователей. Мне кажется логичным, что надо предполагать, что взломщик как-то в этом заинтересован и ломает не на core2duo (или даже epyc или xeon), а как минимум на пачке видеокарт, что увеличивает скорость даже не знаю на сколько порядков.
На количество одноразовых паролей в единицу времени тоже обычно ставят ограничение (еще и потому, что сервису надо платить за каждую смску), реальный человек за минуту 100 одноразовых паролей не запросит. Больше 5 одноразовых паролей на операцию - подожди час, выглядит подозрительно.
Если 1 пароль можно захешировать за разумное время (а это необходимо чтобы этим пользоваться на практике), то и 10^4 паролей будут хешироваться не долго. Даже если хеширование занимает 1 минуту, то перебор всех четырехзначных цифровых паролей займет меньше 17 часов (и это без ферм карт, а на таком же сервере, что и атакуемые сервис).
Ну да, сочетание длинного пароля, соли и ресурсоемкого хеша увеличивает эту стоимость до такой, что даже 1 пароль нельзя взломать используя все вычислительные мощности планеты (по крайней мере те, о которых известно) за миллиарды лет. Мне кажется это достаточно хорошо гарантирует сохранность пароля даже при утекших хешах с солью.
Как раз весь смысл хеширования паролей (и соли) в том, что даже если база утекла нельзя было эти пароли получить. Точнее можно было, но (на текущем железе) это занимало бы миллиарды лет. Самый простой пример: пароли из одной цифры. Есть всего 10 вариантов, тут ни соль не поможет (слишком мало вариантов, можно быстро проверить все варианты с заданной солью), ни криптографические хеш-функции (если хеш-функция работает адекватное время для проверки одного пароля, то для 10 вариантов она тоже работает за небольшое время). А вот если пароли состоят из 100 цифр, то это уже 10^100, такое уже при всем желании (с использованием всех вычислительных мощностей планеты) не получится, вариантов слишком много. За этим и нужно и использовать длинные пароли (увеличиваем количество вариантов), и использовать медленные и затратные по памяти хеш-функции (увеличиваем время (или стоимость в деньгах) проверки одного варианта), и соль (чтобы нельзя было 1 раз предпосчитать все варианты до длины n и переиспользывать).
что же вам сделает нехорошее приложение, утянувшее ваши GPS координаты?
Я боюсь, например, того, что оно может эти данные утечь. И к уже слитым данным добавятся еще и GPS треки маршрута дом-работа-дом, вполне вероятно что и с метками времени. И теперь не только ФСБ может меня найти, а любой человек, кто готов потратить 30 минут и узнать, как сейчас называется бот для пробива. У меня, конечно же, есть полная уверенность в том, что Яндекс (и добрая половина из установленных у меня на телефон приложений) очень серьезно относится к защите персональных данных и в случае утечки они получат ужасающий по своим последствиям штраф в 60 тысяч рублей (не знаю, если в Яндексе хоть 1 сотрудник с ЗП в месяц меньше).
Про требование ФСБ к операторам такси предоставлять прямой к доступ к базе заказов и текущим перемещениям клиентов слышали?
За последние лет 10 я такси пользовался 1 раз. Даже если ФСБ так уж захочется узнать этот мой маршрут я смогу это пережить. А доступ к истории перемещений это уже совсем другое.
Не того вы боитесь, не там у вас маркеры опасностей расставлены
Спасибо за ваше мнение, я сам как-нибудь разберусь чего мне следует бояться и что с этим делать.
Так а зачем выдавать, если можно не выдавать? По закону не надо, это проблемы призывника, что у него возможности ознакомиться не было. Как с письмами от налоговой, это ваша проблема, если налоговая по какой-то причине эти письма по другому адресу шлет, счета заблокируют спокойно и потом ходи и доказывай, что это у них в системе адрес неправильный.
В чем вранье? Ну вот стою я непонятно где, возле моста, и начинаю звонить и объяснять, эээ... улица..... ээээ.... ну у моста... так, тут киоск еще такой белый, и фонарь... Точный адрес говорите? Сейчас сейчас.... Я перезвоню.
Это ложная дихотомия, Существует не только "удобно через приложение" и "ужас с помощью звонка". Как минимум несколько лет назад яндекс такси можно было и через сайт с компьютера заказать вообще без проблем, не знаю как сейчас. Да даже без этого я предпочту заказать такси через телефон, слишком уж яндексу много данных от меня хочется. У меня уже отдельный телефон для приложений с сомнительными разрешениями есть, а то бесит, что каждому второму доступ к GPS, sms и звонкам нужен. А если еще и к совершению звонков разрешение (и это не приложение для совершения звонков), то это вообще замечательно.
Наследование и дженерики понятия не связанные, они друг с другом не связаны и друг на друга не влияют.
Для дженериков есть трейты, они очень хорошо эту задачу выполняют.
Вместо наследования можно использовать композицию (добавлять "наследуемый" тип в качестве внутреннего поля). Чтобы не было так больно копипастить не изменившиеся методы есть, например, delegate.
Первый тип не сложный, легко пишется, и неплохо помогает, но все же не настолько могущественны как второй тип.
Чтобы макросы второго типа (я просто не уверен, как нормально это "Macro By Example" перевести, чтобы было понятно что это) писать было проще и веселее можно использовать другие макросы, например quote. Вот мой личный пример его использования.
Не надо оператор is использовать для сравнения чисел, это не проверка на равенство, а проверка идентичности (т.е. что объект один и тот же) ((0.1+0.2) == 0.3 тоже выведет False).
Вот пример, почему такое его использование приведет к проблемам:
Заголовок спойлера
x = 100
y = 100
print(x is y) # Output: True
print(id(x))
print(id(y))
x += 100
y += 100
print(x is y) # Output: True
print(id(x))
print(id(y))
x += 100
y += 100
print(x is y) # Output: False
print(id(x))
print(id(y))
Не понятно написал, попробую раскрыть мысль в этом комментарии. Я "подсадил" друзей и родственников на эти программы. Они, как раз, более чем обычные пользователи и GUI могут пользоваться yt-dlp без проблем. Но часто ютуб ломает своё все, из-за чего ломается yt-dlp и мне приходится этим людям объяснять:
как и что нужно скачать с гитхаба;
как найти расположение файла по ярлыку;
куда же этот новый yt-dlp нужно положить
и т.д.
То есть люди как раз самые что ни на есть обычные и кроме этого у них особых проблем после начальной настройки нет.
Для yt-dlp можно без проблем найти отдельные GUI, вроде Open Video Downloader или Seal. Объяснять, как обновить yt-dlp после очередного обновления ютуба сложно, но вполне возможно.
Оракл в свое время начал выпуск своей СУБД с версии 2, мотивируя тем, что никто не хочет пользоваться первой версией
Так в этом и проблема. Сам по себе номер версии вообще ничего не значит. Изменение минорной версии не гарантирует, что у кода не изменилось API (хотя для этого есть помощники). Можно тогда просто на версии с датами перейти (вроде 2024.04.1), код надежнее это не сделает, зато выглядит солидно.
С 0.X.Y версиями ситуация получается странная - даже если библиотека уже готова для использования в продакшен среде, то переход на 1.0.0 создаст много проблем с не очевидными выгодами. Менять мажорную версию без нарушений обратной совместимости странно, т.к. cargo автоматически не обновит версию с 0.X.Y до 1.0.0, что заставляет всех пользователей библиотеки делать это вручную. А из плюсов только то, что версия 1.0.0+ выглядит солиднее.
Так и написали бы об этом. Все, что в вашем примере кода говорит о том, что там уже есть многопоточность - это три буквы par. А, как в статье и написано, у меня 0 опыта в C++, я понятия не имею, что эта штука сделает. Вместо обвинений в токсичности лучше бы написали такой комментарий, он был бы гораздо полезнее для всех.
То есть, вы считаете, что эта статья о сравнение Rust и C (даже проигнорируем тот факт, что я так не считаю, просто часто это то, как люди воспринимают Rust. С Python и Golang сравнений больше), подменяете его своим аргументом "в контексте сравнения с C++, потому что считаю сравнение Rust и Си бессмысленным и просто неправильным" и пытаетесь разбить уже свой собственный аргумент? Да это же соломенное чучело.
1234на 16-ом месте по популярности в 2023 году, кстати.Для современных криптографических хеш-функций найти коллизию сложнее, чем подобрать пароль адекватной длины. Для Argon2 нужно перебрать 2^256 вариантов. Это, конечно, не 10^100, но 10^77 тоже неплохо.
Ну так это и есть скорость. И комбинация длинного пароля, соли и ресурсоемкого хеша делает невозможным как взлом конкретного пароля, так и создание радужных таблиц для перебора сразу всех.
Так для этого и нужен длинный пароль, чтобы каждым хешем надо было заниматься отдельно, а не за пару часов перебрать всю базу в сотню-другую тысяч пользователей. Мне кажется логичным, что надо предполагать, что взломщик как-то в этом заинтересован и ломает не на core2duo (или даже epyc или xeon), а как минимум на пачке видеокарт, что увеличивает скорость даже не знаю на сколько порядков.
На количество одноразовых паролей в единицу времени тоже обычно ставят ограничение (еще и потому, что сервису надо платить за каждую смску), реальный человек за минуту 100 одноразовых паролей не запросит. Больше 5 одноразовых паролей на операцию - подожди час, выглядит подозрительно.
Если 1 пароль можно захешировать за разумное время (а это необходимо чтобы этим пользоваться на практике), то и 10^4 паролей будут хешироваться не долго. Даже если хеширование занимает 1 минуту, то перебор всех четырехзначных цифровых паролей займет меньше 17 часов (и это без ферм карт, а на таком же сервере, что и атакуемые сервис).
Ну да, сочетание длинного пароля, соли и ресурсоемкого хеша увеличивает эту стоимость до такой, что даже 1 пароль нельзя взломать используя все вычислительные мощности планеты (по крайней мере те, о которых известно) за миллиарды лет. Мне кажется это достаточно хорошо гарантирует сохранность пароля даже при утекших хешах с солью.
Как раз весь смысл хеширования паролей (и соли) в том, что даже если база утекла нельзя было эти пароли получить. Точнее можно было, но (на текущем железе) это занимало бы миллиарды лет. Самый простой пример: пароли из одной цифры. Есть всего 10 вариантов, тут ни соль не поможет (слишком мало вариантов, можно быстро проверить все варианты с заданной солью), ни криптографические хеш-функции (если хеш-функция работает адекватное время для проверки одного пароля, то для 10 вариантов она тоже работает за небольшое время). А вот если пароли состоят из 100 цифр, то это уже 10^100, такое уже при всем желании (с использованием всех вычислительных мощностей планеты) не получится, вариантов слишком много. За этим и нужно и использовать длинные пароли (увеличиваем количество вариантов), и использовать медленные и затратные по памяти хеш-функции (увеличиваем время (или стоимость в деньгах) проверки одного варианта), и соль (чтобы нельзя было 1 раз предпосчитать все варианты до длины n и переиспользывать).
Я боюсь, например, того, что оно может эти данные утечь. И к уже слитым данным добавятся еще и GPS треки маршрута дом-работа-дом, вполне вероятно что и с метками времени. И теперь не только ФСБ может меня найти, а любой человек, кто готов потратить 30 минут и узнать, как сейчас называется бот для пробива. У меня, конечно же, есть полная уверенность в том, что Яндекс (и добрая половина из установленных у меня на телефон приложений) очень серьезно относится к защите персональных данных и в случае утечки они получат ужасающий по своим последствиям штраф в 60 тысяч рублей (не знаю, если в Яндексе хоть 1 сотрудник с ЗП в месяц меньше).
За последние лет 10 я такси пользовался 1 раз. Даже если ФСБ так уж захочется узнать этот мой маршрут я смогу это пережить. А доступ к истории перемещений это уже совсем другое.
Спасибо за ваше мнение, я сам как-нибудь разберусь чего мне следует бояться и что с этим делать.
Так а зачем выдавать, если можно не выдавать? По закону не надо, это проблемы призывника, что у него возможности ознакомиться не было. Как с письмами от налоговой, это ваша проблема, если налоговая по какой-то причине эти письма по другому адресу шлет, счета заблокируют спокойно и потом ходи и доказывай, что это у них в системе адрес неправильный.
Это ложная дихотомия, Существует не только "удобно через приложение" и "ужас с помощью звонка". Как минимум несколько лет назад яндекс такси можно было и через сайт с компьютера заказать вообще без проблем, не знаю как сейчас. Да даже без этого я предпочту заказать такси через телефон, слишком уж яндексу много данных от меня хочется. У меня уже отдельный телефон для приложений с сомнительными разрешениями есть, а то бесит, что каждому второму доступ к GPS, sms и звонкам нужен. А если еще и к совершению звонков разрешение (и это не приложение для совершения звонков), то это вообще замечательно.
Наследование и дженерики понятия не связанные, они друг с другом не связаны и друг на друга не влияют.
Для дженериков есть трейты, они очень хорошо эту задачу выполняют.
Вместо наследования можно использовать композицию (добавлять "наследуемый" тип в качестве внутреннего поля). Чтобы не было так больно копипастить не изменившиеся методы есть, например, delegate.
Еще для снижения количества копипасты есть макросы, даже 2 вида: Macros By Example и процедурные макросы.
Первый тип не сложный, легко пишется, и неплохо помогает, но все же не настолько могущественны как второй тип.
Чтобы макросы второго типа (я просто не уверен, как нормально это "Macro By Example" перевести, чтобы было понятно что это) писать было проще и веселее можно использовать другие макросы, например quote. Вот мой личный пример его использования.
Не надо оператор
isиспользовать для сравнения чисел, это не проверка на равенство, а проверка идентичности (т.е. что объект один и тот же) ((0.1+0.2) == 0.3тоже выведетFalse).Вот пример, почему такое его использование приведет к проблемам:
Заголовок спойлера
Не понятно написал, попробую раскрыть мысль в этом комментарии. Я "подсадил" друзей и родственников на эти программы. Они, как раз, более чем обычные пользователи и GUI могут пользоваться yt-dlp без проблем. Но часто ютуб ломает своё все, из-за чего ломается yt-dlp и мне приходится этим людям объяснять:
как и что нужно скачать с гитхаба;
как найти расположение файла по ярлыку;
куда же этот новый yt-dlp нужно положить
и т.д.
То есть люди как раз самые что ни на есть обычные и кроме этого у них особых проблем после начальной настройки нет.
Для yt-dlp можно без проблем найти отдельные GUI, вроде Open Video Downloader или Seal. Объяснять, как обновить yt-dlp после очередного обновления ютуба сложно, но вполне возможно.
Это не автор считает, это стандарт так считает.
Так в этом и проблема. Сам по себе номер версии вообще ничего не значит. Изменение минорной версии не гарантирует, что у кода не изменилось API (хотя для этого есть помощники). Можно тогда просто на версии с датами перейти (вроде 2024.04.1), код надежнее это не сделает, зато выглядит солидно.
С
0.X.Yверсиями ситуация получается странная - даже если библиотека уже готова для использования в продакшен среде, то переход на1.0.0создаст много проблем с не очевидными выгодами. Менять мажорную версию без нарушений обратной совместимости странно, т.к. cargo автоматически не обновит версию с0.X.Yдо1.0.0, что заставляет всех пользователей библиотеки делать это вручную. А из плюсов только то, что версия1.0.0+выглядит солиднее.Так и написали бы об этом. Все, что в вашем примере кода говорит о том, что там уже есть многопоточность - это три буквы
par. А, как в статье и написано, у меня 0 опыта в C++, я понятия не имею, что эта штука сделает. Вместо обвинений в токсичности лучше бы написали такой комментарий, он был бы гораздо полезнее для всех.То есть, вы считаете, что эта статья о сравнение Rust и C (даже проигнорируем тот факт, что я так не считаю, просто часто это то, как люди воспринимают Rust. С Python и Golang сравнений больше), подменяете его своим аргументом "в контексте сравнения с C++, потому что считаю сравнение Rust и Си бессмысленным и просто неправильным" и пытаетесь разбить уже свой собственный аргумент? Да это же соломенное чучело.