Есть 500+ корпоративнх юзеров. Надо для них сгенерировать аккаунты и пароли и потом выслать юзерам.
Аккаунты есть, а вот пароли надо сгенерить. Как их сгенерить, чтобы были не очень сложны, чтоб не заблокировались сразу, но и не нельзя было подобрать?
Я в безопасности относительно слабоват и хотелось бы подетальней: какой алгоритм, какие правилы генерации паролей, может еще ЦУ?

Проект будет на .net core, но сам програмулину для генерации хотел написать либо на котлине или go.

1/ взять готовый от 1password (https://github.com/1Password/spg/tree/master) либо поискать готовые аналоги
2/ если хочется самому, учесть:
* попроще для запоминания: разбить на группы по 4-5 символов: Nbkl0-oZrY1-F7LPX
* еще проще для запоминания – чередовать гласные/согласные: jyjec-pabaq-bicib
* можно еще проще: использовать базу существительных-прилагательных, но плюс еще спецсимволы добавить
* если посложнее, то конечно минимум 8 символов, верхний/нижний регистр, цифры, спецсимволы
* по возможности использовать специализированные рандомайзеры
* менять seed чаще
* если seed будет на основе времени, то сделать рандомную задержку между генерациями

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

p> Есть 500+ корпоративнх юзеров. Надо для них сгенерировать аккаунты и пароли и потом выслать юзерам.
Такой подход сразу в топку. Хотя бы так:
Юзеру присылается уникальная ссылка на регистрацию акка. По ссылке юзер сам задаёт пароль.

·>Юзеру присылается уникальная ссылка на регистрацию акка. По ссылке юзер сам задаёт пароль.

Как я понял, это и есть временный пароль, который должен быть изменен, после первой аутентификации.
А ссылки нет, например потому, что нет веб-интерфейса.

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

M>·>Юзеру присылается уникальная ссылка на регистрацию акка. По ссылке юзер сам задаёт пароль.

M>Как я понял, это и есть временный пароль, который должен быть изменен, после первой аутентификации.
Я не так понял. Да и первый ответ в теме был вокруг рекомендаций "попроще для запоминания". Не надо одноразовые пароли запоминать.

M>А ссылки нет, например потому, что нет веб-интерфейса.
В наши дни такой веб-интерфейс делается за час, с перерывами на кофе попить.

Но можно просто одноразовый токен генерить, например случайные 32 бита и в base32 чтобы удобнее читать/вводить. Ещё можно немного бит добавить в качестве контрольной суммы.

И, конечно, временные пароли должны иметь TTL, в районе нескольких недель.

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

P>Есть 500+ корпоративнх юзеров. Надо для них сгенерировать аккаунты и пароли и потом выслать юзерам.
P>Аккаунты есть, а вот пароли надо сгенерить. Как их сгенерить, чтобы были не очень сложны, чтоб не заблокировались сразу, но и не нельзя было подобрать?

Пусть лучше они сами себе пароли придумают, а ты проверь, что эти пароли не совсем уж безумные.

Пароли, которые нагенеришь ты, пользователи не запомнят. Поэтому они напишут их на желтую бумажку и приклеят к монитору. Или в телеге будут хранить, в Saved Messages.

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

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

p>> Есть 500+ корпоративнх юзеров. Надо для них сгенерировать аккаунты и пароли и потом выслать юзерам.
·>Такой подход сразу в топку. Хотя бы так:
·>Юзеру присылается уникальная ссылка на регистрацию акка. По ссылке юзер сам задаёт пароль.

хороший вариант.
Алгоритм генерации ссылки посоветуете или просто в стековерфлоу топ рейт по данной теме?

единственный момент. Если юзер пришел после истечения TTL то ему через процедуру restore password пропускать?

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

P>·>Такой подход сразу в топку. Хотя бы так:
P>·>Юзеру присылается уникальная ссылка на регистрацию акка. По ссылке юзер сам задаёт пароль.
P>хороший вариант.
P>Алгоритм генерации ссылки посоветуете или просто в стековерфлоу топ рейт по данной теме?
Если в условиях корпорации, где кликают по ссылкам — просто сгенерить токен с инфой и подписью, чтобы stateless. Если широкая аудитория, то лучше небольшие легко вводимые коды и хранить остальное в бд.

P>единственный момент. Если юзер пришел после истечения TTL то ему через процедуру restore password пропускать?
Ну дык с этого бы и начинал. Раз есть уже restore password функциональность — просто устанавливай невалидный пароль (null какой-нибудь) и инициируй обыкновенный restore password.

DP>2/ если хочется самому, учесть:

Я бы в таком варианте рекомендовал подход из BIP39: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

Во-первых, там все готовое, во-вторых, более-менее доказанное.

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

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

P>>·>Такой подход сразу в топку. Хотя бы так:
P>>·>Юзеру присылается уникальная ссылка на регистрацию акка. По ссылке юзер сам задаёт пароль.
P>>хороший вариант.
P>>Алгоритм генерации ссылки посоветуете или просто в стековерфлоу топ рейт по данной теме?
·>Если в условиях корпорации, где кликают по ссылкам — просто сгенерить токен с инфой и подписью, чтобы stateless. Если широкая аудитория, то лучше небольшие легко вводимые коды и хранить остальное в бд.

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

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

P>·>Если в условиях корпорации, где кликают по ссылкам — просто сгенерить токен с инфой и подписью, чтобы stateless. Если широкая аудитория, то лучше небольшие легко вводимые коды и хранить остальное в бд.
P>корпорация.
P>в смысле в ссылке должны быть данные о юзере? или просто любой токен сгенерить, в базу положить
В случае если тупо будут тыкать ссылку, то база не нужна. В ссылку можно зашить всю инфу вместе с криптографической защитой. Разница лишь в том, что токен обычно большой блок base64, т.к. в нём все данные лежат, такое только кликнуть можно. А код — мелкий, т.к. там нет данных, они в базе, зато легко ввести вручную.

P>и потом реализовать механизм проверки что такой токен есть и он валидный?
Ну да. В базе лежат данные об аккаунте и ttl.

P>и я так понимаю лучше сделать одноразовый токен? типа если даже TTL не закончился, то второй раз уже невалидный и отсылаем на Restore
Я до сих пор не понимаю, почему сразу на Restore не послать-то, раз у тебя оно уже есть?

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

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

P>>·>Если в условиях корпорации, где кликают по ссылкам — просто сгенерить токен с инфой и подписью, чтобы stateless. Если широкая аудитория, то лучше небольшие легко вводимые коды и хранить остальное в бд.
P>>корпорация.
P>>в смысле в ссылке должны быть данные о юзере? или просто любой токен сгенерить, в базу положить
·>В случае если тупо будут тыкать ссылку, то база не нужна. В ссылку можно зашить всю инфу вместе с криптографической защитой.

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

·> Разница лишь в том, что токен обычно большой блок base64, т.к. в нём все данные лежат, такое только кликнуть можно. А код — мелкий, т.к. там нет данных, они в базе, зато легко ввести вручную.

тут не понял. Если несложно поясните подробнее пожалуйста



P>>и я так понимаю лучше сделать одноразовый токен? типа если даже TTL не закончился, то второй раз уже невалидный и отсылаем на Restore
·>Я до сих пор не понимаю, почему сразу на Restore не послать-то, раз у тебя оно уже есть?

а вариант, я просто такую практику не встречал. тогда тут в принципе уникальная ссылка не нужна, просто ссылка на страницу Restore?

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

P>·>В случае если тупо будут тыкать ссылку, то база не нужна. В ссылку можно зашить всю инфу вместе с криптографической защитой.
P>то есть когда длинная ссылка с токеном там внутри зашито на какой логин выдана ссылка
Ну да.

P>и потом надо еще сопоставить, что юзер не использует чужую ссылку?
Это как? Будет аналогично тому, что юзер не использует чужой пароль.

P>·> Разница лишь в том, что токен обычно большой блок base64, т.к. в нём все данные лежат, такое только кликнуть можно. А код — мелкий, т.к. там нет данных, они в базе, зато легко ввести вручную.
P>тут не понял. Если несложно поясните подробнее пожалуйста
ссылка с токеном будет выглядеть как-то так:
https://service/register?user=vasya&ttl=20250504T102345&signature=LonGBase64Block_jhj908235Koipo29Hpd93jJKx
На сервере обработка простая — достаём user и ttl и проверяем подпись. Подпись верна — ссылка валидна, человек может задать свой пароль.

ссылка с кодом валидации как-то так
https://service/register?code=JP8Q-4RQD
Сервер должен хранить у себя таблицу выданных кодов и искать там user и ttl. Запись найдена — код валиден, человек может задать свой пароль.
Даже можно сделать если человек пошел на https://service/ показать "вы новый пользователь? Введите код тут: [___]" — человек вводит 8 букв и готово.

P>>>и я так понимаю лучше сделать одноразовый токен? типа если даже TTL не закончился, то второй раз уже невалидный и отсылаем на Restore
P>·>Я до сих пор не понимаю, почему сразу на Restore не послать-то, раз у тебя оно уже есть?
P>а вариант, я просто такую практику не встречал. тогда тут в принципе уникальная ссылка не нужна, просто ссылка на страницу Restore?
Ссылка на страницу restore это и есть уникальная ссылка, которая тебе письмом приходит "кликните тут чтобы задать новый пароль"...

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

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



P>>и потом надо еще сопоставить, что юзер не использует чужую ссылку?
·>Это как? Будет аналогично тому, что юзер не использует чужой пароль.

Васе отправили ссылку 123, Пете 456.
Каким-то образом Петя открыл ссылку 123 и хочет активировать свой аккаунт. Что тут должно быть: ошибка что не свою ссылку или разрешать?

P>>·> Разница лишь в том, что токен обычно большой блок base64, т.к. в нём все данные лежат, такое только кликнуть можно. А код — мелкий, т.к. там нет данных, они в базе, зато легко ввести вручную.
P>>тут не понял. Если несложно поясните подробнее пожалуйста
·>ссылка с токеном будет выглядеть как-то так:
·>https://service/register?user=vasya&ttl=20250504T102345&signature=LonGBase64Block_jhj908235Koipo29Hpd93jJKx
·>На сервере обработка простая — достаём user и ttl и проверяем подпись. Подпись верна — ссылка валидна, человек может задать свой пароль.

а так отсылают ссылки сейчас? просто думал так небезопасно и уже не делают в открытом тексте.

·>ссылка с кодом валидации как-то так
·>https://service/register?code=JP8Q-4RQD
·>Сервер должен хранить у себя таблицу выданных кодов и искать там user и ttl. Запись найдена — код валиден, человек может задать свой пароль.
·>Даже можно сделать если человек пошел на https://service/ показать "вы новый пользователь? Введите код тут: [___]" — человек вводит 8 букв и готово.

ага, понял тут. Спасибо

P>>>>и я так понимаю лучше сделать одноразовый токен? типа если даже TTL не закончился, то второй раз уже невалидный и отсылаем на Restore
P>>·>Я до сих пор не понимаю, почему сразу на Restore не послать-то, раз у тебя оно уже есть?
P>>а вариант, я просто такую практику не встречал. тогда тут в принципе уникальная ссылка не нужна, просто ссылка на страницу Restore?
·>Ссылка на страницу restore это и есть уникальная ссылка, которая тебе письмом приходит "кликните тут чтобы задать новый пароль"...

я тут имел ввиду что если идти по этому алгоритму то юзерам надо отправить ссылку
с кодом https://service/restore?code=JP8Q-4RQD чтобы не было лишних юзеров
или просто https://service/restore и юзер там сам через свой логин\почту себе пароль получает ?

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

p> ·>Это как? Будет аналогично тому, что юзер не использует чужой пароль.
p> Васе отправили ссылку 123, Пете 456.
p> Каким-то образом Петя открыл ссылку 123 и хочет активировать свой аккаунт. Что тут должно быть: ошибка что не свою ссылку или разрешать?
Неверный вопрос. Ты должен рассуждать со стороны сервера. Вот серверу пришел запрос "с ссылкой 123" (или "с паролем 5up3r_53cr3t") — как сервер узнает, Петя нажал ссылку (или ввёл пароль) или Вася?

Тебе надо определиться как ты будешь идентифицировать пользователя при создании пароля для аутентификации.

p> P>>тут не понял. Если несложно поясните подробнее пожалуйста
p> ·>ссылка с токеном будет выглядеть как-то так:
p> ·>https://service/register?user=vasya&ttl=20250504T102345&signature=LonGBase64Block_jhj908235Koipo29Hpd93jJKx
p> ·>На сервере обработка простая — достаём user и ttl и проверяем подпись. Подпись верна — ссылка валидна, человек может задать свой пароль.
p> а так отсылают ссылки сейчас? просто думал так небезопасно и уже не делают в открытом тексте.
Ты тут выше собрался пароли открытым текстом слать. Я не понимаю чего ты хочешь.

Ссылка — это по сути одноразовый пароль, который просто вводить не надо, а достаточно кликнуть.

p> ·>Ссылка на страницу restore это и есть уникальная ссылка, которая тебе письмом приходит "кликните тут чтобы задать новый пароль"...
p> я тут имел ввиду что если идти по этому алгоритму то юзерам надо отправить ссылку
p> с кодом https://service/restore?code=JP8Q-4RQD чтобы не было лишних юзеров
Я не понял, что за лишние юзеры.

p> или просто https://service/restore и юзер там сам через свой логин\почту себе пароль получает ?
Что значит "пароль получает"? Пароль не получают, а создают. Т.е. юзер сам должен придумать и ввести пароль, который нигде в открытом виде не появляется, а тут же солится и хешируется.