Ошибаетесь. Открываем даташит на современные аккумуляторы, например samsung 50e (а также samsung 40t): минимальное напряжение - 2.5 В, максимальное - 4.2 В. В телефонах границы могут немного отличаться, но есть общее правило: от 3 до 4.2 В.
Искренне не понимаю как в статье про безопасность можно рекомендовать разрешать вход на сайт с помощью e-mail'а. Это автоматически означает, что ко всем своим дырам аутентификации прибавляются дыры почтового сервиса. Причем вход через сайт может быть защищен SSL, а вот при входе через ссылку в почте эта ссылка по пути к вам может много где осесть и много кто её может воспользоваться (особенно, если она многоразовая).
А еще бывают сервисы, которые любое изменение пароля шлют вам на почту, опять же встает вопрос к безопасности как почтового сервиса, так и канала как между сайтом и вашим почтовым сервисом, так и между почтовым сервисом и вами (ладно, на этом отрезке вы используете SSL).
В общем, я буду использовать вход через почту не раньше, чем распишусь в собственной импотенции как программиста хоть что-то понимающего в безопасности.
Даже если такой пакет пройдет роутеры, наты, файрволы, то юзер все равно не сможет получить на него ответ, поэтому в контексте php-секьюрити данной проблемы не существует. (Поправьте если я не прав.)
«Так ip можно подделать и будет у тебя и сид и ip такой же.»
Сессионный идентификатор — информация секретная, подделать затруднительно (читайте «нельзя»). Можно выкрасть, против этого можно применять проверку IP.
«Так первая соль и так рядом с паролем лежит, какой смысл от второй такой же?»
Первая соль константная, лежит в скрипте, вторая — динамическая, лежит в БД. Первая мало полезна, но дополнительных затрат практически никаких, так что почему бы и нет.
Извините за прямоту, но у вас каша в голове.
По пунктам:
— Форма без хороших проверок ничего не стоит — ерунда, не надо ничего проверять, нужно экранировать вывод в браузер (rtfm htmlspecialchars).
— «Можно защитить свой движок только в том случае, если у тебя нет ни одной формы для загрузки файлов», «Узнайте о содержимом все» — ерунда, не нужно запрещать закачивать файлы и не нужно ничего проверять (размер и длину/ширину картинок, разумеется, нужно), главное запретить выполнение произвольных php-скриптов (и не только php, если у вас более сложный environment) из директорий, куда вы складываете upload, кейворды для гугления: «php_flag engine off», ".htaccess", «DocumentRoot».
— «Он может как-минимум двумя способами открыть настройки и там посмотреть сохраненные пароли, второе через отладчик поменять тип поля с password на text.» — ничего не даст, кроме того, что он сможет залогиниться под вами (если при логине вы ставили галочку «запомнить меня») — от этого вы не защититесь. Пароль он в любом случае не узнает.
— «Тут все так же как и с админкой, нельзя давать возможность попасть в phpmyadmin» — само по себе наличие phpmyadmin в прямом доступе угрозы не несет. Нужно лишь чтобы оно было запаролировано (лучше http-basic-auth, если вы не доверяете встроенным функциям) и, конечно же, не надо давать root-доступ к БД — хотя это опционально.
— Админка 7NVmE10SaJ.php — это называется security through obscurity и само по себе защитой не является. С другой стороны, если у вас уже все нормально защищено, то опять же этот пункт не нужен.
— Пароли. «С недавних времен я начал использовать такую связку для создания пароля md5($secret_key. $password. $salt);» — рекомендую еще усложнить, генерируйте еще и вторую динамическую соль и кладите её в БД рядом с паролем.
— Сессии. «Первое, что нужно помнить, не храните ID сессии в открытом виде, а еще лучше, храните его в БД» — нет причин не хранить ID в открытом виде, а совет хранить сессию в БД в общем виде вреден, полезен только в некоторых случаях, например, когда нужно распараллелить работу скриптов на несколько серверов.
— «Куки нужны для хранение данных браузером, зачастую многие хранят в куках id сессии, чего делать не рекомендую, особенно в открытом виде.» — уверен что именно так хранить ID сессии и нужно, ничего шифровать и проверять не нужно. Разве что могу порекомендовать проверять IP, чтобы данные одной и той же сессии можно было грузить только с одного и того же IP.
— «кроме windows конечно, там само ядро сплошная дыра» — извините, но это бред.
Так писать некорректно. Если пишете время в формате 00:00:00.00, то не надо писать «мс», если пишете в милисекундах — пишите «57781 мс», если в секундах — «57.781 с».
> Теперь многие пользователи чрезвычайно сердятся на страницы, захлёстывающие их потоками запросов на установку cookie. Подсказка: если пользователь отклоняет первую cookie, ему не нужна ни вторая, ни сорок девятая — перенесите это с достоинством.
Imho, бред. Если пользователь настроил браузер так, чтобы он спрашивал подтверждения для каждой куки то он и получает то что хотел. Если ему нужно подтверждение только для первой куки, то настраивать браузер ему нужно как-то подругому.
«Если пользователь отклоняет первую cookie, ему не нужна ни вторая, ни сорок девятая» — ложь… по меньшей мере спорное утверждение.
Вообще автора статьи надо выпороть, чтобы свой сбъективный взгляд на вещи не выдавал за вселенскую мудрость.
Согласен, кнопка рядом лучше.
А если речь идет о том чтобы «за копейку» сделать очень удобное изменение, то уверен что оно будет ненадежно — будет разбалтываться, потом будет искрить. Хорошо сделать можно, но розетка подорожает в разы.
Присмотритесь, у вас кадры телефона лицевой стороной и повернутым на несколько градусов делаются с разным масштабом, отсюда получается эффект то приближения то удаления (как сказали выше про ось вращения). Вам нужно масштабировать не каждый кадр по отдельности на весь экран, а смасштабировать все кадры, выбрать среди них минимальный масштаб и использовать его как константу.
Обычно табличную информацию выводят с разбивкой на страницы, а сортировка должна сортировать данные по всем страницам. Поэтому метод на реальных задачах не применим, разве что вы загрузите всю таблицу в какой-то локальный кэш и в дальнейшем будете работать только с ним, но даже тогда передача всей таблицы из БД может перекрыть выгоду от локальной сортироки.
Ошибаетесь. Открываем даташит на современные аккумуляторы, например samsung 50e (а также samsung 40t): минимальное напряжение - 2.5 В, максимальное - 4.2 В. В телефонах границы могут немного отличаться, но есть общее правило: от 3 до 4.2 В.
А еще бывают сервисы, которые любое изменение пароля шлют вам на почту, опять же встает вопрос к безопасности как почтового сервиса, так и канала как между сайтом и вашим почтовым сервисом, так и между почтовым сервисом и вами (ладно, на этом отрезке вы используете SSL).
В общем, я буду использовать вход через почту не раньше, чем распишусь в собственной импотенции как программиста хоть что-то понимающего в безопасности.
$statement = $db->prepare(«SELECT * FROM lists WHERE id = ?»);
$statement->execute(array($argv[2]));
Заменить на:
$statement = $db->prepare(«SELECT * FROM lists WHERE id = :id»);
$statement->bindValue(':id', $argv[2], PDO::PARAM_INT);
$statement->execute();
?
«Так ip можно подделать и будет у тебя и сид и ip такой же.»
Сессионный идентификатор — информация секретная, подделать затруднительно (читайте «нельзя»). Можно выкрасть, против этого можно применять проверку IP.
Первая соль константная, лежит в скрипте, вторая — динамическая, лежит в БД. Первая мало полезна, но дополнительных затрат практически никаких, так что почему бы и нет.
По пунктам:
— Форма без хороших проверок ничего не стоит — ерунда, не надо ничего проверять, нужно экранировать вывод в браузер (rtfm htmlspecialchars).
— «Можно защитить свой движок только в том случае, если у тебя нет ни одной формы для загрузки файлов», «Узнайте о содержимом все» — ерунда, не нужно запрещать закачивать файлы и не нужно ничего проверять (размер и длину/ширину картинок, разумеется, нужно), главное запретить выполнение произвольных php-скриптов (и не только php, если у вас более сложный environment) из директорий, куда вы складываете upload, кейворды для гугления: «php_flag engine off», ".htaccess", «DocumentRoot».
— «Он может как-минимум двумя способами открыть настройки и там посмотреть сохраненные пароли, второе через отладчик поменять тип поля с password на text.» — ничего не даст, кроме того, что он сможет залогиниться под вами (если при логине вы ставили галочку «запомнить меня») — от этого вы не защититесь. Пароль он в любом случае не узнает.
— «Тут все так же как и с админкой, нельзя давать возможность попасть в phpmyadmin» — само по себе наличие phpmyadmin в прямом доступе угрозы не несет. Нужно лишь чтобы оно было запаролировано (лучше http-basic-auth, если вы не доверяете встроенным функциям) и, конечно же, не надо давать root-доступ к БД — хотя это опционально.
— Админка 7NVmE10SaJ.php — это называется security through obscurity и само по себе защитой не является. С другой стороны, если у вас уже все нормально защищено, то опять же этот пункт не нужен.
— Пароли. «С недавних времен я начал использовать такую связку для создания пароля md5($secret_key. $password. $salt);» — рекомендую еще усложнить, генерируйте еще и вторую динамическую соль и кладите её в БД рядом с паролем.
— Сессии. «Первое, что нужно помнить, не храните ID сессии в открытом виде, а еще лучше, храните его в БД» — нет причин не хранить ID в открытом виде, а совет хранить сессию в БД в общем виде вреден, полезен только в некоторых случаях, например, когда нужно распараллелить работу скриптов на несколько серверов.
— «Куки нужны для хранение данных браузером, зачастую многие хранят в куках id сессии, чего делать не рекомендую, особенно в открытом виде.» — уверен что именно так хранить ID сессии и нужно, ничего шифровать и проверять не нужно. Разве что могу порекомендовать проверять IP, чтобы данные одной и той же сессии можно было грузить только с одного и того же IP.
— «кроме windows конечно, там само ядро сплошная дыра» — извините, но это бред.
Так писать некорректно. Если пишете время в формате 00:00:00.00, то не надо писать «мс», если пишете в милисекундах — пишите «57781 мс», если в секундах — «57.781 с».
Imho, бред. Если пользователь настроил браузер так, чтобы он спрашивал подтверждения для каждой куки то он и получает то что хотел. Если ему нужно подтверждение только для первой куки, то настраивать браузер ему нужно как-то подругому.
«Если пользователь отклоняет первую cookie, ему не нужна ни вторая, ни сорок девятая» — ложь… по меньшей мере спорное утверждение.
Вообще автора статьи надо выпороть, чтобы свой сбъективный взгляд на вещи не выдавал за вселенскую мудрость.
P.S. С большинством пунктов в статье я согласен.
Не понял, в чем угодно или не в MS Word?
А если речь идет о том чтобы «за копейку» сделать очень удобное изменение, то уверен что оно будет ненадежно — будет разбалтываться, потом будет искрить. Хорошо сделать можно, но розетка подорожает в разы.