Перед столкновением частицы разгоняют до скоростей как можно более близким к скоростям света, но все таки, когда они сталкиваются друг об друга их скорость друг относительно друга больше скорости света или нет?
Кто в теме скажите, вот разгоняют два протона и бьют друг об друга, потом смотрят что с осколками, а есть ли эксперименты над битьем осколков друг об друга?
Еще вопрос, правда очень тяжело его сформулировать.
Все эксперименты упираются в поиск частиц. Есть ли эксперименты по поиску не частиц, а чего то другого?
Насколько я понимаю считается что частица может существовать везде, но так ли это? Нет ли такого своеобразного океана где могут существовать частицы и чего-то другого где они существовать не могут?
C бозоном Хиггса непонятно, обнаружили его в итоге или нет?
То что вы описываете очень далеко от реальных банковских проблем (бизнеса). Самое интересно это будет внутри — взаимодействие с клиентами.
Выдать кредит хоть по скорингу хоть через аналитика это легко. Вот блокчейн коллекшн (выбивание долгов) вот это тема.
Другой интересный вопрос — как бороться с человеческой глупостью в части утери криптоключей?
В битконе потерял приватный ключ — все наигрался. В обычных клиент-банках это происходит относительно часто.
Ну как говорится респект и уважуха в вашем начинании. Буду ждать следующих серий ваших приключений.
P.S. Про современные технологии. Был опыт внедрения IVR-решения для персонализации пластиковых карт. 30% клиентов — лиц пожилого возраста (основные вкладчики любого банка) не могли набрать на телефоне T-CODE…
Криптовалюта, криптостартап — инструменты направленные на скрытие данных о владельце счетов или компании.
Не совсем понятно, если вы будете пользоваться этим, то как вы будете дружить с FATF, как сдавать отчетность в США по FATCA?
Если же вы идентифицируете владельца, то не о каком крипто не может быть и речи. Просто используете существующие блокчейн решения.
Хотеть купит дешевле, а продать дороже это нормальная ситуация в рыночной экономике.
Судя по статье вы описываете ценовой конфликт с одним из клиентов. Называете его среднюю сумму чека, оборот и т. д., причем делаете без ссылки на раскрывающие данные предоставленные самой компанией. Если это не ваш клиент, значит у вас есть инсайд. Погуглив я такой информации не нашел.
Конечно считать чужие деньги всегда интересно, но делать это публично, мягко говоря не этично, а делать это в отношение клиента…
Коллеги, сори за офтоп, но не удержался. SAP HANA на мой взгляд не самая удачное название для России, у меня почему то все оно превращаться в «Хана сапу», то есть все нет больше сапа.
Хотел уточнить следующие моменты:
1. Как хранится (где и сколько времени) статистика по доступу пользователей в Инет? Какая есть аналитика?
2. Packet Capture с какой скоростью может писать? Какой максимальный размер захвата и в каком формате хранятся данные?
3. Можно ли повесить сертификат (настроить TLS) на страницу аутентификации пользователей? Золотое правило безопасности гласит, что любая аутентификационная информация должна передаваться по защищенному каналу (а не по голому HTTP).
4. Поддерживается ли аутентификация пользователей по сертификатам (smart cards)?
Когда мы оцениваем качество работы автопилотов, то мы сравниваем их с профессиональными водителями, которые водят машины всю жизнь и убеждаемся, что человек все-таки лучше.
Но если сравнить автопилот с новичком, который только получил / купил права, но который уже имеет право перевозить людей, результат подобного сравнения скорее всего изменится диаметрально противоположно.
С точки зрения дизайна в чем проблема добавить round-trip?
На сколько я понимаю, авторизация происходит один раз, при установки сессии при этом если у вас будут 2 пакета или 10 пользователь разницы не заметит.
Конечно можно предположить что плохо написанный софт будет строить и рвать сессию на каждом SQL-операторе, но и в этом случае изменение количества пакетов используемых для авторизации вряд ли существенно исправить ситуацию с быстродействием.
С другой стороны, помогая «криворуким» программистам вы закладываете в систему проблемы безопасности которые отразятся на всех пользователях.
На практике, проводя аудит безопасности систем, когда открываешь табличку с паролями пользователей и видишь что у половины из них одинаковые коды паролей (хэши) испытываешь смешанные чувства… причем, для самого распространённого пароля — «1» можно даже визуально запомнить хэш.
Хочу отметить, что взлом через радужные таблицы это все таки не brute force.
Радужные таблицы mixaplhanumeric1-12 дадут злоумышленикам очень хорошие результаты по взлому любых систем построенных по аналогичной схеме вообще. Причем атака будет проводиться практически в режиме реального времени и для этого могут использоваться облачные сервисы, фактически похачить можно с мобильника.
Фишинговые домены построенные на базе typosquatting это атака на клиентов. Причем у них вообще может не быть каких-либо инструментов защиты, единственной действенной защитой в данном случае будет только их оперативное разделегирование фишинговых доменов. Просить клиентов использовать Cisco OpenDNS в качестве DNS серверов кажеться мало перспективным. Поправите пожалуйста если я ошибаюсь.
Функционал упомянутый в статье есть также в Bot-Treck intellegence от Group-IB, но там возможности больше, они также ищут фишинг по использованию фирменных логотипов и др.
Расскажите пожалуйста в чем преимущества описанного выше решения от Cisco от аналогичных решений ваших конкурентов и кого вы рассматриваете в качестве основных конкурентов.
Основная проблема всех этих робоферм — использование электрической подсветки.
Растениям нужен свет для них это как еда для нас. На «экономичных» лампах дневного света вырастит тоже экономично, а вернее ничего. Кто не верит посмотрите про промышленные теплицы и какой свет там используется многое станет ясным.
Робо-ферма за 230к$… в Российской действительности, когда сельским хозяйством занимаются люди с оплатой в районе МРОТ на эти деньги несколько десятилетий будем работтать целый колхоз, труд которого сможет прокормить средний Российский город.
На текущий момент, это все интересно только с академической точки зрения, до тех пор пока не найдется дешевых источников освещения и отопления. Подобные фермы будут иметь смысл только в районах где завоз свежей продукции дорог или недоступен, либо когда за свежую зелень люди готовы переплачивать.
Ну, что же, задумки и стремления у вас хорошие, но результирующий шифратор практической ценности не имеет.
Вы теперь знаете куда копать и если будете на выходе вашего шифратора получать устойчивый белый шум, качество которого будет одинаковым вне зависимости от открытого текста и ключевой информации напишите об этом.
В предлагаемой вами схеме все таки есть уязвимость и она в следующем.
Получая закрытый ключ из пароля, а затем открытый ключ из закрытого мы имеем своеобразный аналог псевдо-хэш функции, вида F(пароль)=открытый ключ,
А следовательно на нее будут распространятся атаки справедливые атакам на системы аутентификации использующие чистый хэш.
Пример 1. Хакер Али, сделал себе пароль «qwerty», получил хэш «0xAABB», дальше он крадет таблицу с открытыми ключами пользователей и ищет строки «0xAABB». Дальше думаю понятно
Пример 2. Хакер Зина, украла таблицу с открытыми ключами. У нее есть pre-computed таблицы (например, rainbow table) вида пароль-открытый ключ, где вместо хэш функции используется функция получения открытого ключа по хэшу. Дальше классическая атака через pre-computed таблицы.
Пример 3. Хакер Джэк является MiTM. При авторизации он подменяет scramble идущий от сервера на свой. У Джека есть pre-computed таблица вида свой свой исходный пароль — подписанный scrumble. Дальше аналогично (2).
Таким образом фундаментальной проблемой схемы является генерация ключей на базе «чистых паролей пользователей». Для ее устранения подобных проблем в схему нужно добавлять случайность — соль для каждого пароля.
А что вы думаете о возможности замены / использования криптоалгоритмов на современные Российские ГОСТы, в частности ГОСТ 34.11-2012 для хэша и ГОСТ Р 34.10-2012 для подписи? Да и блочного шифра ГОСТ 34.12-2015?
Алгоритмы есть в свободном доступе, они сертифицированы, по ним работает, например вся банковская система России, доверие к ним есть.
Подскажите, почему выбор пал на ed25519 в качестве основного криптоалгоритма?
Если вы упомянули банки и их запросы, то для них более спокойно было бы если вы использовали какой-либо сертифицированный / стандартизованный / рекомендованный алгоритм.
Проводили ли тесты на криптостойкость подобного шифрования?
Глубокого вдаваться в теорию не буду, но основной смысл шифрования это преобразование «разумного» текста в белый шум или набор случайных чисел.
Самый простой тест — возьмите текст, зашифруйте вашим способом, а потом попробуйте скормить архиватору — если текст жмется значит качество результирующего материала плохое. Тут конечно могут быть нюансы с кодировками и т. д. Поэтому проверять лучше на двоичных данных.
Второй тест. Возьмите тест состоящий из одинаковых символов и зашифруйте. Затем возьмите исходный текст. поменяйте в нем один символ и снова зашифруте. Сравните результаты. Если тексты отличают минимально, значит с шифрованием проблемы.
Если все хорошо, можно исследовать дальше свой шифр с помощью тестов NIST для генераторов случайных чисел
Если закрыть этот «баг» то завершение сеансов неквалифицированных пользователей, которые не закрывают RDP-сессии превратиться в сущий ад. Кто не в теме, просто дропать сеансы не всегда можно, там может потребоватьcя еще сохранить мегаважный Excel.
С точки зрения безопасности, доводы не убедительный. В случае компрометации админа или SYSTEM злоумышленики смогут сделать все тоже а даже больше другими инструментами.
В телеком провайдерах самая бесящая вещь — это тех. поддержка. Сделайте нормальный суппорт и люди к вам потянутся. Скорость / глюки / деньги у всех примерно равны.
На мой взгляд происходящее не совсем корректно. Google имеет зуб на Symantec за левый сертификат на себя, что и справедливо.Но Google предвзят, и это очевидно. Где гарантия того что он напроверял правильно?
Чтобы избежать конфликта интересов должна быть независимая организация устанавливающая требования и проверяющая удостоверяющие центры, возможно даже при ООН или IEEE или аналогичной организации, а производители браузеров должны будут ей подчинятся.
И именно ее результаты ее проверок должны иметь вес. Не исключаю что Symantec сильно накосячил, но подобный подход создает не хороший прецедент. Когда одна компания с высокой долей рынка начинает оказывать давление на другую.
Еще вопрос, правда очень тяжело его сформулировать.
Все эксперименты упираются в поиск частиц. Есть ли эксперименты по поиску не частиц, а чего то другого?
Насколько я понимаю считается что частица может существовать везде, но так ли это? Нет ли такого своеобразного океана где могут существовать частицы и чего-то другого где они существовать не могут?
C бозоном Хиггса непонятно, обнаружили его в итоге или нет?
Выдать кредит хоть по скорингу хоть через аналитика это легко. Вот блокчейн коллекшн (выбивание долгов) вот это тема.
Другой интересный вопрос — как бороться с человеческой глупостью в части утери криптоключей?
В битконе потерял приватный ключ — все наигрался. В обычных клиент-банках это происходит относительно часто.
Ну как говорится респект и уважуха в вашем начинании. Буду ждать следующих серий ваших приключений.
P.S. Про современные технологии. Был опыт внедрения IVR-решения для персонализации пластиковых карт. 30% клиентов — лиц пожилого возраста (основные вкладчики любого банка) не могли набрать на телефоне T-CODE…
Не совсем понятно, если вы будете пользоваться этим, то как вы будете дружить с FATF, как сдавать отчетность в США по FATCA?
Если же вы идентифицируете владельца, то не о каком крипто не может быть и речи. Просто используете существующие блокчейн решения.
Судя по статье вы описываете ценовой конфликт с одним из клиентов. Называете его среднюю сумму чека, оборот и т. д., причем делаете без ссылки на раскрывающие данные предоставленные самой компанией. Если это не ваш клиент, значит у вас есть инсайд. Погуглив я такой информации не нашел.
Конечно считать чужие деньги всегда интересно, но делать это публично, мягко говоря не этично, а делать это в отношение клиента…
А в целом решение и статья интересные.
Хотел уточнить следующие моменты:
1. Как хранится (где и сколько времени) статистика по доступу пользователей в Инет? Какая есть аналитика?
2. Packet Capture с какой скоростью может писать? Какой максимальный размер захвата и в каком формате хранятся данные?
3. Можно ли повесить сертификат (настроить TLS) на страницу аутентификации пользователей? Золотое правило безопасности гласит, что любая аутентификационная информация должна передаваться по защищенному каналу (а не по голому HTTP).
4. Поддерживается ли аутентификация пользователей по сертификатам (smart cards)?
Но если сравнить автопилот с новичком, который только получил / купил права, но который уже имеет право перевозить людей, результат подобного сравнения скорее всего изменится диаметрально противоположно.
На сколько я понимаю, авторизация происходит один раз, при установки сессии при этом если у вас будут 2 пакета или 10 пользователь разницы не заметит.
Конечно можно предположить что плохо написанный софт будет строить и рвать сессию на каждом SQL-операторе, но и в этом случае изменение количества пакетов используемых для авторизации вряд ли существенно исправить ситуацию с быстродействием.
С другой стороны, помогая «криворуким» программистам вы закладываете в систему проблемы безопасности которые отразятся на всех пользователях.
На практике, проводя аудит безопасности систем, когда открываешь табличку с паролями пользователей и видишь что у половины из них одинаковые коды паролей (хэши) испытываешь смешанные чувства… причем, для самого распространённого пароля — «1» можно даже визуально запомнить хэш.
Хочу отметить, что взлом через радужные таблицы это все таки не brute force.
Радужные таблицы mixaplhanumeric1-12 дадут злоумышленикам очень хорошие результаты по взлому любых систем построенных по аналогичной схеме вообще. Причем атака будет проводиться практически в режиме реального времени и для этого могут использоваться облачные сервисы, фактически похачить можно с мобильника.
Функционал упомянутый в статье есть также в Bot-Treck intellegence от Group-IB, но там возможности больше, они также ищут фишинг по использованию фирменных логотипов и др.
Расскажите пожалуйста в чем преимущества описанного выше решения от Cisco от аналогичных решений ваших конкурентов и кого вы рассматриваете в качестве основных конкурентов.
Растениям нужен свет для них это как еда для нас. На «экономичных» лампах дневного света вырастит тоже экономично, а вернее ничего. Кто не верит посмотрите про промышленные теплицы и какой свет там используется многое станет ясным.
Робо-ферма за 230к$… в Российской действительности, когда сельским хозяйством занимаются люди с оплатой в районе МРОТ на эти деньги несколько десятилетий будем работтать целый колхоз, труд которого сможет прокормить средний Российский город.
На текущий момент, это все интересно только с академической точки зрения, до тех пор пока не найдется дешевых источников освещения и отопления. Подобные фермы будут иметь смысл только в районах где завоз свежей продукции дорог или недоступен, либо когда за свежую зелень люди готовы переплачивать.
Вы теперь знаете куда копать и если будете на выходе вашего шифратора получать устойчивый белый шум, качество которого будет одинаковым вне зависимости от открытого текста и ключевой информации напишите об этом.
Получая закрытый ключ из пароля, а затем открытый ключ из закрытого мы имеем своеобразный аналог псевдо-хэш функции, вида F(пароль)=открытый ключ,
А следовательно на нее будут распространятся атаки справедливые атакам на системы аутентификации использующие чистый хэш.
Пример 1. Хакер Али, сделал себе пароль «qwerty», получил хэш «0xAABB», дальше он крадет таблицу с открытыми ключами пользователей и ищет строки «0xAABB». Дальше думаю понятно
Пример 2. Хакер Зина, украла таблицу с открытыми ключами. У нее есть pre-computed таблицы (например, rainbow table) вида пароль-открытый ключ, где вместо хэш функции используется функция получения открытого ключа по хэшу. Дальше классическая атака через pre-computed таблицы.
Пример 3. Хакер Джэк является MiTM. При авторизации он подменяет scramble идущий от сервера на свой. У Джека есть pre-computed таблица вида свой свой исходный пароль — подписанный scrumble. Дальше аналогично (2).
Таким образом фундаментальной проблемой схемы является генерация ключей на базе «чистых паролей пользователей». Для ее устранения подобных проблем в схему нужно добавлять случайность — соль для каждого пароля.
Алгоритмы есть в свободном доступе, они сертифицированы, по ним работает, например вся банковская система России, доверие к ним есть.
Если вы упомянули банки и их запросы, то для них более спокойно было бы если вы использовали какой-либо сертифицированный / стандартизованный / рекомендованный алгоритм.
Глубокого вдаваться в теорию не буду, но основной смысл шифрования это преобразование «разумного» текста в белый шум или набор случайных чисел.
Самый простой тест — возьмите текст, зашифруйте вашим способом, а потом попробуйте скормить архиватору — если текст жмется значит качество результирующего материала плохое. Тут конечно могут быть нюансы с кодировками и т. д. Поэтому проверять лучше на двоичных данных.
Второй тест. Возьмите тест состоящий из одинаковых символов и зашифруйте. Затем возьмите исходный текст. поменяйте в нем один символ и снова зашифруте. Сравните результаты. Если тексты отличают минимально, значит с шифрованием проблемы.
Если все хорошо, можно исследовать дальше свой шифр с помощью тестов NIST для генераторов случайных чисел
Если закрыть этот «баг» то завершение сеансов неквалифицированных пользователей, которые не закрывают RDP-сессии превратиться в сущий ад. Кто не в теме, просто дропать сеансы не всегда можно, там может потребоватьcя еще сохранить мегаважный Excel.
С точки зрения безопасности, доводы не убедительный. В случае компрометации админа или SYSTEM злоумышленики смогут сделать все тоже а даже больше другими инструментами.
Microsoft, пожалуйста, не латай этот «баг» :)
Чтобы избежать конфликта интересов должна быть независимая организация устанавливающая требования и проверяющая удостоверяющие центры, возможно даже при ООН или IEEE или аналогичной организации, а производители браузеров должны будут ей подчинятся.
И именно ее результаты ее проверок должны иметь вес. Не исключаю что Symantec сильно накосячил, но подобный подход создает не хороший прецедент. Когда одна компания с высокой долей рынка начинает оказывать давление на другую.