Если для того что-бы клиент смог создать правильный ключь ему необходима соль из базы данных, то по какому условию эта соль ему выдаётся? Я вижу два варианта:
Первый: соль выдаётся по имени аккаунта. В таком случае происходит довольно абсурдная ситуация, в которой любой знающий аккаунты может вытянуть все соли, и смысл изначально её использовать становится сомнительным.
Второй: она выдаётся по некому хэшу на основе только пароля. В таком случае непонятно, зачем вообще хранить хэш от соли рядом с хэшем без соли.

Здравствуйте, Caracrist, Вы писали:

C>Если для того что-бы клиент смог создать правильный ключь ему необходима соль из базы данных, то по какому условию эта соль ему выдаётся? Я вижу два варианта:
C>Первый: соль выдаётся по имени аккаунта. В таком случае происходит довольно абсурдная ситуация, в которой любой знающий аккаунты может вытянуть все соли, и смысл изначально её использовать становится сомнительным.
C>Второй: она выдаётся по некому хэшу на основе только пароля. В таком случае непонятно, зачем вообще хранить хэш от соли рядом с хэшем без соли.
Основное назначение соли — сделать бесполезными огромные базы посчитанных хэшей, по которым бессолевой пароль ломается крайне быстро + сделать так, чтобы у пользователей с одинаковыми паролями не было бы одинаковых хэшей (это если соль будет привязана к пользователю).
Соответственно:
1. Лучше чтобы соль была разной (или просто использовать логин)
2. Сама соль не является секретом, поэтому не страшно, если кто-то ее может получить (см. например, родную юниксовую функцию crypto)

Здравствуйте, DOOM, Вы писали:

DOO>Основное назначение соли — сделать бесполезными огромные базы посчитанных хэшей, по которым бессолевой пароль ломается крайне быстро + сделать так, чтобы у пользователей с одинаковыми паролями не было бы одинаковых хэшей (это если соль будет привязана к пользователю).
DOO>Соответственно:
DOO>1. Лучше чтобы соль была разной (или просто использовать логин)
DOO>2. Сама соль не является секретом, поэтому не страшно, если кто-то ее может получить (см. например, родную юниксовую функцию crypto)

спасибо, пока сделал так: соль своя у каждого акаунта и выдаётся по хэшу на пароль+логин.

Здравствуйте, Caracrist, Вы писали:

C> спасибо, пока сделал так: соль своя у каждого акаунта и выдаётся по хэшу на пароль+логин.

Я бы не стал так делать. Соль — это случайная величина, не надо делать ее зависимой от данных пользователя (а уж тем более от пароля).

Здравствуйте, Anton Batenev, Вы писали:

C>> спасибо, пока сделал так: соль своя у каждого акаунта и выдаётся по хэшу на пароль+логин.

AB>Я бы не стал так делать. Соль — это случайная величина, не надо делать ее зависимой от данных пользователя (а уж тем более от пароля).

Соль у меня случайная, она выдаётся по хэшу на пароль+логин. Дальше идёт стандартный процесс создания ключа из пароля+соль клиентом и логин с ним.

Здравствуйте, Caracrist, Вы писали:

C> C>> спасибо, пока сделал так: соль своя у каждого акаунта и выдаётся по хэшу на пароль+логин.
C> AB>Я бы не стал так делать. Соль — это случайная величина, не надо делать ее зависимой от данных пользователя (а уж тем более от пароля).
C> Соль у меня случайная, она выдаётся по хэшу на пароль+логин.

Или я чего-то не понимаю, или все же она не случайная. Т.е. рядом со словом "случайная" не должно стоять больше никаких условий — случайная величина ни от чего не зависит, "великий рандом". Пароль + логин — величина не случайная, хэш от неслучайной величины — так же не случайный, инициализация генератора "псевдослучайных" чисел неслучайной величиной — не случайная последовательность.

Здравствуйте, Anton Batenev, Вы писали:


AB>Или я чего-то не понимаю, или все же она не случайная. Т.е. рядом со словом "случайная" не должно стоять больше никаких условий — случайная величина ни от чего не зависит, "великий рандом". Пароль + логин — величина не случайная, хэш от неслучайной величины — так же не случайный, инициализация генератора "псевдослучайных" чисел неслучайной величиной — не случайная последовательность.

А как ты понимаешь слово "выдаётся"?
Если что, я имею ввиду: достаётся из базы данных.

Здравствуйте, Caracrist, Вы писали:

C>Соль у меня случайная, она выдаётся по хэшу на пароль+логин.

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

