Я совсем не о порче БД говорю. Против порчи — бэкап хороший вариант.
Я говорю о том, что конкретное физическое лицо с преступными целями рутирует хостинг. Подсадят шеллы во все папки хостинга. Утянут пароли, зайдут в базы данных, найдут таблицу tralala_users и скопируют ее к себе на диск. В этой таблице скорее всего есть столбик с хэшами. Эти хэши вынут из столбика и загрузят на вход такому современному зверю с 200-ми или 500-ми процессорами, который работает круглосуточно и только и умеет делать — так это считать хэши.
После прохождения некотого времени какая-то часть паролей (подозреваю, большая часть) окажется расшифрованной. Эти расшифрованные пароли загрузят в другую базу данных и «скормят» серверу, который будет заходить на определенные сайты и опять же в круглосуточном режиме будет пытаться логиниться. Например, скайп, или в Яндекс деньги (там сейчас SMS-ки сделали в виде подтверждения), или еще куда-нибудь. И куда-то они залогинятся! И у какого-то количества пользователей на счету будут деньги, которые пропадут!
Именно поэтому, если у вас бизнес связан с деньгами и вы учитываете их на счетах пользователей, то секундное присутствие шелла уже грозит вам следствием (не была ли утянута база) и потом просьбой ко всем пользователям заменить свои пароли. Это может плохо отразиться на вашем бизнесе.
Очевидно, если вы работаете на известном движке, то задача такому мошеннику, который пароли собирает, облегчается до нельзя, поскольку точно известно, где брать, что брать и даже для каждого движка есть уже готовые скрипты, которые за 1 секунду все сделают.
В этой статье я хотел усложнить задачу мошенникам. Заставить их либо уйти сразу с сайта, поскольку на нем разбираться надо, как все устроено, либо хотя бы замедлить его работу. Тогда можно успеть зайти и заблокировать его IP.
Извините, что слишком подробно все описал. Надеюсь читать было нескучно.
К сожалению я не понял, что вы хотите сказать приведенной ссылкой.
Как бы там ни было, движки, с которыми мне приходится иметь дело, не кодируют данные для доступа к базам данных. А работать мне приходилось из известных с WP, JOOMLA, CS-CART. Из менее известных — MODX, ShopCms и несколькими другими. Причем, что удивительно, когда я клиентов пугаю перспективами этого открытого хранения, то никто не пугается! Ни один! А один клиент, имея магазин с оборотом 5 миллионов рублей в месяц, все пароли имеет одинаковые. Это имя его кошки. Предположим, «masha». Один раз я его напугал таки рассказом о том, чем это грозит и тогда в самом ответственном месте он изменил пароль на имя второй кошки, условно «dasha». После того, как я ему откровенно сказал, что я об этом думаю, он сжалился и изменил пароль на (опять же условно) «Masha,Dasha». Это меня более или менее устроило.
Скажите, вы считаете, что проблема высосана из пальца, а я «маньяк безопасности»?
Да! Пролет! Я, оказывается, пользовался плохим онлайн-декодировщиком. Сейчас поискал другой и да! Вы абсолютно правы! Сейчас я перефразирую этот абзац.
Именно это я, кажется, и предлагаю. Для типовых движков все может быть сложнее. Осложняется дело SEO рерайтингом, который везде реализован по-разному. В cs-cart, например, это делается с помощью аддона. То есть конечно, любой двиг можно преобразовать для безопасности. Но это может быть очень сложно и в каждом случае надо подходить индивидуально.
Если брать любой движок, то первым делом, на мой взгляд, надо зашифровать сведенья для доступа к базе. Так потеряв на некоторое время сайт, можно хотя бы базу данных сохранить и не просить пользователей, чтобы пароли меняли.
Нет. Не пробовал. Статья в большой степени написана для тех, кто работает на публичных хостингах и не пользуется https. Возможно, это стоило бы указать особо! Именно там особенно актуальны описанные проблемы безопасности и сложности с производительностью.
Я говорю о том, что конкретное физическое лицо с преступными целями рутирует хостинг. Подсадят шеллы во все папки хостинга. Утянут пароли, зайдут в базы данных, найдут таблицу tralala_users и скопируют ее к себе на диск. В этой таблице скорее всего есть столбик с хэшами. Эти хэши вынут из столбика и загрузят на вход такому современному зверю с 200-ми или 500-ми процессорами, который работает круглосуточно и только и умеет делать — так это считать хэши.
После прохождения некотого времени какая-то часть паролей (подозреваю, большая часть) окажется расшифрованной. Эти расшифрованные пароли загрузят в другую базу данных и «скормят» серверу, который будет заходить на определенные сайты и опять же в круглосуточном режиме будет пытаться логиниться. Например, скайп, или в Яндекс деньги (там сейчас SMS-ки сделали в виде подтверждения), или еще куда-нибудь. И куда-то они залогинятся! И у какого-то количества пользователей на счету будут деньги, которые пропадут!
Именно поэтому, если у вас бизнес связан с деньгами и вы учитываете их на счетах пользователей, то секундное присутствие шелла уже грозит вам следствием (не была ли утянута база) и потом просьбой ко всем пользователям заменить свои пароли. Это может плохо отразиться на вашем бизнесе.
Очевидно, если вы работаете на известном движке, то задача такому мошеннику, который пароли собирает, облегчается до нельзя, поскольку точно известно, где брать, что брать и даже для каждого движка есть уже готовые скрипты, которые за 1 секунду все сделают.
В этой статье я хотел усложнить задачу мошенникам. Заставить их либо уйти сразу с сайта, поскольку на нем разбираться надо, как все устроено, либо хотя бы замедлить его работу. Тогда можно успеть зайти и заблокировать его IP.
Извините, что слишком подробно все описал. Надеюсь читать было нескучно.
Как бы там ни было, движки, с которыми мне приходится иметь дело, не кодируют данные для доступа к базам данных. А работать мне приходилось из известных с WP, JOOMLA, CS-CART. Из менее известных — MODX, ShopCms и несколькими другими. Причем, что удивительно, когда я клиентов пугаю перспективами этого открытого хранения, то никто не пугается! Ни один! А один клиент, имея магазин с оборотом 5 миллионов рублей в месяц, все пароли имеет одинаковые. Это имя его кошки. Предположим, «masha». Один раз я его напугал таки рассказом о том, чем это грозит и тогда в самом ответственном месте он изменил пароль на имя второй кошки, условно «dasha». После того, как я ему откровенно сказал, что я об этом думаю, он сжалился и изменил пароль на (опять же условно) «Masha,Dasha». Это меня более или менее устроило.
Скажите, вы считаете, что проблема высосана из пальца, а я «маньяк безопасности»?
Если брать любой движок, то первым делом, на мой взгляд, надо зашифровать сведенья для доступа к базе. Так потеряв на некоторое время сайт, можно хотя бы базу данных сохранить и не просить пользователей, чтобы пароли меняли.