Как я вижу новостной алгоритм фейсбука на самом деле.
У меня есть ряд друзей, на которых я подписан. Есть друзья, в постах которых я пишу.
В итоге у меня в ленте 30 постов с рекламой дешевых инди-игр, 40 с левыми рекомендациями, несколько повторяющихся реклам от агентств недвижимости, которые точно мошенники, но даже жалобы на их рекламу не выключают их, ибо проплачено.
В ленте застрял один постоянно надоедливо-повторяющийся пост знакомой, с которой мы два года назад работали на одной фирме, и жмакнули «В друзья» из вежливости и корпоративной этики, и один очень интересный для меня комментарий в новости, которая исчезает, потому что я нажал кнопку «Еще», чтобы развернуть текст, но улетел в другие комментарии. Кнопка браузера «Назад» уносит меня обратно, но больше я не увижу ни этой интересной новости, ни этого интересного для меня комментария.
Вот так примерно работает новостная лента фейсбука. А не вот так, как описано выше в посте.
Если вы захотите аутентифицироваться на другом компьютере, то подразумевается, что ему понадобится соль? Причем та же, что и была на предыдущем компьютере? Тогда если сервер пришлет ее в запросе любому, кто захочет аутентифицироваться, то все сведется к обычному перебору паролей по словарю. Берем пароль из словаря, берем соль, генерим ключи, пытаемся авторизоваться. Ну, то есть вот эта соль и ключи просто лишние телодвижения.
Получится одна большая сверхмассивная черная дыра + часть массы выделится в виде гравитационных волн, то есть результирующая черная дыра будет по массе меньше, чем две дыры до слияния. Само слияние происходит очень быстро, за миллисекунды. Пока есть вопрос в том, как вообще сближаются черные дыры — гуглите «проблему финального парсека».
Предел массы для черной дыры, которая набирает свою массу, «воруя» ее у окружающего пространства: это звезды, газ, пыль. Набрав 50+ миллиардов солнечных масс (самая большая сейчас 66 миллиардов), диск акреции, который окружает ЧД, и который является «поставщиком» вещества, станет слишком удаленным. От этого он начнет охлаждаться, «слипаться» в комки и распадется. А без акреционного диска дыра не растет.
То есть, ничто не мешает черной дыре «воровать» вещество или сливаться с другими черными дырами, просто вещество неоткуда будет уже взять.
Updated:
Кроме того, даже если допустить, что у черной дыры есть постоянный источник падающего на нее вещества, то чем больше массы падает в черную дыру, тем активнее ведет себя акреционный диск, и тем больше падающего на него вещества он выбрасывает обратно. То есть, скорость роста черной дыры конечна, даже если этого вещества падает завались сколько. Пройдут триллионы триллионов лет пока черная дыра наберет массу, чтобы ее классифицировать из «сверхмассивной черной дыры» во что-то следующее.
Да, согласен.
Жаль, выглядело неплохо, но действительно моя идея ничем не отличается от пароля, который слепили из двух частей.
С точки зрения хакера, он делает запросы «слово + пароль» для каждого аккаунта и получает все комбинации. Единственное, что его стесняет это дополнительные запросы к серверу для получения соли для каждого из пользователей вместо того, чтобы сразу получить ответ на нужную склеенную пару. А это и наши расходы в том числе. Их можно создать и без дополнительных солей.
Если украсть соль, то да. Могут быстро угнать аккаунт, особенно с простым паролем. Хорошо если вспомнишь, что забыл выйти из системы, и успеешь сменить пароль и секретное слово раньше, чем подберут пароль.
Можно не сохранять соль в куках. Она нужна лишь при вводе логина-пароля. Потом не нужна.
Вы ошибаетесь.
Если вы возьмете на подбор строку cat12345 — это одно.
Если вы берете cat и шифруете им 12345, то у вас получается вложенная зависимость.
Более того, вы не сообщаете нужно ли брать cat. А может и dog. А может и 42.
Технически Вам нужно перебрать все простые секретные слова по словарю и получить от сервера хэши. А потом перебрать со всеми этими хешами один простой пароль. Потом взять второй простой пароль и перебрать с ним все хэши опять. Потом третий, и так далее.
Это не тоже самое, что слепить две строки в одну и сказать, что пароль стал якобы сильнее. Комбинация 12345 будет верна только если ее зашифровать правильной солью. А комбинаций соли у вас весь ваш словарь. А ведь есть еще пароль 123456 и его тоже надо проверить со всеми хэшами от вашего словаря.
Да, в схеме дополнительный «пароль».
Технически секретное слово может быть как пустым, так и идентичным паролю. Но это, конечно, серьезно упростит перебор паролей.
Субъективно, я не считаю дополнительное поле сложным, хотя опыта в этой сфере у меня маловато (я про юзабилити и UI). Ведь есть, например, галочка «сохранить пароль», которая тоже потенциально отнимает внимание пользователя.
Я полностью согласен. Моя задача — попытаться усложнить жизнь мошенникам. Поэтому в концепте заведомо плохие примеры — короткие пароли и нарочито неосторожное поведение пользователей. Мне надо понять слабые места, и вообще определить не ошибся ли я. В реальности я никому не посоветую устанавливать пароль «12345».
Да, нужно три параметра. Добавляется секретное слово.
Логин и хэш из секретного слова могут быть в куках после первой попытки аутентификации, даже неуспешной. Пароль надо вводить руками каждый раз при аутентификации.
Если Вы берете первые три символа у пароля, тоже самое сделает и скрипт хакера. В моем случае хакер не знает чем солить. Он не может сгенерировать соль, не зная секретного слова. А подставлять просто секретное слово тоже не получится. Его должен захэшировать сервер своей солью, которую хакер не знает.
Предположим самое худшее — хакер решил брутфорсить не пароль, а секретное слово. Логин он знает, пароль тоже. Ему осталось зашифровать пароль и отправить его на сервер. Алгоритм хэширования у него тоже есть. Остался сущий пустяк — соль. Но какая соль правильная? Придется ее перебирать и проверять — но это возможно только если вы точно знаете, что пароль правильный.
Как этому можно противостоять? Усилить алгоритм ALG2 сложными расчетами, чтобы максимально усложнить перебор секретного слова с заведомо известным паролем.
Но даже без этого, скомпрометированным паролем воспользоваться сразу не удастся.
1) Два простых пароля — это пароль чуть сложнее. В моем примере простое секретное слово превращается в хэш, который используется, чтобы солить сам пароль. Это не два пароля вместе. Хэш секретного слова солится на сервере солью, которая нигде не публикуется.
2) Жена знает секретное слово — его можно оставлять прежним. А пароль можно менять и сообщать публично. Но только в троллейбусе, и только если Вашу жену зовут Галя :) Шучу, конечно. Я просто пытался обыграть ситуацию, что простой пароль как будто бы уже известен.
Ничто так не бесит, как лента новостей в фейсбуке. Листаешь ленту, разворачиваешь комментарий, но улетаешь на другую страницу. Возвращаешься назад — а у тебя уже другие новости, а ты еще те хотел дочитать. Ну хоть реклама постоянно повторяется, не пропустишь (сарказм).
случае нескольких одновременных обращений к записи с TTL1 < t < TTL2, в очереди будет находиться только 1 задача на обновление, а не несколько одинаковых.
Здесь не понял как и кто за этим следит. Все параллельные процессы инициализируют обновление кэша, так-как для каждого из них выполняется условие TTL1 < t < TTL2. И каждый процесс запустит эвент «кэш мне запили». Очередь, конечно, можно разобрать с условием, что есть только один подписчик, который обновляет кэш, и второе аналогичное задание он пропустит так-как t станет < TTL1 и < TTL2 но что если подписчиков больше одного? В общем, сама по себе концепция не дает возможности предотвратить двойное обновление кэша.
Плюс я не совсем уверен, что нужен второй TTL как таковой. Если есть доступ к значению времени истечения актуальности кэша, ставим сразу значение второго TTL, как основное, и при запросе пользователем данных, отдаем кэш, и проверяем сколько прошло времени. Если уже порядочно, то кидаем эвент на обновление кэша.
Насколько я помню, одной из проблем с жидкостью для дыхания было вымывание сурфактанта. Без сурфактанта легочные альвеолы слипаются и дыхание становится невозможным.
У меня есть ряд друзей, на которых я подписан. Есть друзья, в постах которых я пишу.
В итоге у меня в ленте 30 постов с рекламой дешевых инди-игр, 40 с левыми рекомендациями, несколько повторяющихся реклам от агентств недвижимости, которые точно мошенники, но даже жалобы на их рекламу не выключают их, ибо проплачено.
В ленте застрял один постоянно надоедливо-повторяющийся пост знакомой, с которой мы два года назад работали на одной фирме, и жмакнули «В друзья» из вежливости и корпоративной этики, и один очень интересный для меня комментарий в новости, которая исчезает, потому что я нажал кнопку «Еще», чтобы развернуть текст, но улетел в другие комментарии. Кнопка браузера «Назад» уносит меня обратно, но больше я не увижу ни этой интересной новости, ни этого интересного для меня комментария.
Вот так примерно работает новостная лента фейсбука. А не вот так, как описано выше в посте.
То есть, ничто не мешает черной дыре «воровать» вещество или сливаться с другими черными дырами, просто вещество неоткуда будет уже взять.
Updated:
Кроме того, даже если допустить, что у черной дыры есть постоянный источник падающего на нее вещества, то чем больше массы падает в черную дыру, тем активнее ведет себя акреционный диск, и тем больше падающего на него вещества он выбрасывает обратно. То есть, скорость роста черной дыры конечна, даже если этого вещества падает завались сколько. Пройдут триллионы триллионов лет пока черная дыра наберет массу, чтобы ее классифицировать из «сверхмассивной черной дыры» во что-то следующее.
Жаль, выглядело неплохо, но действительно моя идея ничем не отличается от пароля, который слепили из двух частей.
С точки зрения хакера, он делает запросы «слово + пароль» для каждого аккаунта и получает все комбинации. Единственное, что его стесняет это дополнительные запросы к серверу для получения соли для каждого из пользователей вместо того, чтобы сразу получить ответ на нужную склеенную пару. А это и наши расходы в том числе. Их можно создать и без дополнительных солей.
Жаль, что не увидел это сразу.
Можно не сохранять соль в куках. Она нужна лишь при вводе логина-пароля. Потом не нужна.
Если вы возьмете на подбор строку cat12345 — это одно.
Если вы берете cat и шифруете им 12345, то у вас получается вложенная зависимость.
Более того, вы не сообщаете нужно ли брать cat. А может и dog. А может и 42.
Технически Вам нужно перебрать все простые секретные слова по словарю и получить от сервера хэши. А потом перебрать со всеми этими хешами один простой пароль. Потом взять второй простой пароль и перебрать с ним все хэши опять. Потом третий, и так далее.
Это не тоже самое, что слепить две строки в одну и сказать, что пароль стал якобы сильнее. Комбинация 12345 будет верна только если ее зашифровать правильной солью. А комбинаций соли у вас весь ваш словарь. А ведь есть еще пароль 123456 и его тоже надо проверить со всеми хэшами от вашего словаря.
Технически секретное слово может быть как пустым, так и идентичным паролю. Но это, конечно, серьезно упростит перебор паролей.
Субъективно, я не считаю дополнительное поле сложным, хотя опыта в этой сфере у меня маловато (я про юзабилити и UI). Ведь есть, например, галочка «сохранить пароль», которая тоже потенциально отнимает внимание пользователя.
Логин и хэш из секретного слова могут быть в куках после первой попытки аутентификации, даже неуспешной. Пароль надо вводить руками каждый раз при аутентификации.
Предположим самое худшее — хакер решил брутфорсить не пароль, а секретное слово. Логин он знает, пароль тоже. Ему осталось зашифровать пароль и отправить его на сервер. Алгоритм хэширования у него тоже есть. Остался сущий пустяк — соль. Но какая соль правильная? Придется ее перебирать и проверять — но это возможно только если вы точно знаете, что пароль правильный.
Как этому можно противостоять? Усилить алгоритм ALG2 сложными расчетами, чтобы максимально усложнить перебор секретного слова с заведомо известным паролем.
Но даже без этого, скомпрометированным паролем воспользоваться сразу не удастся.
2) Жена знает секретное слово — его можно оставлять прежним. А пароль можно менять и сообщать публично. Но только в троллейбусе, и только если Вашу жену зовут Галя :) Шучу, конечно. Я просто пытался обыграть ситуацию, что простой пароль как будто бы уже известен.
Ничто так не бесит, как лента новостей в фейсбуке. Листаешь ленту, разворачиваешь комментарий, но улетаешь на другую страницу. Возвращаешься назад — а у тебя уже другие новости, а ты еще те хотел дочитать. Ну хоть реклама постоянно повторяется, не пропустишь (сарказм).
Если у вас мемкеш, посмотрите в сторону cas.
Здесь не понял как и кто за этим следит. Все параллельные процессы инициализируют обновление кэша, так-как для каждого из них выполняется условие TTL1 < t < TTL2. И каждый процесс запустит эвент «кэш мне запили». Очередь, конечно, можно разобрать с условием, что есть только один подписчик, который обновляет кэш, и второе аналогичное задание он пропустит так-как t станет < TTL1 и < TTL2 но что если подписчиков больше одного? В общем, сама по себе концепция не дает возможности предотвратить двойное обновление кэша.
Плюс я не совсем уверен, что нужен второй TTL как таковой. Если есть доступ к значению времени истечения актуальности кэша, ставим сразу значение второго TTL, как основное, и при запросе пользователем данных, отдаем кэш, и проверяем сколько прошло времени. Если уже порядочно, то кидаем эвент на обновление кэша.