The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз языка программирования PHP 7.3, opennews (?), 06-Дек-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


19. "Релиз языка программирования PHP 7.3"  –1 +/
Сообщение от Ilya Indigo (ok), 07-Дек-18, 00:22 
> При сборке с опцией configure --with-password-argon2 в функциях password_hash()...

Да сдалась 300 лет эта убогая ф-ия для идиотов, в которой ещё заботливо запретили использовать свою соль!
Лучше бы в hash_hmac() алгоритмы bcrypt и argon2(i|id|d) завезли.
А так всё равно приходится пароли алгоритмом sha3-512 хешировать. :-(

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

P.S. Прошёл уже год а документация по sodium всё также отсутствует даже на английском.
https://secure.php.net/manual/en/book.sodium.php

Ответить | Правка | Наверх | Cообщить модератору

24. "Релиз языка программирования PHP 7.3"  +3 +/
Сообщение от blblblblbl (?), 07-Дек-18, 01:19 
У тебя что, соль какая-то особая, забористая?
Чем обычная не устраивает, а?
Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз языка программирования PHP 7.3"  –1 +/
Сообщение от Ilya Indigo (ok), 07-Дек-18, 09:32 
Особенная, состоящая из статической и динамической части, при этом статическая хранится в конфиге, а динамическая берётся из id и время регистрации, которые запрещено менять в БД, а главное только я знаю как готовить хэш, и только я знаю как его проверять! А я всегда точно знаю, каким алгоритмом он будет создан и обязательно будет проверен, а также точно какой длины он будет!

password_hash()/password_verify() предполагает что соль с параметрами всегда хранится с хешем, и алгоритм, соль и параметры мало того что всем известны, так ещё он всегда готовится и проверяется одинокого и password_verify() можно скормить вообще любой валидный хэш подсунув его вместо хэша требуемого пользователя!
Такого мне не нужно, кушайте сами!

Ответить | Правка | Наверх | Cообщить модератору

55. "Релиз языка программирования PHP 7.3"  +3 +/
Сообщение от Аноним (55), 07-Дек-18, 10:42 
> а главное только я знаю как готовить хэш, и только я знаю как его проверять

Security by obscurity? Спец, без сомнения!

Ответить | Правка | Наверх | Cообщить модератору

56. "Релиз языка программирования PHP 7.3"  +/
Сообщение от blblblblbl (?), 07-Дек-18, 10:43 
> Особенная, состоящая из статической и динамической части, при этом статическая хранится в конфиге

Т.е. утекла каким-то образом статическая часть, здравствуй генерация новых паролей.
А если утекла статическая часть, то какова вероятность того, что злодей знает алгоритм готовки хеша?

Соль вообще-то не обязана быть скрытой, она вообще про другое.

> предполагает что соль с параметрами всегда хранится с хешем, и алгоритм, соль и параметры мало того что всем известны, так ещё он всегда готовится и проверяется одинокого и password_verify() можно скормить вообще любой валидный хэш подсунув его вместо хэша требуемого пользователя!

Вот, пожалста, хеш пароля, какой он?
$2y$10$kCkVDOxVduJsFkeD5mVcMO2YxK3/BcV02a0rmse6/KE6qjfDwSGcK

Дан пароль jog7ygyt8t.
Какой мне валидный хеш от любой другой строки подсунуть в password_verify, чтобы пароль был признан правильным? Предполагается, что пароль как бы неизвестен, т.е. брать хеш от этого пароля и предлагать тут нельзя.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

61. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Ilya Indigo (ok), 07-Дек-18, 11:06 
>> Особенная, состоящая из статической и динамической части, при этом статическая хранится в конфиге
> Т.е. утекла каким-то образом статическая часть, здравствуй генерация новых паролей.

1 НЕТ! Без динамической части соль бесполезна, для генерации нужна и соль и данные из БД для каждого пользователя!
2 Для password_hash()/password_verify() здравствуй генерация новых паролей By Design!

> А если утекла статическая часть, то какова вероятность того, что злодей знает
> алгоритм готовки хеша?

Если он получил доступ к ssh, то тут, конечно, уже ничего не поможет.
Но если он каким-то образом получил доступ только к MariaDB, причём прецеденты были, то это ему никак не поможет в отличие от password_hash()/password_verify() где достаточно просто всунуть валидную хэш для админа. (P.S. И да id админов в конфиге вручную задаю)
> Соль вообще-то не обязана быть скрытой, она вообще про другое.

Я знаю, но меня не устраивает такой принятый By Design порядок вещей, что можно получив доступ к СУБД тупо вставить хэщ другого пользователя, пароль которого тебе известен или вообще самому сгенерировать её и такой хэш будет валиден.

> Вот, пожалста, хеш пароля, какой он?
> $2y$10$kCkVDOxVduJsFkeD5mVcMO2YxK3/BcV02a0rmse6/KE6qjfDwSGcK

Да мне плевать какой он, я сгенируирую новый стандартным способом, пароль которого буду знать и заменю хэш в таблице админа, сделаю свои тёмные дела, верну старый хеш назад, и про это даже никто не узнает, если конечно в access log не посмотреть, а если админ заходит из той же сети или с телефона такого же оператора то он даже не сможет отличить он это входил или нет.

Ответить | Правка | Наверх | Cообщить модератору

68. "Релиз языка программирования PHP 7.3"  +/
Сообщение от blblblblbl (?), 07-Дек-18, 12:02 
> 1 НЕТ! Без динамической части соль бесполезна, для генерации нужна и соль и данные из БД для каждого пользователя!
> 2 Для password_hash()/password_verify() здравствуй генерация новых паролей By Design!

1. зачем тогда статический кусок? без него это такой же хеш: динамическая соль + алгоритм хеша
2. с чего вдруг? тут перегенерация только если база утекла и то не так страшно, т.к. секретного алгоритма нет, а хеши достаточно стойкие.

> Если он получил доступ к ssh, то тут, конечно, уже ничего не поможет.

А если это админ-обиженка?
Все алгоритмы на руках, прикопает до поры.

Ну и если кто-то со стороны ходит по базе как у себя дома, то уже всё плохо.

Ответить | Правка | Наверх | Cообщить модератору

74. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Ilya Indigo (ok), 07-Дек-18, 12:35 
>> 2 Для password_hash()/password_verify() здравствуй генерация новых паролей By Design!
> 1. зачем тогда статический кусок? без него это такой же хеш: динамическая
> соль + алгоритм хеша

Затем, чтобы
1 При получении доступа к БД злоумышленник не смог получить всю соль и сгенерировать хэш, даже если бы знал как его генерировать.
2 Чтобы имея под рукой аналогичный сайт и/или микрофреймвёрк этого сайта и зная как её генерировать всё равно не смог бы этого сделать без доступа по ssh.
> Ну и если кто-то со стороны ходит по базе как у себя
> дома, то уже всё плохо.

Я не говорю что это нормально, у меня вообще доступ к ней только через сокет, но я сайты не для себя делаю и админю я далеко не все, и не с одним моим сайтом проблем со взломом не было, и я не хочу нарушать эту традицию!
Если я могу сделать лучше чем это по дизайну (длина хэша для пароля меньше и всегда постоянная при той же безопасности, и более высокая защита при доступе к СУБД), то я это делаю!

Ответить | Правка | Наверх | Cообщить модератору

94. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Sw00p akaJerom (?), 07-Дек-18, 14:54 
идея не плохая с разделением на части соли, но прикол в том, что постановка задачи у вас изначально не правильна, она равносильна этому - есть шифрованные данные (пример в общем, и не обязательно про хеширование), но криптоаналитик не знает алгоритм, при взломе шифра, уже предполагается, что криптоаналитик знает все о шифре, и все тут дорлжно упираться в ключ (только он не известен), говорить об "атакующий не знает алгоритма" - смысла нет. И в вашем случае говорить, что атакующий не видит части соли прописанной в конфиге, имея доступ только к бд, всего лишь навсего "безопасность через неясность", что категорически не приемлемо в самом понятии криптографии (самообман). Ну есть только доступ к бд, а что мешает сделать на подобии load_file('config.php') и тому подобное? (немного поутрировал)
Ответить | Правка | Наверх | Cообщить модератору

101. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Ilya Indigo (ok), 07-Дек-18, 15:22 
Я с вами не согласен.
> уже предполагается, что криптоаналитик знает все о шифре

1 Без ssh доступа к серверу нет, а если доступ получен, то смысла уже нет.
> "безопасность через неясность"

ДОПОЛНИТЕЛЬНАЯ безопасность...
Безопасности много не бывает, если при этом она не вредит производительности и удобству авторизации.
Это как сказать, зачем закрывать дверь на замок, ведь в наше время есть куча способов открыть любой замок, по этому замок на двери не нужен, а всё будет упираться в...
> а что мешает сделать на подобии load_file('config.php')

Отсутствие ssh доступа к серверу. при наличие которого уже ничего не нужно будет делать.

P.S. Поставленная мной задача обломать того кто получит доступ к СУБД чтобы заменить хэш админа и зайти как ни в чём не бывало под админом, при этом сохранить надёжность хэша, удобство авторизации и уменьшить объём кэша решается.

Я не говорю, что к СУБД можно будет подпускать кого угодно ничего не опасаясь!
Это просто дополнительная защита, которая в случае эксплоита субд или кривых рук админа может или защитить или заставить взломщика предпринять более заметные действия например вход по ssh, который в auth.log ssh сразу будет заметен, в отличии от access.log apache.

Ответить | Правка | Наверх | Cообщить модератору

106. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Sw00p akaJerom (?), 07-Дек-18, 15:50 
> Я с вами не согласен.
>> "безопасность через неясность"

принято, если со мной не согласны, то посоветую более вторитетный источник - Б. Шнайер, почитайте его труды, "на пальцах" все разъясняет.

> ДОПОЛНИТЕЛЬНАЯ безопасность...

заключил бы это в кавычки, "безопасность" - процесс, а не метод.

> Безопасности много не бывает, если при этом она не вредит производительности и
> удобству авторизации.

Она должна быть достаточной и необходимой с условиями требований.

> есть куча способов открыть любой замок,

ну вот отлично, значить нужно прийти к выводу, что делается "что-то не так"

>по этому замок на двери не нужен, а всё будет упираться в...

дверь то, тогда зачем?


>> а что мешает сделать на подобии load_file('config.php')
> Отсутствие ssh доступа к серверу. при наличие которого уже ничего не нужно
> будет делать.

load_file - имелось ввиду средствами самой СУБД.

> как ни в чём не бывало под админом

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

Ответить | Правка | Наверх | Cообщить модератору

93. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Sw00p akaJerom (?), 07-Дек-18, 14:44 
на то и коллизии существуют
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

100. "Релиз языка программирования PHP 7.3"  +/
Сообщение от blblblblbl (?), 07-Дек-18, 15:20 
какова вероятность коллизии у bcrypt с blowfish или argon2?
тупой брутфорс на видеокарте на 4 порядка медленнее, чем у того же sha512

в конце-концов выяснилось, что защищается от подмены хеша в базе, чтоб не дать залогиниться потом под паролем для этого хеша

Ответить | Правка | Наверх | Cообщить модератору

105. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Sw00p akaJerom (?), 07-Дек-18, 15:38 
> какова вероятность коллизии у bcrypt с blowfish или argon2?

ровно такая же как и md5, все зависит от битности.

> тупой брутфорс на видеокарте на 4 порядка медленнее, чем у того же
> sha512

от чего зависит эта "медленность" ?

> в конце-концов выяснилось, что защищается от подмены хеша в базе, чтоб не
> дать залогиниться потом под паролем для этого хеша

что имелось тут ввиду я не понял

Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз языка программирования PHP 7.3"  +/
Сообщение от blblblblbl (?), 07-Дек-18, 16:46 
> ровно такая же как и md5, все зависит от битности

а в реальной жизни, без применения велосипедов?
тот же солёный md5 можно, но реально сложно же

> от чего зависит эта "медленность" ?

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

> что имелось тут ввиду я не понял

товарищ выше написал, зачем он так делает

Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз языка программирования PHP 7.3"  +/
Сообщение от blblblblbl (?), 07-Дек-18, 16:49 
Собственно я к тому, что любой хеш нам только даёт возможность распознать утечку и инициировать смену паролей за разумное время, но не даёт 100% гарантии защищённости.
Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз языка программирования PHP 7.3"  +/
Сообщение от blblblblbl (?), 07-Дек-18, 01:21 
> Лучше бы в hash_hmac() алгоритмы bcrypt и argon2(i|id|d) завезли.

ну если так надо, берёшь С и завозишь пулл-реквестом

> А так всё равно приходится пароли алгоритмом sha3-512 хешировать. :-(

зачем?

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

49. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Ilya Indigo (ok), 07-Дек-18, 09:42 
> ну если так надо, берёшь С и завозишь пулл-реквестом

Трачу от недели до месяца на разбор всех тонкостей как это делается, реквестю, и в лучшем случае посылаюсь сразу, мол для паролей жрите password_hash()/password_verify() а hash_hmac вообще совсем для другого предназначен, а в худшем мой реквест просто будет висеть мёртвым грузом.
Бывало, может не месяц, но достаточное кол-во времени тратил на SR а меинтайнер с подобными объяснениями их отклонял.
Не так уж часто, кол-во принятых гораздо больше, но уже чую за что можно взяться, а что будет простой тратой времени.

> зачем?

Затем, что в отсутствии возможности использовать bcrypt и argon2(i|d|id), sha3-512 остаётся самым надёжным алгоритм для хэша пароля.

Ответить | Правка | Наверх | Cообщить модератору

47. "Релиз языка программирования PHP 7.3"  –1 +/
Сообщение от Мимокрокодилemail (?), 07-Дек-18, 09:34 
http://php.net/manual/ru/function.password-hash.php
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

51. "Релиз языка программирования PHP 7.3"  +/
Сообщение от Ilya Indigo (ok), 07-Дек-18, 09:45 
И что?
Внимание

Эта опция была объявлена устаревшей начиная с PHP 7.0.0. Рекомендуется использовать автоматически генерируемую соль.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру