Шёл 2020 год...
Украинский хостинг решил не хранить пароли в открытом виде...
Подробнее
Повышение уровня безопасности почты Inbox ☆ Новости компании Хос... 14:34 to me v : hosting ui-snain Добрый день, Для повышения уровня безопасности и соответствия требованиям сертификации PCI DSS принято решение хранить все пароли в захешированном виде. Решение отказаться от хранения паролей в открытом виде давалось не легко, так как мы понимаем, насколько удобно посмотреть в панели управления пароль к почте, зайти одним кликом в почтовый ящик или подключиться к FTP. В то же время всё большее количество клиентов пользуются услугами хостинга, хранят почту на наших серверах, поэтому, понимая возложенную ответственность, при выборе между удобством и безопасностью выбор сделан в пользу безопасности.
безопасность,пароли,security,password,песочница
Еще на тему
P.S. и так то компания не украинская,а литовская
Комментарии жгут не меньше.
когда делается иначе, базу сливают и любители ставить везде одинаковый пароль не могут потом зайти в свои одноклассники\танки\вконтакте\нужное подчеркнуть
Прост обычно утечка паролей означает утечку базы, а утечка базы это такой пиздец сам по себе, что о паролях думать уже как бы и смысла нет.
Я не призываю отказываться от шифрования паролей - это копеечная операция, которая считается признаком хорошего тона. Я говорю, что смысла от нее немного - поможет лишь тем, у кого сложный пароль, что тоже неплохо.
1) адекватные люди не хранят соль там же где и хеш
2) база не обязательно находится на том же сервере где и сервис, который её использует
3) наличие данных хранящихся в базе не обязательно как то поможет в получение доступа к сервису, который их использует и где хранится соль
ээээ не хочу показаться грубым, но ты только что написал в_одном_посте "Надеяться на то, что соль не утечет - это security by obscurity" и тут же "то лучше вообще свой алгоритм хеширования навелосипедить - дело нехитрое, а потенциальный мамкин хакер обалдеет", упорот штоли)?
И я еще раз подчеркну, что решение с хешингом паролей - это просто симуляция защиты. К таблицам в БД в принципе не должно быть прямого доступа.
"Обрати внимание на зачем-то выброшенную тобой часть предложения" а тут проблема что человек либо за либо против, я увидел два противоречивых мнения в посте, о чем и решил сообщить. к "безопасность через неизвестость" у меня лояльное отношение, хм, такая техника обмазана грязью почем напрасно. проблема в том что зачастую её используют как основополагающий барьер защиты, которым она естественно совсем не является. а как дополнительный барьер она очень даже подходит, о чем собственно я и хотел донести говоря о грамотном хранении соли и нестандартных применениях алгоритмов хеширования
К тому, что все обращения к БД должны быть ограничены лишь обращением к хранимым процедурам у которых есть права на работу с таблицами. Таким образом исключаются и SQL-инъекции и даже каким-либо образом утекший пароль, с помощью которого бэкэнд обращается к БД (или, если БД ограничена локалхостом, то - доступ к шеллу), не дает злоумышленнику возможности получить все пароли и/или хеши от паролей, равно как и пользовательские данные. Но во многих проектах принято напрямую херачить CRUD запросы и даже не всегда экранировать аргументы. А для "безопасности" гордо хешировать пароль.
Я еще раз подчеркну, что нет ничего плохого в хешировании пароля, прост это не мера внешней безопасности, а внутренней - чтобы те, у кого есть рабочий доступ к БД не слили базу паролей. Но даже в таком качестве оно работает не очень хорошо.
Тем не менее, когда говорят о безопасности, то подразумевают многослойную защиту - типа, если человек накосячит неумышленно, то многослойная защита не позволит злоумышленнику получить данные. Отказ от прямой работы с таблицами, а точнее - запрет для используемого бэкэндом аккаунта СУБД на любые CRUD-операции, гарантирует, что даже если злоумышленник из-за чьего-то дебильного косяка получит шелл-доступ и реквизиты для работы с СУБД - он ничего не сможет оттуда достать.
В популярных проектах, разрабатываемых на территории бСССР это, разумеется, не принято - считается вообще в порядке вещей, чтобы скрипты подключались к СУБД с полными правами и без пароля. Да что там, в куче мест у пользователя под которым крутится вебсервер есть даже право на изменение файлов самих скриптов, потому как "ну и чо? Все так делают, чего париться...".
я обратного не утверждал, в этом плане кстати совершенно согласен, система многослойна и уровни доступа, а также защита, должны быть многослойными.
"В популярных проектах, разрабатываемых на территории бСССР это, разумеется, не принято - считается вообще в порядке вещей, чтобы скрипты подключались к СУБД с полными правами и без пароля. Да что там, в куче мест у пользователя под которым крутится вебсервер есть даже право на изменение файлов самих скриптов, потому как "ну и чо? Все так делают, чего париться.."
пиздёшь =) доступы используются как read-only, так и с ограниченными правами, так и root, в зависимости от того что нужно. там где php узается fpm из под www-data, файлы все chown root только на чтение и всё это в docker, чтобы оттуда получить доступ хотя бы к целевой системе, нужно хорошо запотеть
забавно было бы глянуть на отрытую базу паролей гугла или пусть даже мылояндекс. эпоха 12345678 ведь ушла