А почему соль называют солью, а не сахаром.

потому-что она "насолит" злоумышленнику, у него всё будет не в "сахаре")

помоему соль настолько насолила что уже 2-й день обсуждаем :)

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

И она, естественно, хранится вместе с хешом

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

это и есть почти "радужные таблицы"

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

на самом деле срач бы не в этом

просто я удивился что соль хранится рядом с паролем, а не в приложении

это и есть почти "радужные таблицы"

Нет

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

И соль одна на всех, ага

и пароли имеют чуть ли не по 255 символов длинну, хрен уже перебором походишь

Радужные это таблицы коллизий, уменьшающие количество вариантов

кто-то совершенно не понял смысл соли..

https://stackoverflow.com/questions/2999197/do-i-need-a-random-salt-once-per-password-or-only-once-per-database

Don't just rely on a site wide salt for example, as that defeats the point of using a salt in the first place.

на самом деле я читал этот подход около 7 лет назад (со статической солью) и это было инновационно

еще на md5

и пароли имеют чуть ли не по 255 символов длинну, хрен уже перебором походишь

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

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

мы говорим о случаи когда СДАМПИЛИ БАЗУ

через ' or 1=1

Коллега, не лезте в бутылку

короче ребята: 1. соль можно и нужно хранить рядом с паролем 2. соль нужно рандомного генерить для каждого пароля отдельно 3. соль защищает от rainbow table attack это всё что нужно знать

Одну срль на все пароли используют только имбецилы

Ну да, хэш для входа не поможет без обратного преобразования

короче ребята: 1. соль можно и нужно хранить рядом с паролем 2. соль нужно рандомного генерить для каждого пароля отдельно 3. соль защищает от rainbow table attack это всё что нужно знать

Та

короче ребята: 1. соль можно и нужно хранить рядом с паролем 2. соль нужно рандомного генерить для каждого пароля отдельно 3. соль защищает от rainbow table attack это всё что нужно знать

Не защищает. Заставляет на каждую соль готовить таблицу заново

Не защищает. Заставляет на каждую соль готовить таблицу заново

совершенно верно, тем самым "защищая" от нападения с радужной таблицей..

можно две соли держать, одну в аппке, вторую в бд ? Тогда защитим даже от атаки перебором для слабых паролей аля "хакер1997"

можно две соли держать, одну в аппке, вторую в бд ? Тогда защитим даже от атаки перебором для слабых паролей аля "хакер1997"

зачем?!

потому что в вашем варианте нет защиты от атаки по словарю

потому что в вашем варианте нет защиты от атаки по словарю

а нука поясни))

я легко переберу какие то несчасные 32 000 слов с вариациями

и мне ничего не помешает каждое присолить открытой солью

а потом сравнить хеши

для простых паролей вида "test" "123456"

можно две соли держать, одну в аппке, вторую в бд ? Тогда защитим даже от атаки перебором для слабых паролей аля "хакер1997"

security through obscurity? если взломали бд, то не взломали сервер? а вообще я считаю люди которые используют пароли типа "123456" - заслужили взлома

если же мы их посолим то пароли будут "test!@$(*@RU(u9J#*(R#FJ#*(FJ#(*FH#(*F#(HF(" уже хрен. Правда до тех пор пока "секретная" строка не раскрыта (что уже сложнее)

придется добраться до бинарника аппки

потом ковырнуть бинарник опционально зашированный поверх чем то

а у вас тут “интересно” сегодня)

ну... если оно вам надо то пожалуйста... я не стану защищать пользователей с паролем "123456"

90% пользователей идиоты

Хэш хэшем поверх другим и разными алгоритмами ))

я лучше при регистрации проверю пароль на сложность и предложу "подумать" о безопасности.. те кто не заботятся о своей безопасности - её не заслужили

я встречал таких вот проверяторов

я лучше при регистрации проверю пароль на сложность и предложу "подумать" о безопасности.. те кто не заботятся о своей безопасности - её не заслужили

Ну такое себе утверждение

