Полное имя и базы данных

https://habr.com/ru/post/431866/

tl;dr; - если вам надо worldwide, то единственным правильным решением будет одно поле вида «сам напиши как там тебя звать». И nullable его.

Ох, какая хорошая статья. Спасибо. В догонку, как правильно солить пароли? Ну в смысле, хеш понятно храним (да не простой md5, а какой-нибудь посерьёзнее, пусть будет sha2), а не пароль, но вот смысл в хранении в базе ещё и соли к каждому паролю? Ведь по сути если базу спёр злой какер, то он и соль сопрёт, а соль + хеш, это считай нет никакой соли, а есть только хеш. Прост решил поиграться с более-менее реальным примером с БД, а то уровень по ним а-ля слепить ВКР в которой будет БД использоваться для хранения данных, ну то есть не серьёзный. Всякие задачки по SQL нормально решаются, но отсутствие реального опыта в проде с БД очень чувствуется.

Или это только защит qwerty паролей которые одинаковые у многих юзеров?

Таблица «Имя» с первичным ключом (user_id, n). Для каждого юзера по порядку (n) сохраняем лексемы. По необходимости добавляем внешние атрибуты в духе «тип (фамилия, второе имя)», «используется при письменном обращени с мая по сентябрь», и т.п.

Преномен, номен, когномен, агномен.

уникальная соль для каждого отдельного пароля - защита от радужных таблиц, чтобы нельзя было наперед накакультировать огромную таблицу хешей и потом легко искать по ней обратные значения по всевозможным значения паролей

Ну в смысле, хеш понятно храним (да не простой md5, а какой-нибудь посерьёзнее, пусть будет sha2),

это не суть важно. уже давно делают по десяткам тысяч итераций хеширования, так что выбор хеш-функции не особо чего-то значит. (но обычно выбирают ту, которая работает медленнее. ну и да, обязательно из серии «криптографических».)

т.е. берешь пороль, солишь, хешируешь. результат опять солишь, снова хешируешь. и так десятки тысяч раз.

смысл в том, чтобы как можно более затянуть вычисление хеша.

Или это только защит qwerty паролей которые одинаковые у многих юзеров?

это лишь положительный побочный эффект от соли.

и в реальной жизни никогда ничего не удаляют из таблиц.

вместо этого ставят фжалог deleted=True, и потом фильтруют по нему.

А имени и фамилии недостаточно?

Жители стран, где нет фамилий уже давно привыкли вписывать отчетсво в графу «фамилия». Мусульмане в графу фамилия пишут либо насаб, либо лакаб. У азиатов тоже традиционный расклад - имя+фамилия. Просто имя зачастую из двух слов состоит.

Хэшить специализированной для этого функцией, например, argon2i. Соль нужна для того, чтобы злоумышленник не мог воспользоваться радужными таблицами, так что хранить ее вместе с паролем — нормальная тема.

Базу можно не только посолить, но и поперчить. Соль в том, что перец хранится отдельно от овощебазы.

у нас в БД (граждане россии, ближнего зарубежья и чуть-чуть из дальнего) поле отчество было nullable
проблем не было: даже если приходил чувак со странностями в имени, то тупо брали его загранпаспорт и переписывали оттуда - там есть имя и фамилия латиницей

Я бы делал так, одно юникодное поле достаточной длины, где имяфамиляотчестваивсё остальное пишется как есть на языке оригинала (VARCHAR(65535) наверное хватит), и два поля латиницей, имя и фамилия, где латинизированное имя записывается в соответствии с какими-нибудь принятыми стандартами, например, как в загранпаспортах

У азиатов тоже традиционный расклад - имя+фамилия.

У японцев как раз фамилия + имя.

Самое длинное имя в мире:

Барнаби Мармадюк Алоизий Бенджи Кобвеб Дартаньян Эгберт Феликс Гаспар Гумберт Игнатий Джейден Каспер Лерой Максимилиан Недди Объяхулу Пепин Кьюллиам Розенкранц Секстон Тедди Апвуд Виватма Уэйленд Ксилон Ярдли Закари Усански

соль + хеш, это считай нет никакой соли, а есть только хеш

А откуда ему знать как именно соль применяется? Например, в хвосте или в начале? И это ещё самое простое.

в реальной жизни никогда ничего не удаляют из таблиц

К вопросу о всяких потешных «правах на забвение».

Преномен, номен, когномен, агномен.

Почти зиганул, но вовремя сдержался.

От перестановки слагаемых местами сумма не меняется.

Или, блин, японцы не разберутся какую часть вписать в поле «фамилия», а какую в поле «имя»?

Не, я тут про Явинские имена прочитал. Там и фамилии нет иногда, только имя.

а кто говорил про стирание данных из БД? может ещё на самих блочных девайсах shred 10 раз прогнать, чтоб уж точно?

со всех сторон оно выглядит как удаленным.

Обрабатываемые персональные данные подлежат уничтожению либо обезличиванию по достижении целей обработки или в случае утраты необходимости в достижении этих целей, если иное не предусмотрено федеральным законом»

значит фио можно перетереть в табличке профайлов и кое что ещё, а остальную активность оставить например. обезличено.

А стирать меж тем надо уметь... Иначе прознав про то, что ты deleted ставишь, но не удаляешь данные (а может принципиально не умеешь, так как у тебя запутано всё в таблицах), найдя уязвимость в системе тебя могут очень сильно наказать, залив в базу много-много всякого мусора, когда ты чухнешься у тебя база на весь диск может стать...

GDPR смотрит на тебя, как Грета Тунберг на членов ООН

Или это только защит qwerty паролей которые одинаковые у многих юзеров?

В общем-то да. Тех, кто упорно ставит паролем 12345 не спасёт ничто.

Правильная форма соли:

Hash = salt + sha256(salt + password)

Я видел как некоторые разделяли их чем-нибудь, вроде двоеточия, но это бессмысленно, т.к. выхлоп sha256 и так имеет фиксированную длину.

В настоящее время ручное соление уступает функциям формирования ключа (KDF). В ассортименте Argon2, PBKDF2 и т.д.

Просто уточнил фактическую неточность, нет повода заводиться. Правило строгое, поэтому поле в формах обычно одно: «имя» – очень удобно.

Да я и не завожусь :-) Да, одно поле - оптимальный выбор. Сам так делаю, по возможности. Но если прям очень надо несколько полей, то хватит двух.