Не факт.
Владеем девайсом на андроиде — считаем его лучшим, однако 4.1 это просто небольшая эволюция.
След. девайс будет на wp8, но презентация сурфейса неинтересна, а вп8 ничего нового не говорит.
Макбук лично нам на фиг нужен, но ретина это очень интересно, хотя и странно реализована.
По поводу «махинаций» — зря Вы в мифы записали на базе такой простой аргументации.
Премирование должно быть осмысленным и стимулирующим.
Наибольший стимул это или получение денег или улучшение взаимоотношений.
Наибольший смысл в премиях это когда они выдаются тому, чью работа известна.
И то и другое подразумевает близкое сотрудничество, таким образом как раз естественным будет замыкание премий внутри узких ячеек «Маша -> Петя -> Вася -> Маша», где люди друг друга знают (есть смысл улучшать взаимоотношения и надежда получить деньги) и знают качество работы друг друга (не премировать же неизвестного дворника из соседнего корпуса), а Вы их на ковер и увольнять за махинации.
В остальном — по сути это какой-то «нирыбанимясо» фриланс. Улучшить горизонтальные связи тем, что в соседнем отделе тебе помогут за премиальные деньги? С одной стороны это тупо переквалификация любого работника в менеджера («я лучше спихну свою проблему в соседний отдел за 100р, а сам в это время левака на 200р сделаю») или местный консультационный центр — в результате соседний отдел будет всем помогать (10 вовремя спасенных в бухгалтерии кактусов это 10 премий, а оклад он один) но ничего больше в плане должностных обязанностей.
В общем — кесарю кесарево, цезарю цезарево, а ссср-ную систему лучше оставить в ссср.
По факту — экономия на спичках, жертва бОльшего во имя меньшего.
Даже если забыть о том, что у современного смарта гигагерц на борту…
То время инициализации скрипта даже будучи сокращенным на порядок (а отказ от поддержки старого кода время _инициализации_ сократит не больше чем раза в 2 почти наверняка), на время общей загрузки и рендеринга повлияет жалкими долями процента.
0.01 секунды или 0.011 секунды большая разница?
ну понеслась… сейчас докатимся до того, что фотки надо делать только на средний формат:-)
по факту, если снимать без зума, то качество видео со смарта (сгс2) при норм освещении не хуже чем с фуллхд хорошего панасоника (покупали незадолго ло сгс2), в плюсах удобный формат (а не кривой пал/нтсц который еще не каждый редактор возьмет), объем файлов (мп4 сразу это вам не тут!). Отсутствие юзабилити и не в последнюю очередб неудобность хвата портит 80% всего.
Все что надо сделать (реально сделать) это что бы смартфоны снимали бы горизонтальное видео при вертикальном положении.
Современные супертонкие суперлегкие смарты и так тяжело держать, а уж в горизонтальном положении это вообще ппц, особенно при съемке видео, пытаясь одновременно на экран не нажать случайно и не выронить из руки и камеру пальцами не закрыть.
Юзабилити как видео/фото камеры у смартов очень низки, вертикальный хват это хоть немного исправляет, так что верт.видео это не по приколу, это по сути вынужденная мера.
Так не смотрите.
Вот реально проблема высосанная из пальца, йотуб они понимаешь ненавидят, объясняют «почему».
Объяснили бы лучше «зачем» Вы его смотрите в таком разе, когда есть текстовые мануалы, вот это реально непонятно:)
А на этом «одном ноуте» Вы не выбирали другой регион на яндекс.поиске?
Мы как-то москву выбрали (не помним как, то ли по ссылке перешли. то ли результаты хотели по другому поискать), он запомнил регион и стал по москве по умолчанию карту показывать, раздражало жутко. yandex.ru/yandsearch?text=habrahabr&lr=2 — справа вверху смотрите «Регион:… » есть?
Разница в том, что вы сравниваете грамотный подход к хранению паролей с неграмотным хешированием, а надо сравнивать оба подхода с грамотной реализацией.
Еще раз повторим: сравниваем не мы, а автор топика (объясняли тут habrahabr.ru/post/146591/#comment_4936324 ), а мы лишь критикуем это его сравнение, не более того.
Ну а на счёт сферического среднестатестического сайта в вакууме… топик-то про озон.
Топик про хранение открытых паролей, озон лишь пример вообще-то. Однако — с удовольствием послушаем про реализацию системы хранения на озоне и ее преимущества/недостатки, если Вы хотите конкретизировать.
Вот не надо сравнивать ИТшников и простых пользователей.
Так мы не сравниваем, мы практически цитируем некоторых юзеров «господи, этот сайт хранит мой пароль в открытом виде, ужас, ведь я этот пароль еще много где использую» (с) К тем кто сам так не делает, а просто заботится о своем ближнем — вопросов нет.
Допустим есть риск человеческого фактора в большой компании: кто-то из инсайдеров может слить часть БД.
Давайте еще раз уточним — мы не отрицаем, что пароли лучше хэшировать (ясен пень что лучше), мы не более чем утверждаем, что грамотный подход к хранению паролей в открытом виде превосходит ту степень безопасности, что есть у среднестатического сайта в интернете, особенно если сайтовладелец, как и автор топик, а считает что хэширование это ключ ко всем проблемам, а "алгоритм шифрования старый, соль не используется и т.д. Это все мелочи. "(с) и хотя бы в меру этого имеет право на существование (особенно если сверху уже спущена задача хранить пароли в открытом виде и это не обсуждается).
Что касается инсайда… Тут уж из серии — а что если из банка сбежит кассир с деньгами. Да, может сбежать. Такие дела, there are no safety in this crazy world.
Глобально абсолютной защиты от инсайда нет, чем бы Вы там пароли не солили — один черт пострадаете (начиная с банального сниффера вкряченного на сервер).
Локально же этот вопрос частично решается хранением паролей в шифрованном виде, с тем что бы ключ был на сервере куда есть доступ у одной группы сотрудников, а зашифрованные пароли на другом сервере — куда доступа у этой группы сотрудников нет. Мы такое не реализовывали, т.к. это было уже overkill-ом, но в принципе — вполне рабочий вариант.
Санкт-Петербург, юзаем рамблер теперь, до этого яндекс.
Яндекс за последние полгода сильно разочаровал.
Сначала 2 раза подвел на кольцевой, нарисовал повороты там, где их не было, в результате +30 минут каждый раз и +7км.
Потом подвел в другом месте на кольцевой, «не знал» о наличии заезда в город там, где он уже до фига времени есть, опять же +40 выкинутых минут и километров 30.
И наконец добило то, что по нужному району огромное кол-во давно построенных домов с адресами показывается черти где (т.е. для тех домов, о существовании которых яндекс не знает) даже если на карте они отрисованы, а неслабое количество даже не отрисовано.
В общем актуальность и точность яндекса по СПб приводит к невозможности на него положиться.
Рамблер, наверное, тоже с недостатками, но мы их пока не нашли:)
Ну правильно, давайт сравним гипотетическую ситуацию с хорошей безопасностью с не менее гипотетической ситуацией с плохой безопасностью, и назовем это хорошим сравнением.
Так ведь именно это и делает автор топика! Которому мы возражаем… за что и огребаем.
Создатель топика как раз и сравнивает гипотетическую ситуацию хранения пароля ozon-ом в открытом виде заявляя что
Действующий пароль выслан в открытом виде
При этом называет мелочью следующие вещи
алгоритм шифрования старый, соль не используется и т.д. Это все мелочи.
А мы лишь попытались донести ту простую мысль, что хранение паролей в открытом виде само по себе не зло, и что с таким отношением автора топика к «мелочам», он создаст систему менее надежную, чем можно легко создать даже при условии открытых паролей.
Но в их подходе правда больше здравого смысла чем может показаться.
Изоляция хранилища с паролями дает бОльшую безопасность, чем их соление и отсутствие изоляции.
Что бы взломать извне изолированное хранилище с паролями, Вам надо сначала взломать основной сервер (допустим это относительно легкая задача), потом получить доступ к серверу баз данных (на котором только база данных крутиться и порты открыты только для ссх и мускула) — что уже затруднительно, потом вычислив местонахождение третьего сервера — умудриться и его ломануть (при том что там вообще только по ссх ключам вход, с ограничением по IP и все другие внешние коннекты запрещены). При чем основной сервер регулярно проверяется на внесение «левых» изменений (что бы избежать троянцев), а на сервер с паролями обычные девелоперы доступа не имеют. При чем в дополнение — авторизация происходит сугубо по https, т.е. и снифферов на любом этапе можно не бояться.
А теперь сравните это с сайтом, где все крутится в одной БД (к которой имеет доступ обычный девелопер в страшном количестве) на рабочем сервере (который взломали и ага), мониторинг на левые изменения не проводится достаточно надежно (хотя бы потому что проводится с этого же сервера, если вообще проводится), а база хэширована мд5 дай бог с солью (поскольку в статье критикуется открытое хранение, а большинство сайтов пользуется мд5 это приемлимое допущение). А логин по http добивает эту систему полностью и бесповоротно.
Если действительно подумать на эту тему, без шор на глазах и предрассудков по поводу «открытых паролей», то становится понятно, что использование открытых паролей при адекватной защите дает защиту оных намного более высокую, чем среднестатический сайт гордящийся хэшированием.
И самое дикое в этой ситуации, что многие критики системы «открытых» паролей критикуют их аргументом вида «господи, они увидят мой пароль и применят его на другом сайте». Сильно же эти критики думают о безопасности, если один и тот же пароль используют на разных сайтах, хотя уже даже на хабре с десяток статей про легкий выбор разных паролей с хорошей степенью запоминаемости.
Опять же, надо помнить, что при наличии прямого доступа к серверу, вытворять там можно настолько страшные вещи, что приводить в качестве аргумента «при прямом доступе будет плохо» или типа того, это катастрофический эпик фейл, т.к. подобный аргумент убивает абсолютно любую идею о защите.
Не хотелось бы выступать в роли К.О., но это просто грех при использовании простых языков/фреймворков — не озаботится хотя бы полным прочтением документации, хотя бы один раз. Просто что бы знать какие функции в принципе там есть.
Иногда в коде встречаются «новоизобретенные» велосипеды, созданные исключительно по причине не знания о наличии такой функции. И это расстраивает. Можно не знать как используется каждая функция (доки в конце концов под рукой), но хотя бы примерно иметь представление об имеющемся наборе функций — надо.
Юзабилити можно и проще улучшить, достаточно присылать сразу новый пароль (не отменяя до его активации старый), и давать в письме ссылку на страницу с формой, где будет достаточно нажать 1 кнопку, что бы сменить пароль и залогиниться под новым.
Проблема на самом деле глубже. На каждом 2-ом сайте пароли хранятся в md5 и/или тихого трояна (отслеживающего пароли из post-ов) месяцами не заметят. Дело не в хэшировании или его отсутствии как таковом, дело в комплексном подходе к безопасности. Плохая реализация сайта при наличии даже md5 с солью — даст худший эффект чем хорошая реализация и хранение паролей в открытом виде.
А как вы судите о надежности? Chronopay, Linkedin и другие, также были уверены в достаточной надежности системы, ровно до момента, пока их не взломали.
Не вполне понятно, почему Вы считаете что линкедин и прочие были уверены в достаточной надежности. В надежности вообще нельзя быть уверенным, это лишь игра вероятностями, взломать можно всё.
В именно нашем случае надо не забывать о том, что возможности по обезопашиванию ограничивались постановкой задачи — необходимостью хранить где-то пароли в открытом виде. Мы ни в коем случае не заявляем о 100% надежности нашего метода, это просто лучшее решение из тех что мы смогли найти. И если Вы можете привести схему как этот вариант обходится и/или предложить лучший вариант — будем очень благодарны, т.к. вопрос безопасности в этом случае нас очень волнует.
Владеем девайсом на андроиде — считаем его лучшим, однако 4.1 это просто небольшая эволюция.
След. девайс будет на wp8, но презентация сурфейса неинтересна, а вп8 ничего нового не говорит.
Макбук лично нам на фиг нужен, но ретина это очень интересно, хотя и странно реализована.
Премирование должно быть осмысленным и стимулирующим.
Наибольший стимул это или получение денег или улучшение взаимоотношений.
Наибольший смысл в премиях это когда они выдаются тому, чью работа известна.
И то и другое подразумевает близкое сотрудничество, таким образом как раз естественным будет замыкание премий внутри узких ячеек «Маша -> Петя -> Вася -> Маша», где люди друг друга знают (есть смысл улучшать взаимоотношения и надежда получить деньги) и знают качество работы друг друга (не премировать же неизвестного дворника из соседнего корпуса), а Вы их на ковер и увольнять за махинации.
В остальном — по сути это какой-то «нирыбанимясо» фриланс. Улучшить горизонтальные связи тем, что в соседнем отделе тебе помогут за премиальные деньги? С одной стороны это тупо переквалификация любого работника в менеджера («я лучше спихну свою проблему в соседний отдел за 100р, а сам в это время левака на 200р сделаю») или местный консультационный центр — в результате соседний отдел будет всем помогать (10 вовремя спасенных в бухгалтерии кактусов это 10 премий, а оклад он один) но ничего больше в плане должностных обязанностей.
В общем — кесарю кесарево, цезарю цезарево, а ссср-ную систему лучше оставить в ссср.
Даже если забыть о том, что у современного смарта гигагерц на борту…
То время инициализации скрипта даже будучи сокращенным на порядок (а отказ от поддержки старого кода время _инициализации_ сократит не больше чем раза в 2 почти наверняка), на время общей загрузки и рендеринга повлияет жалкими долями процента.
0.01 секунды или 0.011 секунды большая разница?
и есть еще момент, иногда не хватает широкого угла… ну или высокого учитывая контекст)))
по факту, если снимать без зума, то качество видео со смарта (сгс2) при норм освещении не хуже чем с фуллхд хорошего панасоника (покупали незадолго ло сгс2), в плюсах удобный формат (а не кривой пал/нтсц который еще не каждый редактор возьмет), объем файлов (мп4 сразу это вам не тут!). Отсутствие юзабилити и не в последнюю очередб неудобность хвата портит 80% всего.
Современные супертонкие суперлегкие смарты и так тяжело держать, а уж в горизонтальном положении это вообще ппц, особенно при съемке видео, пытаясь одновременно на экран не нажать случайно и не выронить из руки и камеру пальцами не закрыть.
Юзабилити как видео/фото камеры у смартов очень низки, вертикальный хват это хоть немного исправляет, так что верт.видео это не по приколу, это по сути вынужденная мера.
Вот реально проблема высосанная из пальца, йотуб они понимаешь ненавидят, объясняют «почему».
Объяснили бы лучше «зачем» Вы его смотрите в таком разе, когда есть текстовые мануалы, вот это реально непонятно:)
Мы как-то москву выбрали (не помним как, то ли по ссылке перешли. то ли результаты хотели по другому поискать), он запомнил регион и стал по москве по умолчанию карту показывать, раздражало жутко. yandex.ru/yandsearch?text=habrahabr&lr=2 — справа вверху смотрите «Регион:… » есть?
Топик про хранение открытых паролей, озон лишь пример вообще-то. Однако — с удовольствием послушаем про реализацию системы хранения на озоне и ее преимущества/недостатки, если Вы хотите конкретизировать.
Давайте еще раз уточним — мы не отрицаем, что пароли лучше хэшировать (ясен пень что лучше), мы не более чем утверждаем, что грамотный подход к хранению паролей в открытом виде превосходит ту степень безопасности, что есть у среднестатического сайта в интернете, особенно если сайтовладелец, как и автор топик, а считает что хэширование это ключ ко всем проблемам, а "алгоритм шифрования старый, соль не используется и т.д. Это все мелочи. "(с) и хотя бы в меру этого имеет право на существование (особенно если сверху уже спущена задача хранить пароли в открытом виде и это не обсуждается).
Что касается инсайда… Тут уж из серии — а что если из банка сбежит кассир с деньгами. Да, может сбежать. Такие дела, there are no safety in this crazy world.
Глобально абсолютной защиты от инсайда нет, чем бы Вы там пароли не солили — один черт пострадаете (начиная с банального сниффера вкряченного на сервер).
Локально же этот вопрос частично решается хранением паролей в шифрованном виде, с тем что бы ключ был на сервере куда есть доступ у одной группы сотрудников, а зашифрованные пароли на другом сервере — куда доступа у этой группы сотрудников нет. Мы такое не реализовывали, т.к. это было уже overkill-ом, но в принципе — вполне рабочий вариант.
Яндекс за последние полгода сильно разочаровал.
Сначала 2 раза подвел на кольцевой, нарисовал повороты там, где их не было, в результате +30 минут каждый раз и +7км.
Потом подвел в другом месте на кольцевой, «не знал» о наличии заезда в город там, где он уже до фига времени есть, опять же +40 выкинутых минут и километров 30.
И наконец добило то, что по нужному району огромное кол-во давно построенных домов с адресами показывается черти где (т.е. для тех домов, о существовании которых яндекс не знает) даже если на карте они отрисованы, а неслабое количество даже не отрисовано.
В общем актуальность и точность яндекса по СПб приводит к невозможности на него положиться.
Рамблер, наверное, тоже с недостатками, но мы их пока не нашли:)
Создатель топика как раз и сравнивает гипотетическую ситуацию хранения пароля ozon-ом в открытом виде заявляя что
При этом называет мелочью следующие вещи
А мы лишь попытались донести ту простую мысль, что хранение паролей в открытом виде само по себе не зло, и что с таким отношением автора топика к «мелочам», он создаст систему менее надежную, чем можно легко создать даже при условии открытых паролей.
Но в их подходе правда больше здравого смысла чем может показаться.
Изоляция хранилища с паролями дает бОльшую безопасность, чем их соление и отсутствие изоляции.
Что бы взломать извне изолированное хранилище с паролями, Вам надо сначала взломать основной сервер (допустим это относительно легкая задача), потом получить доступ к серверу баз данных (на котором только база данных крутиться и порты открыты только для ссх и мускула) — что уже затруднительно, потом вычислив местонахождение третьего сервера — умудриться и его ломануть (при том что там вообще только по ссх ключам вход, с ограничением по IP и все другие внешние коннекты запрещены). При чем основной сервер регулярно проверяется на внесение «левых» изменений (что бы избежать троянцев), а на сервер с паролями обычные девелоперы доступа не имеют. При чем в дополнение — авторизация происходит сугубо по https, т.е. и снифферов на любом этапе можно не бояться.
А теперь сравните это с сайтом, где все крутится в одной БД (к которой имеет доступ обычный девелопер в страшном количестве) на рабочем сервере (который взломали и ага), мониторинг на левые изменения не проводится достаточно надежно (хотя бы потому что проводится с этого же сервера, если вообще проводится), а база хэширована мд5 дай бог с солью (поскольку в статье критикуется открытое хранение, а большинство сайтов пользуется мд5 это приемлимое допущение). А логин по http добивает эту систему полностью и бесповоротно.
Если действительно подумать на эту тему, без шор на глазах и предрассудков по поводу «открытых паролей», то становится понятно, что использование открытых паролей при адекватной защите дает защиту оных намного более высокую, чем среднестатический сайт гордящийся хэшированием.
И самое дикое в этой ситуации, что многие критики системы «открытых» паролей критикуют их аргументом вида «господи, они увидят мой пароль и применят его на другом сайте». Сильно же эти критики думают о безопасности, если один и тот же пароль используют на разных сайтах, хотя уже даже на хабре с десяток статей про легкий выбор разных паролей с хорошей степенью запоминаемости.
Опять же, надо помнить, что при наличии прямого доступа к серверу, вытворять там можно настолько страшные вещи, что приводить в качестве аргумента «при прямом доступе будет плохо» или типа того, это катастрофический эпик фейл, т.к. подобный аргумент убивает абсолютно любую идею о защите.
Иногда в коде встречаются «новоизобретенные» велосипеды, созданные исключительно по причине не знания о наличии такой функции. И это расстраивает. Можно не знать как используется каждая функция (доки в конце концов под рукой), но хотя бы примерно иметь представление об имеющемся наборе функций — надо.
Проблема на самом деле глубже. На каждом 2-ом сайте пароли хранятся в md5 и/или тихого трояна (отслеживающего пароли из post-ов) месяцами не заметят. Дело не в хэшировании или его отсутствии как таковом, дело в комплексном подходе к безопасности. Плохая реализация сайта при наличии даже md5 с солью — даст худший эффект чем хорошая реализация и хранение паролей в открытом виде.
В именно нашем случае надо не забывать о том, что возможности по обезопашиванию ограничивались постановкой задачи — необходимостью хранить где-то пароли в открытом виде. Мы ни в коем случае не заявляем о 100% надежности нашего метода, это просто лучшее решение из тех что мы смогли найти. И если Вы можете привести схему как этот вариант обходится и/или предложить лучший вариант — будем очень благодарны, т.к. вопрос безопасности в этом случае нас очень волнует.