Pull to refresh
14.2
Karma
0
Rating
Денис Зыков @shai_hulud

Пользователь

  • Followers 6
  • Following

Photon Plugin: защищаем игровой процесс от читеров

Образно говоря, с его помощью можно получить своего надежного клиента в каждой игровой комнате, которого точно не взломают. 

Это получается у вас "обсервер" в каждой комнате который крутит "кастомные" проверки? Т.е. читерить можно, но скромно?

Или вы сделали корректную синхронизацию действий на клиенте и на сервере? Или у вас авторитарный сервер?

Эксперты рассказали, как в 2019 году нашли уязвимость генерации паролей в Kaspersky Password Manager

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

gRPC vs REST, что выбрать для нового сервера?

HATEOAS, который является обязательным для REST

А без него REST уже не работает?

OWASP, уязвимости и taint анализ в PVS-Studio C#. Смешать, но не взбалтывать

А вам не приходила идея использовать Profiling API и на живом процессе собрать реальные данные попадающие в функции/методы, и смешав с data-flow анализом узнать куда могут попадать «зараженные данные». Да и вообще с реальными данными можно получить более качественный анализ и подсказки и утереть нос реактивным могзам *wink*.

Хроники SSO: банк, токены и немного магии

Делаем безопасную куку (HttpOnly, SameSite, Secure) и кладем в нее UUID. Потом от этого UUID делаем хеш, например, CRC32, — и кладем его уже в тело JWT. И все.


Если из приложения/браузера украли токен, то и куку унесут. Добавили геморроя разработчикам, точки отказа и никакой дополнительной безопасности.

Понимаю бахнули бы еще подпись внутренней крипто-железкой устройства.

Pure DI для .NET

Под «мощью» DI я имел ввиду количество фич. Под сложностью, в этом конкретном случае, имелась ввиду сложность конструирования. Композиция, дженерики, иньекции не только в конструктор итд.

Программирование это не только поиск и применение «клевых» решений, попытки попасть в практичность продукта, но и работа со сложностью в общем ее смысле. Если за ней не следить, то потом никто не сможет понять проект (и назовет его легаси, который невозможно поддерживать). Работать стоит надо не над «мощью» инструментов, а над уменьшения сложности кода. Это экономит на разработку «мощных» инструментов.

Идеальный код — тот который не написан.

Pure DI для .NET

*Режим пассивной агрессии*
Может стоит вместо увеличения мощи DI, стоит уменьшать сложность внедняемых сервисов?

Многопоточность на низком уровне

Крайне скучный метод:
public void SpinOnce()
{
	if (NextSpinWillYield)
	{
		CdsSyncEtwBCLProvider.Log.SpinWait_NextSpinWillYield();
		int num = (m_count >= 10) ? (m_count - 10) : m_count;
		if (num % 20 == 19)
		{
			Thread.Sleep(1);
		}
		else if (num % 5 == 4)
		{
			Thread.Sleep(0);
		}
		else
		{
			Thread.Yield();
		}
	}
	else
	{
		Thread.SpinWait(4 << m_count);
	}
	m_count = ((m_count == 2147483647) ? 10 : (m_count + 1));
}

Почему большинство программистов оказываются посредственными техлидами

Job Saving Driven Development впролне себе рабочая методология и для менеджеров тоже.

Как мы просто сократили объем входящего в дата-центр трафика на 70%

Занимает больше места :)
Вся прелесть BSON в возможности «пропускать» информацию блоками при сканировании, по этому в начале каждого блока есть префикс с его длинной в байтах. Плюс все списки хранятся в крайне неоптимальном виде document где индекс как ключ избыточен в большинстве случаев.

BSON — формат хранения, а не передачи.

Как мы просто сократили объем входящего в дата-центр трафика на 70%

Даже в бинарном протоколе данные могут повторяться много раз подряд. К примеру цепочка событий над одной сущностью. Будет меняться пара полей из десятка, остальные повторяться.

Base64, Base32 и Base16 кодировки в .NET

Ну если тестить на кейсе где output летит в трубу, то стоит тестить по честному:

Код (тестилось на версии 3.1.1)
Результат:
|                               Method |      Mean | Ratio |
|------------------------------------- |----------:|------:|
| System_Memory_Base64ToString_NoAlloc |  3.480 ms |  1.00 |
|   BaseN_BaseNDecoder_Convert_NoAlloc | 18.628 ms |  5.36 |


Результаты сравнения с остальными альтернативами. Теперь немного быстрее встроенного Convert.ToBase64String() и много быстрее альтернатив.