1) совсем без соли — можно заранее посчитать ключи на станжартные пароли для всех бах в мире
2) одна глобальная соль на всю базу — можно посчитать ключи один раз на пароли по всей базе
3) одна соль на логин — потребуется отдельная табличка засоленных стандартных паролей на каждый логин
4) одна соль на логин+пароль — ровно то же что и в предыдущем случае. при этом у тебя в базе хранится несколько солей на логин и на них хря тратится место

Здравствуйте, Caracrist, Вы писали:

C> Если для того что-бы клиент смог создать правильный ключь ему необходима соль из базы данных, то по какому условию эта соль ему выдаётся? Я вижу два варианта:
C> Первый: соль выдаётся по имени аккаунта. В таком случае происходит довольно абсурдная ситуация, в которой любой знающий аккаунты может вытянуть все соли, и смысл изначально её использовать становится сомнительным.
C> Второй: она выдаётся по некому хэшу на основе только пароля. В таком случае непонятно, зачем вообще хранить хэш от соли рядом с хэшем без соли.
Я обычно делаю как-то так:

salt := 8 randomly generated bytes.
hash := sha(concat(salt, passwordAsUtf8Bytes))
databaseField := bytesToHex(concat(salt, hash));

sha даёт 20 байт или 40 символов в hex. salt это 8 байт или 16 символов hex.
Т.е. в субд будет колонка размером 56 символов. В принципе обычно субд поддерживают запись массива байт, но с этим не так удобно работать, поэтому я обычно и храню в виде hex — читабельнее.
Потом обратный процесс: извлекаем строчку из базы, декодируем в массив 28 байт и проверяем, что хеш от первых восьми байт массива и введённого пароля побайтно совпадает с последними 20ю байтами массива.

Генерация случайной соли даёт дополнительную защиту, скрывающую факт, что пользователь при смене паролей использует старые.

Плюс, даёт гарантию, что мол, ВНЕЗАПНО не выяснится, что соль была выбрана неверно. Случайная соль — это 100% хорошая соль.

Здравствуйте, ·, Вы писали:

C>> Если для того что-бы клиент смог создать правильный ключь ему необходима соль из базы данных, то по какому условию эта соль ему выдаётся? Я вижу два варианта:
C>> Первый: соль выдаётся по имени аккаунта. В таком случае происходит довольно абсурдная ситуация, в которой любой знающий аккаунты может вытянуть все соли, и смысл изначально её использовать становится сомнительным.
C>> Второй: она выдаётся по некому хэшу на основе только пароля. В таком случае непонятно, зачем вообще хранить хэш от соли рядом с хэшем без соли.
Почему соль не сделать сеансовой?

Здравствуйте, pva, Вы писали:

C>>> Если для того что-бы клиент смог создать правильный ключь ему необходима соль из базы данных, то по какому условию эта соль ему выдаётся? Я вижу два варианта:
C>>> Первый: соль выдаётся по имени аккаунта. В таком случае происходит довольно абсурдная ситуация, в которой любой знающий аккаунты может вытянуть все соли, и смысл изначально её использовать становится сомнительным.
Вроде уже объяснили почему соль не является секретом. Но вроде ещё не объяснили, почему её нужно выбирать осторожно. Как мне кажется, что уже есть нагенерённые радужные таблицы для соли "admin", "test", "1" (id админа нередко именно такой).

C>>> Второй: она выдаётся по некому хэшу на основе только пароля. В таком случае непонятно, зачем вообще хранить хэш от соли рядом с хэшем без соли.
Хеш от соли — вещь бессмысленная. Хранят саму соль. Хеш без соли — хранить нельзя. Хранят хеш солёного пароля и соль.

pva>Почему соль не сделать сеансовой?
Это как? Если ты её не сохранишь в БД, то как ты потом пароль проверять-то будешь?

Здравствуйте, pva, Вы писали:

pva>Здравствуйте, ·, Вы писали:

C>>> Если для того что-бы клиент смог создать правильный ключь ему необходима соль из базы данных, то по какому условию эта соль ему выдаётся? Я вижу два варианта:
C>>> Первый: соль выдаётся по имени аккаунта. В таком случае происходит довольно абсурдная ситуация, в которой любой знающий аккаунты может вытянуть все соли, и смысл изначально её использовать становится сомнительным.
C>>> Второй: она выдаётся по некому хэшу на основе только пароля. В таком случае непонятно, зачем вообще хранить хэш от соли рядом с хэшем без соли.
pva>Почему соль не сделать сеансовой?
Собственно вот хорошая статья. Отвечает все на твои вопросы: https://crackstation.net/hashing-security.htm
Например: "The WRONG Way: Short Salt & Salt Reuse" (использование логина|id в качестве соли), "The WRONG Way: Double Hashing & Wacky Hash Functions" (это то что ты делаешь вычисляя соль из пароля).
И да, соль надо генерировать криптостойким генератором случайных чисел.
И "The salt needs to be unique per-user per-password". Какие такие сеансы?

