Комментарии 28
Откуда в email только латинские буквы и цифры? И почему 8 символов?
en.wikipedia.org/wiki/Email_address#Valid_email_addresses
en.wikipedia.org/wiki/Email_address#Valid_email_addresses
Скорее не вредно, а бесполезно в подобных случаях. И то, от просто любопытных глаз скроет, особенно если название поля в базе будет вводить в заблуждение, типа passwod1 для номера телефона.
«Однако если увеличение длины выхода хеш-функции всего на один бит (из 256 или 512) увеличивает сложность атаки криптоаналитика на двоичный порядок (в два раза), то увеличение количества итераций для хеш-функции PBKDF2 в два раза увеличит сложность атак также только в два раза.»
и то и то в 2 раза? либо я что-то не понял, либо криво написано.
и то и то в 2 раза? либо я что-то не понял, либо криво написано.
Стандарт PCI DSS, описывающий требования к защите карточных данных, запрещает хранить полные номера карт в открытом виде. они должны быть превращены в «нечитаемый формат». Это связано с тем, что большинство платёжных систем имеют анти-фрод защиту и тупой перебор PAN+CVC+expire date поэтому смысл в 6+4 всё таки есть — он не позволяет просто взять и использовать идентификатор из какого-нибудь чека в мусорке.
6+4 хранить можно. Но вот держать рядом с ними хешированное значение нельзя.
хранить хеш от полного номера карты как автор пишет это в принцыпе == хранить номер карты в открытом виде, за такое когда вскорется будет гарантировано ататата!
как вскроется? и зачем вообще это хранить? в логи написал, напечатал на чеке и всё.
как? — случайно или в результате утечки/взлома, ну как обычно это происходит))
зачем хранить? — я бы тоже хотел знать ответ на этот вопрос.
чем запись в логи отличается от записи в базу? Особенно в ситуации если вы в юрисдикции где логи по закону нужно хранить долго. И на чеке такое тоже не стоит печатать, никто ведь не печатает на чеках полный номер карты, так зачем хеш печатать?
зачем хранить? — я бы тоже хотел знать ответ на этот вопрос.
чем запись в логи отличается от записи в базу? Особенно в ситуации если вы в юрисдикции где логи по закону нужно хранить долго. И на чеке такое тоже не стоит печатать, никто ведь не печатает на чеках полный номер карты, так зачем хеш печатать?
Запись в лог от записи в базу отличается тем что лог это как правило то, что регулярно просматривают в случае возникновения вопрос по той или иной операции, могут отправить его по почте в соседний отдел, а то и вовсе распечатать и выкинуть в мусорку — вещь относительно неконтролируемая. База же в соответствии с PCI DSS имеет ограниченный доступ и по хорошему даже DBA не должен видеть содержимое некоторых столбцов.
суть мысли была в том что «хранить номера карт нельзя, нигде и никогда».
И не важно в каком месте или виде, просто открыто номер карты или в виде хеша полного номера карты. Так же не имеет значения куда вы записали номер, в базу или в лог. Вы его сохранили и, «это фиаско...».
И не важно в каком месте или виде, просто открыто номер карты или в виде хеша полного номера карты. Так же не имеет значения куда вы записали номер, в базу или в лог. Вы его сохранили и, «это фиаско...».
А ну это бред — хранить его можно и нужно. Он хранится в процессинге, он хранится в бек-офисе. Он хранится в амазоне и гугл плее. Просто нужно соответствовать стандартам PCI.
В открытом видел, там где его могут увидеть случайные люди — на чеках и на логах — его нужно маскировать. Но это и не хранение по сути.
В открытом видел, там где его могут увидеть случайные люди — на чеках и на логах — его нужно маскировать. Но это и не хранение по сути.
чтобы не хранить в открытом виде есть шифрование таблиц. 6+4 хранить смысла нет так как данные в таком виде не нужны. В логах и прочих чеках — да, только с маской.
Большое спасибо за статью! Прочел на одном дыхании и с удовольствием ознакомлюсь с книгой, когда появится немного времени.
Хотелось бы еще отметить, что было бы здорово хоть немного дополнить фрагмент про:
Лично я как-то далеко не сразу понял, почему поставляющаяся вместе с хешом соль не влияет на время перебора. Возможно просто голова задурена работой, а возможно это и правда не на столько очевидно, как кажется когда дошло.
Хотелось бы еще отметить, что было бы здорово хоть немного дополнить фрагмент про:
Как и прежде, использование любой соли, которая поставляется вместе со значением хеш-функции, не влияет на время перебора (но по прежнему защищает от атаки по словарю).
Лично я как-то далеко не сразу понял, почему поставляющаяся вместе с хешом соль не влияет на время перебора. Возможно просто голова задурена работой, а возможно это и правда не на столько очевидно, как кажется когда дошло.
Я и сейчас не понимаю. Соль нужна для того, чтобы нельзя было сразу всю пачку хэшей отбрутфорсить — т.е. придется перебирать для каждого хэша отдельно.
Просто это не усложняет перебор совсем.
Вместо формулы hash(cardnumber) получается hash(salt+cardnumber). А функции хэширования пофиг, что вы в неё подставляете, если не гигабайты, конечно.
Вместо формулы hash(cardnumber) получается hash(salt+cardnumber). А функции хэширования пофиг, что вы в неё подставляете, если не гигабайты, конечно.
- Хешировать не сами значения, а конкатенацию исходного значения и некоторого секрета, который хранится отдельно.
Надо только учитывать, что сам секрет (соль) должен быть достаточно длинным.
Иначе, зная алгоритм хеширования и пару логин/хеш, можно подобрать эту «соль». А потом уже получать исходные данные по любому хешу.
Т.е. «соль» и исходный текст при подборе как бы меняются функционалом. Поэтому требования к длине исходного текста переносится на требование к длине секрета.
Ну да, секрет должен занимать террабайт, например. Чтобы усложнить перебор.
Достаточно 128 бит энтропии. Примерно 25 случайных символов или же 160 букв произвольного текста.
Совсем не обязательно. Достаточно комбинации из не менее 8-ми цифр, строчных и прописных букв латинского алфавита (некоторые можно исключить, чтобы не путались с цифрами), чтобы среднее время брутфорса уже превысило все рациональные сроки в большинстве случаев.
Ну а если длина текстовой «соли» будет 40-48 случайных символов из указанного набора, то подбирать можно будет до скончания веков.
Т.е. требования к длине «соли» должно быть таким же, как и требование к ключам шифрования.
Ну а если длина текстовой «соли» будет 40-48 случайных символов из указанного набора, то подбирать можно будет до скончания веков.
Т.е. требования к длине «соли» должно быть таким же, как и требование к ключам шифрования.
Если он лежит рядом, то это не поможет.
Что Вы имеете в виду под «рядом»?
Допустим, «соль» хранится в области, куда доступ напрямую запрещен. Только функции шифрования (хеширования). Это «рядом»?
Допустим, «соль» хранится в области, куда доступ напрямую запрещен. Только функции шифрования (хеширования). Это «рядом»?
Рядом это в той же таблице. Ведь так рекомендуют сейчас хранить пароли. Хэш с солью, а соль в соседней ячейке. Или даже в этой, но отделена от хэша разделителем. Тупо, согласен, но так рекомендуют.
На самом деле не так страшен черт… Все зависит от ценности данных.
В некоторых не особо критичных случаях можно не только хранить соль рядом, но и передавать ее открытым текстом:
1. При авторизации сервер передает клиенту случайную «соль» и запоминает ее и время ее генерации.
2. Клиент вычисляет, допустим, MD5(MD5(pass)+salt) и передает серверу.
3. Сервер проверяет время действия «соли». Если «протухла», то отвергает. Иначе вычисляет хеш от хеша с солью и сравнивает с пришедшим.
5. После проверки соль сбрасывается (если удачно) или перегенерируется, если предлагается повторная попытка авторизации.
Можно так же хранить не соль, а уже хеш от посоленного хеша. Кажется, разницы никакой.
Таким образом, перехват соли и посоленного хеша пароля не гарантируют узнавания самого пароля. Ведь даже узнав вероятный хеш пароля нельзя быть уверенным, что он именно тот самый, а не коллизия. И узнать пароль по раскрытому хешу нет никакой гарантии.
А использовать коллизию (повторная эксплуатация) тоже не получится, т.к. соль или посоленный хеш пароля либо будут сброшены после удачной авторизации, либо «протухнут» за время попыток подбора.
Таким образом, динамическая соль с ограниченным временем существования ничуть не хуже (а может быть даже гораздо надежнее) хранящегося отдельно, но короткого секрета.
И уж точно лучше отдельного секрета средней длины, но общего для всех.
В некоторых не особо критичных случаях можно не только хранить соль рядом, но и передавать ее открытым текстом:
1. При авторизации сервер передает клиенту случайную «соль» и запоминает ее и время ее генерации.
2. Клиент вычисляет, допустим, MD5(MD5(pass)+salt) и передает серверу.
3. Сервер проверяет время действия «соли». Если «протухла», то отвергает. Иначе вычисляет хеш от хеша с солью и сравнивает с пришедшим.
5. После проверки соль сбрасывается (если удачно) или перегенерируется, если предлагается повторная попытка авторизации.
Можно так же хранить не соль, а уже хеш от посоленного хеша. Кажется, разницы никакой.
Таким образом, перехват соли и посоленного хеша пароля не гарантируют узнавания самого пароля. Ведь даже узнав вероятный хеш пароля нельзя быть уверенным, что он именно тот самый, а не коллизия. И узнать пароль по раскрытому хешу нет никакой гарантии.
А использовать коллизию (повторная эксплуатация) тоже не получится, т.к. соль или посоленный хеш пароля либо будут сброшены после удачной авторизации, либо «протухнут» за время попыток подбора.
Таким образом, динамическая соль с ограниченным временем существования ничуть не хуже (а может быть даже гораздо надежнее) хранящегося отдельно, но короткого секрета.
И уж точно лучше отдельного секрета средней длины, но общего для всех.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда вредно хешировать