Хранение номеров мобильных телефонов и кредитных карт в открытом виде?

Question

[Zulusho]

Здравствуйте, есть такая задача:
Пользователи вводят свой номер, он подтверждается по смс.
Пользователь совершает перевод средств карту одного зелёного банка менеджеру, после чего менеджер подтверждает оплату.
Поскольку зелёный банк может возвращать только имя плательщика и последние четыре цифры номера карты(и сумму перевода), менеджер может искать оплату в выписке с использованием этих данных. Данные о карте и имени плательщика получаем от пользователя.
Если оплата не подтверждена - менеджер звонит клиенту по номеру, который мы подтвердили.
Соответственно менеджер должен в читаемом виде получать и данные о плательщике, о карте(последние 4 цифры), и о номере.
Один пользователь может оплачивать неограниченному количеству менеджеров и один менеджер может получать неограниченное количество оплат от неограниченного количества пользователей.
Вопрос – в каком виде хранить эти данные в базе максимально безопасно?
Безопасно ли хранить их в открытом виде? OWASP запрещает это делать

Answer 1

[Александр Аксентьев]

OWASP запрещает это делать

Ну таки шифруйте любым шифром - это автоматически делает их неоткрытыми. Именно это по вашей же ссылке и написано и перечислены варианты как можно скрыть данные. Необязательно это должно быть необратимое хеширование.

Безопасно ли хранить их в открытом виде?

даже с шифрованием при доступе к серверу/исходникам данные можно расшифровать, и безопасности это никак не прибавляет.
Защитит если данные сольют без доступа к коду или всему серверу, через стандартную инъекцию например на сайте.

Comments

[Zulusho]

Есть ли способы шифрования, при которых ключи для дешифровки можно будет генерировать на клиенте?
К примеру, из пароля пользователя - в базе он хранится в bcrypt, при получении доступа к ней, получить пароли не получится.
Слышал про end-to-end как в мессенджерах, но насколько понял, там нужно хранить ключи на клиенте пользователя и менеджера, но один клиент может заходить с разных платформ, одни данные клиента должны быть доступны всем менеджерам, да и в браузере негде хранить ключи, localstorage/cookie могут быть сброшены в любой момент

[Александр Аксентьев]

Zulusho, в любом варианте можно шифровать на клиенте, но вам все равно придётся надежно хранить ключи чтобы манагер не потерял доступ к данным. По паролю например - сменил пароль - данные потерялись.

К тому же для каждого менеджера надо будет хранить свою версию данных под разными ключами.

В общем сплошные костыли ради надежного шифрования получатся.
Как ниже написали надо определиться от чего защищаетесь. Делать шифрование ради шифрования смысла вообще нет, трудозатраты только сплошные.

Обычного шифрования по статичному ключу достаточно чтобы закрыть формально пункт по недержанию данных открытыми. Если вы не собираетесь вообще сертификацию проходить, то отдельно в шифровании нет никакого смысла. Т.е. нужно либо нормально делать, либо не заморачиваться если нет к этому предпосылок реальных.

Answer 2

[cicatrix]

Если "максимально безопасно" то, разумеется, шифровать.
Для поиска можно тупо повторить в соседнем поле в незашифрованном виде 4 цифры, которые получаете от банка.
И да, если "максимально безопасно", то каждая запись должна шифроваться своим ключом, который, разумеется, не должен лежать рядом с записью.

Вообще, это всё словоблудие: 100%-й безопасности не бывает. Определите сценарий угрозы - от чего именно вы хотите защититься, определите наиболее вероятные векторы атаки на ваши данные, постарайтесь закрыть хотя бы их. Безопасность - это КОМПЛЕКС мероприятий (начиная с того, насколько вы уверены в надёжности своих менеджеров/админов, что они не сольют базу злоумышленнику). Подкуп иногда бывает дешевле взлома.

Answer 3

[Сергей]

То что Вы собираете, можно классифицировать как персональные данные. Регулирует 152-ФЗ, по обработке есть свои требования, в частности использование сертифицированных средств защиты. Что в целом закрывает Ваш вопрос.

Могут и не поймать за подобное, фирм-то много, все не обойдут. Но открытая база пользователей с телефонами...))) Ну давайте так, она у вас 9 из 10 будет закрытая, от внешнего мира, но открытая для внутреннего доступа. е экселевский же файл вы будете генерить)