Base64, Base32 и Base16 кодировки в .NET

Залил, версия 3.1.0.
Я не смог получить 3мс на кодировании 20мб данных через Base64.EncodeToUtf8. И даже если такое получится, то советую проверить output на то что там действительно правильно закодировалось.

Base64, Base32 и Base16 кодировки в .NET

Не вижу никаких проблем вызывать оптимизированный алгоритм при выполнении определённых условий

Полностью согласен. Даже более, я сам использую System.Buffers.Text.Base64 везде, где его можно применить.
Но сравнивать производительность, и говорить «почему ваш общий алгоритм медленнее специализированного» не очень корректно.
И часто ли случается ситуация, когда в качестве алфавита используется что-то отличное от RFC4648?

Да, есть богомерзкий Base64 URL который всё чаще торчит из разных Web API.
снижать производительность алгоритма на полтора порядка

Сейчас в два с половиной раза (табличка вверху). Полтора порядка это 15 раз.

Base64, Base32 и Base16 кодировки в .NET

Ссылка на код неправильная.
Так можно сравнивать что-угодно с чем угодно.

а) не проверять корректность теста, что на выходе правильные данные
б) сравнивать теплое с мягким

Base64, Base32 и Base16 кодировки в .NET

Добавил наследование ICryptoTransform пару расширений:
stream.BaseNEncode() // в полученный стрим можно писать
stream.BaseNDecode() // из полученного стрима можно читать


Тест с примером.

Base64, Base32 и Base16 кодировки в .NET

Учел критику/пожелания и добавил немного оптимизаций. Бенчмарк в репозитории.

|                                 Method |      Mean | Allocated |
|--------------------------------------- |----------:|----------:|
|          System_Convert_ToBase64String |  48.80 ms |  53.33 MB |
|           System_Memory_Base64ToString |  15.29 ms |  26.67 MB |
|             BaseN_BaseNDecoder_Convert |  49.13 ms |  26.67 MB |
|           BaseN_Base64Convert_ToString |  59.41 ms |  53.33 MB |
|           BaseN_Base32Convert_ToString |  70.00 ms |     64 MB |
| Wiry_Base32Encoding_Standard_GetString | 100.28 ms |    128 MB |
|       SimpleBase_Base32_Rfc4648_Encode | 102.78 ms |     64 MB |
|                  Albireo_Base32_Encode | 152.63 ms |    128 MB |


Сравнивать с System.Buffers.Text.Base64 некорректно т.к. любой general алгоритм будет проигрывать специализированному. У меня принимается словарь на вход, даже пользовательский, а в System.Buffers.Text.Base64 словарь зашит в алгоритм. Плюс там ввернуто много SSE и AVX, которые будет очень сложно навернуть на общий алгоритм.

Base64, Base32 и Base16 кодировки в .NET

В readme указано, что это желаемое (или нежелаемое для некоторых) поведение. Средства валидации присуствуют
GetCharCount(buffer) != GetMaxCharCount(buffer)
для тех кто хочет с этим что-то делать.

Base64, Base32 и Base16 кодировки в .NET

Типа такого?

public static Stream BaseNEncode(this Stream stream, BaseNAlphabet baseNAlphabet)
{
  return new CryptoStream(stream, new BaseNEncoder(baseNAlphabet), CryptoStreamMode.Write);
}

var output = new MemoryStream();
var writeStream = output
  .BaseNEncode(BaseNAlphabet.Base64Alphabet)
  .GZip();

writeStream.Write(...);


Естественно расширение GZip() я не могу поместить в свою библиотеку т.к. это вне зоны ее ответственности.

Base64, Base32 и Base16 кодировки в .NET

Если Base64, то самый простой способ это класс ToBase64Transform и CryptoStream.
using System.Security.Cryptography;

var base64Transform = new ToBase64Transform();
using var output = new MemoryStream();
using var base64Encoder = new CryptoStream(output, base64Transform, CryptoStreamMode.Write);
using var gZipCompressor = new GZipStream(base64Encoder, CompressionMode.Compress);

gZipCompressor.Write(new byte[] { 255}, 0, 1);


Если другие, то для стримов удобнее SimpleBase и класс StreamHelper.

Для чтения из сокетов и System.IO.Pipelines уже удобнее можно использовать мою либу т.к. там есть подходящий BaseNEncoder.Convert() принимающие Span{byte}.

Хотя если реализовать ICryptoTransform то можно сесть на паравоз CryptoStream и получить поддержку стримов. Я скорее всего скоро это сделаю у себя в либе в ближайшее время.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity