Pull to refresh

Comments 7

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

Да и остальное - вариативно.

Я когда подобным развлекался, ставил на выбор отдельно строчные/прописные, кириллица/латиница, цифры, спецсимволы, отдельная строка для индивидуальной последовательности спецсимволов.

А когда-то давно, какой-то сайт не принимал пароли, потому, что там подряд шли строчные, цифры - а им хотелось, что бы подряд одинаковые субтипы не стояли. Типа "ММегаППППароль" - так нельзя, хотят: "МеГ@ПаР0лЬ"

Я 5 лет назад, при создании аналогичного генератора пароля на языке SourcePawn, делал ещё проверку, чтобы не было двух букв в одном регистре и двух цифр подряд.

static const char
	SYMBOL[] = "abcdefghijklmnopqrstuvwxyz0123456789'+-=@_ABCDEFGHIJKLMNOPQRSTUVWXYZ",

...

	int i, j, k;
	while(i < iSize[client])
	{
		while(k == j || (k < 26 && j < 26) || (k > 25 && k < 36 && j > 25 && j < 36) || (k > 41 && j > 41))
			k = GetRandomInt(0, 67);
		sPass[1][client][i++] = SYMBOL[k];
		j = k;
	}
	sPass[1][client][i] = 0;

где iSize[client] – целочисленная переменная, хранящая необходимую длину пароля, заданную игроком;
а sPass[1][client] – строковая переменная, куда будет сохранён сгенерированый пароль (в последней строке предоставленного кода завершается строка, т.к. у нас используются нуль-терминированные строки).

...проверку, чтобы не было двух букв в одном регистре и двух цифр подряд.

Разве подобное условие не делает наш пароль более предсказуемым? Условно, если мы подбираем пароль то можем существенно сократить количество вариантов с таким условием, и соответственно его сложность сильно пострадает.

Для подбора давалось от 1 до 10 попыток (зависит от настроек), после чего был кик или бан по IP на срок до получаса. Ну а минимальная длина выставлялась от 5 до 63 символов (пользователь мог выбрать любую длину, но минимальную планку нового пароля задавал сервер). Ну и время на ввод можно было ограничить макисимум до 3 минут (можно меньше или вообще выключить это ограничение), после чего опять таки кик или бан IP.

Так что криптостойкость была вполне себе достаточной, кмк.

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

Я в БД пароли в открытом виде хранил, потому что сама БД ничем наружу не торчала (и вообще была SQLite).
Это было для серваков CS:S v34 (ну и прочих NoSteam), когда развелось спуферов SteamID для пиратки. Т.е. выкачивать БД всё равно ради такого мамкины хакиры не стали бы.

for i in 0..long{

Такое чувство, что код был написан на С, потом превращен в Rust автоматически.

for c in password.chars() {
  if c.is_ascii_digit() { digits += 1; }
}

А ещё лучше

let digits = password.chars().filter(char::is_ascii_digit).count();

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

Sign up to leave a comment.

Articles