совершенно секюрный пароль вида - 0MbeJnamfz4Bl7yY0MBXACz4y (25 символов) "ой блеать! что-то у вас он длинный. Не больше 10 символов"

а эту "глобальную соль" рано или поздно сольют.. и толку с неё мало

совершенно секюрный пароль вида - 0MbeJnamfz4Bl7yY0MBXACz4y (25 символов) "ой блеать! что-то у вас он длинный. Не больше 10 символов"

Лол,как ты такой пароль запомнишь?

Лол,как ты такой пароль запомнишь?

они хранятся в облаке ? Защищенные чем то поверх

они хранятся в облаке ? Защищенные чем то поверх

И запомнаються в куках?

Лол,как ты такой пароль запомнишь?

Может это имя бабушки.

нет

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

юзаю LastPass

это менеджер паролей, но облачный

с шифрованием

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

Менеджер паролей?А с чего ты взял что он абсолютно безопасен?

LastPass, кажется, пару раз ломали.

LastPass, кажется, пару раз ломали.

удачи им, там шифрование 2048 ключем

ERROR: S client not available

Менеджер паролей?А с чего ты взял что он абсолютно безопасен?

1. open source, пропритарной херне доверять нельзя 2. популярен, вероятность ошибок ниже 3. не в облаке, я понимаю что зашифрованный файлс с паролями в AES256 можно и на облако класть, но проблема в доступности, облако не 100% надёжно, порой бывает и сеть выбивает

астановитесь!

4. на каждый сервис иметь отдельный, рандомно сгенерированный пароль 5. регулярно менять пароли, в самом лучшем случае ежедневно (автоматиризованно естественно)

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

а для защиты от слива данных третьми лицами достаточно и хранилища паролей

удачи им, там шифрование 2048 ключем

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

там еще и клиентское шифрование

Один фиг если ты кому-то будешь нужен то найти способ не сложно

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

если речь о передачи по сети -> HTTPS если вы изначально не доверяете девайсу (keylogger) тогда вам ничего не поможет кроме как сменить девайс

еще раз, если за тебя взялись таким образом что стоит сниффер на тарифик/клавиатуру. Тебе надо не про защиту паролей от порнохаба думать, а об правильной упаковке чемодана ?

параноики от криптографии об этом забывают

еще раз, если за тебя взялись таким образом что стоит сниффер на тарифик/клавиатуру. Тебе надо не про защиту паролей от порнохаба думать, а об правильной упаковке чемодана ?

Этр слишком сложно, в рф с успехом применяется термо-ректальный анализатор паролей

короче ребята: 1. соль можно и нужно хранить рядом с паролем 2. соль нужно рандомного генерить для каждого пароля отдельно 3. соль защищает от rainbow table attack это всё что нужно знать

в той же таблице рядом хранить? ?

в той же таблице рядом хранить? ?

желательно в одной строке

аааа

понял

это не против слива таблицы

это против перебора по радужным таблицам

ещё рекомендую использовать bcrypt для шифрования паролей: https://godoc.org/golang.org/x/crypto/bcrypt

https://gowebexamples.com/password-hashing/

ещё рекомендую использовать bcrypt для шифрования паролей: https://godoc.org/golang.org/x/crypto/bcrypt

норм посоны юзают argon2

норм посоны юзают argon2

хмм, кстати я не слыхал ещё об argon2, спасибо за инфу https://crypto.stackexchange.com/questions/30785/password-hashing-security-of-argon2-versus-bcrypt-pbkdf2

Классно для аватарки чата :)

Согласен.

)

Согласен.

Женя? :D

М?

М?

Вездесущий Женя)

Ну да. )

Давно валяется у меня в непрочитаном https://cloudplatform.googleblog.com/2018/01/12-best-practices-for-user-account.html?m=1

https://medium.com/@vporoshok/%D1%87%D0%B8%D1%81%D1%82%D0%B0%D1%8F-%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0-%D0%BD%D0%B0-go-91ef3c31626c кто нибудь читал эту статью? почему автор считает что контроллер должен выполнять только одно действие, это мне что на кажддый чих свой контроллер создавать?