Redbaron_chaos,
Могут отказать даже после прошествия срока и пригласить к регистратору, учтите этот важный нюанс. Мы когда восстанавливали - на пустой кошель с нулевым БЛ доступ восстановился без проблем за сутки, а вот на не пустой с неплохим БЛ отказали в восстановлении - пригласили к регистратору. Хотя оба ВМИД были привязаны даже друг к другу и использовались на одном железе, с одних ИП и т.д.
Енум не ставили? Поставьте как решите вопрос.
Опять набор голословных утверждений с хамством и переходом на личности. Очень симптоматично.
Впрочем, нам тут в голову мысль пришла, мы с месяц назад закончили аудит среднего размера проекта на безопасность, заказчик (с сёрча) был очень доволен нами, но очень недоволен предыдущим программистом. И тут вдруг Вы, ранее общавшийся с нами адекватно, прямо таки агритесь, хамите и переходите на личности. Похоже смысла продолжать с Вами диалог нет, развлекайтесь дальше без наших ответов.
Отлично понимаем, просто шире смотрим на вещи.
Мы выше отметили, что собственно вход по паролю сам по себе не идеально безопасен (тот же вход по ключам/цифровой подписи лучше), поэтому речь в любом случае о компромиссе, а SeVlad вон уверен что проблема с безопасностью только когда его на почту присылают, а ссылки можно хоть веером рассылать.
Так это им не делается:) Но сама возможность есть и кое-где так делается, натыкались на это не раз и сами такое реализовывали.
Но самоцель же не ссылка или пароль, самоцель защита входа и именно для входа надо вводить различные свойства. В конечном итоге все зависит от степени защиты которая требуется. Если у хакера есть доступ к почте, то он всегда закажет ссылку и восстановит пароль заново. Если же у хакера есть доступ к смс, то он сделает то же самое. Поэтому если заботит защита входа от этого вектора атак, то и ссылка не пригодна, если же защита от этого вектора атак не беспокоит, то и пароль будет адекватной мерой.
Мы с самого начала говорили про ключевое слово "так же". Ссылка практически так же безопасна/небезопасна как и присылка пароля, при этом генерация пароля имеет уже тот плюс, что он будет уникальный и сложный.
Наши же оппоненты зациклились на идее (никем не высказанной) что раз мол пароль посылается, то он и в базе хранится в открытом виде. А когда им указали на то, что это не обязательно так - начили агриться. Поэтому диалог и пошел в неконструктивной манере.
У всех. Но объясняется это не в азбуке, а в университетских учебниках:) Ну и для этого нужен большой проект, а не доработки вида "а давайте добавим возможность иметь 2 категории вместо одной"©
Во-первых, если объем кода "друпела" Х, то при большой разработке объем кастюмного кода будет 10*х. Таким образом кода друпела там останется 10%. А то и меньше, если проект реально большой. Каковую мысль до Вас и пытаются донести. Чем больше проект - тем меньше в %% соотношении в нем исходного кода взятой цмс. Разве не очевидно?
Во-вторых, иногда надо менять и сам "друпел" - вспомните, много в последнем друпеле от первого осталось? А в зенде? В последнем пхп от первого? Рефакторинг старого кода по Вашему вымысел? Потеря совместимости с legacy миф? Или зенд, друпел и пхп делали джуны из поколения жоп несущие ламерский бред?
В-третьих, и сам "друпел" иногда меняется. Выходит новая версия сильно отличная от старой и Вам или желательно (если появились новые плюшки) или необходимо (если утеряна совместимость) менять свой код .... или же если своего кода много (см. пункт 1) и рефакторинг под новую версию нерационален, то на новую версию просто не переходят со всеми вытекающими.
Это какой-то несвязный бред. Теперь Вы почему-то заговорили о наших личностях, спрашиваете при чем тут они и рассуждаете о каких-то "разработчиках". Тема назывется "пароли пользователея на почту", напоминаем.
Мы уже ответили, на что Вам и указали.
Т.е. по сути Вам ответить нечего и Вы опять переходите на личности.
На этот Ваш пост мы уже отвечали показывая его несостоятельность, повторяться не будем - сходите прочитайте ответ.
Так же как и при получении ссылки:) Ключевое слово "так же". Т.е. если делать эти проверки, то они будут мешать (или помогать) везде.
Пущай все и авторизирует. В принципе после авторизации 2-3 устройств вопрос для обычных юзеров снимается, поэтому у нас заказчики достаточно часто соглашаются на такой вариант. Опять же, можно позволить юзеру настраивать это все - как минимум ИП проверку позволить отключить или сделать проверку хотя бы по региону + пробивать на принадлежность к фрипрокси и тору. Варианты-то решения есть, вопрос просто в том кто как заморачивается.
И баланс в целом сводится даже не к "безопасности/сложности реализации", сколько к "безопасности/удобству для юзера". Кому нужен офигенно безопасный сайт на который никто не ходит - пусть отключит его от интернетов и положит в сейф:)
Да речь на самом деле лишь о степени паранойи и ее реализации.
Если уж совсем параноить, то вход на сайт должен быть только по цифровой подписи. Восстановление которой в случае утери происходит у нотариуса при личном присутствии и со справкой о дееспособности в зубах.
Поэтому когда кто-то утверждает что автосгенеренный пароль зло, но при этом видит в присылании ссылки ответ на все вопросы безопасности - это напрягает даже больше, чем когда пароли хранятся в открытом виде. Потому что дымовая завеса от этой псевдобезопасности маскирует реальные проблемы.
Забыли про Вами же поначалу упомянутую проверку по IP/UA и т.д.? Удобная у Вас память.
Совсем не обязательно вообще-то.
Но если Вы сбрасываете пароль через двухфакторку и входите через нее же, то нет никакой проблемы присылать пароль сразу.
Хранение и распространение разные статьи 😂
Есть вариант шифровать (а не хэшировать) пароль генерируя ключ на основе пары секретный вопрос/ответ (или другие данные), тогда вполне реально не хранить пароли в открытом виде, но в то же время предоставить возможность восстановить именно оригинальный пароль. Но как правило такие сложности это никому на фиг не нужный гиморой.
Dram,
Остановитесь на минутку.
Погуглите sql иньекции и зачем нужно экранирование.
Не забывайте устанавливать кодировку после соединения с базой и выясните зачем это надо.
Используйте или https://www.php.net/manual/ru/mysqli.real-escape-string.php экранирование или плейсхолдеры https://www.php.net/manual/ru/mysqli.prepare.php , второе более модно.
И снова - вместо ответа по делу, переход на личности и хамство. ЧТД.
Много слов, но до сих от Вас так и нет ни одного реалистичного сценария, при котором посылка ссылки от чего-то защитила бы, по сравнению с посылкой пароля. Который мы уже дважды просили до этого. Но Вам интереснее выступать на бис с банальными очевидностями не имеющими отношения к делу и хамить собеседникам. Жаль.
У Вас шаблон диалога так и не поменялся - когда Вам нечем аргументировать по сути - Вы начинаете хамить собеседнику, что бы он или слился с топика или начал хамить в ответ и Вы бы его забанили. Неужели за столько лет не придумали ничего пооригинальнее?
Если Вы хотите пословоблудить, то не хранить в открытом виде вообще невозможно, ведь с момента когда юзер передает пароль на сервер и до момента его обработки он хранится в открытом виде. Ах ах ах, ужас, все хранят пароли в открытом виде какое-то время (ну кроме воблы, которая шифрует мд5 перед передачей 😂 ).
Если же Вы постараетесь разобраться в вопросе, то поймете, что никто не мешает отправить пароль в смс, а сам пароль сохранить не в открытом виде.
Правило "сходи сначала по ссылке перед тем как выставить новый пароль" это именно диктат своих правил, которые не грозят безопасности сервера.
Еще раз - словоблудие словоблудием, но от Вас так и нет ни одного реалистичного сценария, при котором посылка ссылки от чего-то защитила бы, по сравнению с посылкой пароля.
Никак не спасает от одинаковых паролей на всех сервисах.
