10x!

Петербург. 21 век. Лимит ВХОД 20Гб на анлиме в 100мбит. Электронный ППЦ.

"кто как играет..."

дело не в БД, а в том чем ею пользуются.

строго порядковый идентификатор

лично в моих некоторых проектах такое требование есть - чтобы у новой записи был строго следующий идентификатор.

Перебор он и в Африке будет перебором. Введение критериев избавит от прямого перебора, но не избавит от сути - всё перехватывается.

Хотя если SSL и пару js-трюков - думаю будет бессмысленно.

Я веду к тому, что сгенерированая соль для хэша (salt) всё-равно может быть перехвачена, потому что отдается клиенту. Тоесть неважно чем мы будем пользоваться для перебора - важно что у нас всё для этого есть.

можно поспорить только в том случае, если пароли в БД уже лежат в хэше. Тогда выполнение любого хэша на стороне клиента - бессмысленно.

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

Грамотнее будет выдавать сессию на логин на основе косвенных факторов - тоесть ip, user-agent, заголовки. Тоесть не показывать и не рассказывать никому о принципе привязки к сессии.

вполне возможны, когда требуется строгий порядок ID, в ТЗ всё бывает

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

ч0рт, и обязательно в понедельник, а!