Кстати, я сказал, что соль 8 байт, в статье говорят, что "As a rule of thumb, make your salt is at least as long as the hash function's output", а значит для sha1 надо 20 байт.

Здравствуйте, Caracrist, Вы писали:

C>Здравствуйте, Anton Batenev, Вы писали:


AB>>Или я чего-то не понимаю, или все же она не случайная. Т.е. рядом со словом "случайная" не должно стоять больше никаких условий — случайная величина ни от чего не зависит, "великий рандом". Пароль + логин — величина не случайная, хэш от неслучайной величины — так же не случайный, инициализация генератора "псевдослучайных" чисел неслучайной величиной — не случайная последовательность.

C>А как ты понимаешь слово "выдаётся"?
C>Если что, я имею ввиду: достаётся из базы данных.
Аааа... Похоже у тебя что-то намешано. Ты говоришь, что соль выдаётся из базы по хэшу на пароль+логин. Значит собственно "хэш на пароль+логин" у тебя в базе и хранится. Что и является плохо солёным хешем пароля. А то что у тебя "выдаётся" это наверное сессионный токен, причём тут соль

Здравствуйте, ·, Вы писали:

·>И "The salt needs to be unique per-user per-password". Какие такие сеансы?
Я рассматривал другой вектор атаки. По поводу сеансовой, предполагалось что работает как-то так
Client -> Server: хочу auth
Server -> Client: session salt
Client -> Server: (login, hash(salt, password))
Server -> Client: результат

А у вас, судя по всему, рассматривается случай когда тырят БД с сервера.

Здравствуйте, pva, Вы писали:

pva>·>И "The salt needs to be unique per-user per-password". Какие такие сеансы?
pva>Я рассматривал другой вектор атаки. По поводу сеансовой, предполагалось что работает как-то так
pva>Client -> Server: хочу auth
pva>Server -> Client: session salt
pva>Client -> Server: (login, hash(salt, password))
pva>Server -> Client: результат

pva>А у вас, судя по всему, рассматривается случай когда тырят БД с сервера.
Так это ты всех запутал, это не соль, а nonce. И вообще это https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication не надо ничего своего сочинять.

Здравствуйте, ·, Вы писали:

·>Так это ты всех запутал, это не соль, а nonce. И вообще это https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication не надо ничего своего сочинять.
Угу. У меня память короткая. В терминах путаюсь и стандартных протоколов не знаю.

Здравствуйте, ·, Вы писали:

·>Я обычно делаю как-то так:
А стандартных функций для HMAC в библиотеке нет? Потому что приведенный код — это кандидат на Length extension attack. При этом важно, какой именно sha используется. SHA-1 уязвим а вот SHA-3 — нет.

Здравствуйте, maxkar, Вы писали:

M>·>Я обычно делаю как-то так:
M>А стандартных функций для HMAC в библиотеке нет? Потому что приведенный код — это кандидат на Length extension attack. При этом важно, какой именно sha используется. SHA-1 уязвим а вот SHA-3 — нет.
Так это вроде только актуально для HMAC, а я писал о солёном хешировании паролей. Разве эта уязвимость может чем-то помочь при взломе паролей?

Здравствуйте, ·, Вы писали:


·>Потом обратный процесс: извлекаем строчку из базы, декодируем в массив 28 байт и проверяем, что хеш от первых восьми байт массива и введённого пароля побайтно совпадает с последними 20ю байтами массива.

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

Здравствуйте, ·, Вы писали:

pva>>Почему соль не сделать сеансовой?
·>Это как? Если ты её не сохранишь в БД, то как ты потом пароль проверять-то будешь?

Хранить можно и в отдельном файлике. Это даже лучше, т.к. если сольют базу то соль не узнают.

Здравствуйте, mottimatto, Вы писали:

M> Ну т.е. если ты знаешь что соль это первые N байт, то перебор паролей не отличается от поиска по базе хешей.
Отличается. Читаем статью в вики и описание правильной имплементации.

M>Хранить можно и в отдельном файлике.
Конечно можно. Но бессмысленно. Соль секретом не является.

M>Это даже лучше, т.к. если сольют базу то соль не узнают.
Строго хуже. Стойкости к взлому не добавляет, а лишние сложности создаёт.