Спасибо за ностальгию. Прочел — как будто жизнь пронеслась перед глазами. Волшебный МК-61 без кнопки "=" и непривычным ПОЛИЗ, самопаянный "Синклер" с гордым пояснением "Пентагон", то бишь с НГМД. Затем болгарский "Правец" и толстые тетради с самописным кодом и отладкой там же. Далее "Искры", женщина-заведующая машзалом, которой бежать за ребенком в садик, уговоры и бдения по ночам, ключи от машзала, которые забыл сдать вахтеру, нагоняй и великодушие от заведующей. Наконец, цветные немецкие "Амстрады" и первые 286-е. Романтика и творчество, плавно переросшие в ремесло :)
Объясните, пожалуйста? Я имею в виду любой алгоритм, используемый на стороне сервера для валидации введенного пароля. Он не должен быть вычислительно сложным, чтобы уменьшить плечо DOS-атаки. Как я понял, вы предполагаете, что злоумышленнику известен алгоритм, поэтому то, что считается в уме, легко щелкается любым умным утюгом. Моя идея в том, что алгоритм неизвестен, поэтому перебор алгоритмов сопоставим с брутфорсом пароля.
Если бы не авторитет первоисточника, я бы подумал, что это очередной вброс. Воспринимается примерно как «выбор инструмента в работе не важен, виноват программист». Угу, даже дворники перешли от метлы к механизации, чтобы повысить производительность и качество.
То есть на самом деле, мы больше не можем открыть или закрыть дверь. Мы можем получить новую дверь, которая открыта или закрыта… но мы не можем открыть существующую. И мы не можем заменить дверь в той комнате, куда мы хотим попасть, с закрытой на открытую, потому что для этого понадобится изменить комнату. И так далее.
Напомнило анекдот про пепельницу в «Мерседесе». Функциональный подход, когда это еще не было мейнстримом )
Куда, вернее, откуда он утечет? Приличный для бытового уровня хэш придумать можно. Добавить шифр Цезаря, например. Потребуется знание более одного пароля, чтобы восстановить метод. Разумеется, это применимо не ко всем случаям, но тогда и любой другой plain text применим не всегда.
Есть простой способ "хранить" неограниченное число паролей, не прибегая к бумажным или электронным помощникам. Нужно всего лишь поставить пароль в зависимость от идентификатора сайта (домена) или приложения (названия) и рандомизировать это производной вашего единственного секретного слова. Т.е. password = f(id, secret). Например, взять от идентификатора 5 четных символов с конца и добавить к ним последние (len(id) mod 5) символов вашего секрета. Сложность функции зависит от вашей способности помнить и решать ее в уме, ну и от степени параноидальности. При должной сложности утечка одного пароля не сильно скомпрометирует вашу защиту.
Нет, несмотря на то, что в DateTime на самом деле нет TimeZone, установка DateTimeKind.Utc делает его мировым (как признак, без вычислений). Отличие от DateTimeOffiset в том, что последний может вычисляться с любой зоной, в то время как DateTime может быть только локальным или UTC.
Это логично, время приводится к локальному с учетом таймзоны. Тем не менее, оно по-прежнему указывает на ту же самую точку в мировых координатах, которую вы передаете. Вот пример:
var d = DateTime.Parse("2016-03-19T12:17:33Z");
Console.WriteLine($"Value='{d}', Kind={d.Kind}, UTC='{d.ToUniversalTime()}'");
Локальное время учитывает +5 сервера, но Kind при этом Local, так что UTC по-прежнему то же. Как вы видите, здесь нет каких-либо манипуляций с оригинальным значением, добавлений часов и т.п.
Ладно, может, сериализация в MVC/API работает по-другому?
public ActionResult Index(DateTime time)
{
return Json(new
{
value = time.ToString(),
kind = time.Kind.ToString(),
utc = time.ToUniversalTime().ToString()
}, JsonRequestBehavior.AllowGet);
}
Вы не поняли. Клиент — админ, он сам создает событие, скажем, в 18:00 локального времени места события, т.к. это публичное время (проще говоря, расклеено на афишах). Он оперирует только этим временем вне зависимости от его текущего местоположения.
А через неделю? В моем проекте так и происходит, что привилегированные юзеры колесят по стране и сами создают и корректируют удаленные события — естественно, в локальном времени места события.
Например, в V8 (используется в Chromium), сделана попытка разобрать все скрипты, независимо от их атрибутов, на отдельном выделенном потоке для выполнения скрипта. Таким образом, «блокирующая парсер» природа JavaScript-файлов должна быть минимизирована по умолчанию.
В общем случае UTC — не панацея. К примеру, сотрудник, находящийся в командировке, открывая бэкенд своей компании, должен видеть события в локальном времении компании, а не в локальном своем. «Заседание начинается в 15:00, явка обязательна».
В Хроме сертификат вообще запрятали в Dev Tools: https://superuser.com/questions/1160502/how-to-view-ssl-certificate-details-on-chrome.
Спасибо за ностальгию. Прочел — как будто жизнь пронеслась перед глазами. Волшебный МК-61 без кнопки "=" и непривычным ПОЛИЗ, самопаянный "Синклер" с гордым пояснением "Пентагон", то бишь с НГМД. Затем болгарский "Правец" и толстые тетради с самописным кодом и отладкой там же. Далее "Искры", женщина-заведующая машзалом, которой бежать за ребенком в садик, уговоры и бдения по ночам, ключи от машзала, которые забыл сдать вахтеру, нагоняй и великодушие от заведующей. Наконец, цветные немецкие "Амстрады" и первые 286-е. Романтика и творчество, плавно переросшие в ремесло :)
Неа. Длинная — да
Можете привести практический пример такой ситуации?
Напомнило анекдот про пепельницу в «Мерседесе». Функциональный подход, когда это еще не было мейнстримом )
Куда, вернее, откуда он утечет? Приличный для бытового уровня хэш придумать можно. Добавить шифр Цезаря, например. Потребуется знание более одного пароля, чтобы восстановить метод. Разумеется, это применимо не ко всем случаям, но тогда и любой другой plain text применим не всегда.
Есть простой способ "хранить" неограниченное число паролей, не прибегая к бумажным или электронным помощникам. Нужно всего лишь поставить пароль в зависимость от идентификатора сайта (домена) или приложения (названия) и рандомизировать это производной вашего единственного секретного слова. Т.е. password = f(id, secret). Например, взять от идентификатора 5 четных символов с конца и добавить к ним последние (len(id) mod 5) символов вашего секрета. Сложность функции зависит от вашей способности помнить и решать ее в уме, ну и от степени параноидальности. При должной сложности утечка одного пароля не сильно скомпрометирует вашу защиту.
Это логично, время приводится к локальному с учетом таймзоны. Тем не менее, оно по-прежнему указывает на ту же самую точку в мировых координатах, которую вы передаете. Вот пример:
Вывод:
Value='3/19/2016 5:17:33 PM', Kind=Local, UTC='3/19/2016 12:17:33 PM'
Локальное время учитывает +5 сервера, но Kind при этом Local, так что UTC по-прежнему то же. Как вы видите, здесь нет каких-либо манипуляций с оригинальным значением, добавлений часов и т.п.
Ладно, может, сериализация в MVC/API работает по-другому?
Ответ:
В том-то и дело, что если всегда приводить время к UTC при сериализации, указанной вами неконсистентности не будет.
Вы не поняли. Клиент — админ, он сам создает событие, скажем, в 18:00 локального времени места события, т.к. это публичное время (проще говоря, расклеено на афишах). Он оперирует только этим временем вне зависимости от его текущего местоположения.
Блокировку можно уменьшить за счет устранения препарсинга.
в консоли Хрома — и никаких отвлечений ;)