Чому майже немає веб-сторінок хеш-паролів у клієнта перед тим, як надсилати (і знову їх розміщувати на сервері), як «захистити» від повторного використання пароля?

46

В Інтернеті існує багато сайтів, які потребують інформації для входу, і єдиний спосіб захисту від повторного використання пароля - це "обіцянка", що паролі хешируються на сервері, що не завжди відповідає дійсності.

Тож мені цікаво, як важко зробити веб-сторінку, яка хешить паролі на клієнтському комп'ютері (з Javascript), перш ніж надсилати їх на сервер, де вони будуть повторно хешировані? Теоретично це не дає додаткової безпеки, але на практиці це можна використовувати для захисту від "шахрайських сайтів", які не хешують ваш пароль на сервері.

— Мартін Фіксман
джерело

18

хешований пароль, надісланий у поле очищення, не є кращим, ніж пароль, надісланий у відкритому доступі, якщо сервер просто порівнює хеші, людина в середині атак любить такий тип "безпеки"

3

Найкраще рішення - (imo) менеджер паролів на стороні клієнта. Таким чином, ви можете створити випадковий рядок символів як свій пароль, і ви не покладаєтесь на сервер, щоб "захистити" вас.

— Дін Хардінг

2

@Jarrod - мені це здається, як і різні веб-сайти, що використовують різні алгоритми хешування на стороні клієнта, запобігли б атаці, описаній у цьому коміксі. Один широко використовуваний пароль стає безліччю різних паролів через різні алгоритми хешу. Цей хеш-розрахунок на стороні клієнта не заважає застосовувати інші види захисту - наприклад, надсилання хеша через захищене з'єднання.

— Стів314

2

@ Steve314 моя думка, що все, що стосується клієнта, за замовчуванням порушено. Ви можете хеш-хеш-хеш, якщо це робиться на клієнті і передається туди-сюди на сервер, clearце лише математична мастурбація. Мені довелося виправити успадковану мені систему, яка була розроблена саме так, як ви і ОП описуєте, її постійно підлаштовували підлітки з Wireshark. Ми це заблокували лише тоді, коли ми ввели REALшифрування, зашифрували та підписали всі корисні навантаження на сервер і з нього, маніпуляція з обліковим записом припинилася і після цього більше ніколи не повторювалася.

5

Схоже, ваш план захисту себе від шахрайських сайтів - попросити сайтів-шахраїв встановити кращу безпеку. ?

— pc1oad1etter

46

Чому його не використовують? Тому що це багато додаткової роботи для нульового підсилення. Така система не була б більш безпечною. Це може бути навіть менш захищеним, оскільки створює помилкове враження, що він є більш захищеним, що змушує користувачів застосовувати менш безпечні практики (наприклад, повторне використання паролів, паролі словника тощо).

— Рейн Генріхс
джерело

2

Це найкраща відповідь поки що.

1

Це як шифрування Blu-Ray та DVD. Для розблокування навіть не потрібен ключ. Єдиний «захист», який він надав, - це те, що коли DVD-диски вперше вийшли, коштувати дорожче придбати диск для його копіювання, ніж придбати повну копію фільму. Звичайно, зараз ви можете придбати DVD за долар, а ще більше - той факт, що ключі зараз є загальнодоступними знаннями. Те саме відбувається з Blu-Ray

— Майкл Браун

2

Я думаю, що хешування паролем на стороні клієнта додає безпеку. Якщо я слухаю, я бачу лише ваш хеш, а не ваш пароль. Якщо сервер надсилає виклик (як слід), хеш навіть не використовується повторно.

— Андомар

2

Я думаю, що підхід x4u може бути цілком доречним для деяких програм, де вимоги безпеки знаходяться десь між передачею паролів на дроті та використанням сертифікатів. Я думаю, що хтось із наймовних прихильників не помічає, що хешування пароля перед тим, як він вийде на провід, виконується на додаток до стандартної обробки серверів з використанням облікових даних. Отже, питання таке: чи покращує пропозиція x4u безпеку в сценарії передачі пароля по проводу чи ні. Я кажу, що так і є. Ключове значення для цього полягає у використанні солей для пароля.

— ЛОС

6

Правильний спосіб запобігти атакам MITM - це шифрування в кінці. TLS (https) існує: використовуйте його. Не вигадуйте власні криптовалюти.

— Рейн Генріхс

14

Теоретично це не дає додаткової безпеки, але на практиці це можна використовувати для захисту від "шахрайських сайтів", які не хешують ваш пароль на сервері.

Як саме це захищає вас? Це здається, що все, що ви хочете зробити, - це хеш-хеш-пароль, який є якоюсь безглуздою. Тому що хешований пароль стане потім паролем.

В Інтернеті існує багато сайтів, які потребують інформації для входу, і єдиний спосіб захисту від повторного використання пароля - це "обіцянка", що паролі хешируються на сервері, що не завжди відповідає дійсності.

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

Якщо ви використовували javascript, все, що "хакер" повинен був зробити, це використовувати один і той же метод для хеш-хеш-паролів. Після того, як ви отримаєте хешовану інформацію, для обчислення пароля -> того самого хеша в базі даних потрібен час, який є фактором, що перешкоджає доступу до облікового запису.

— Рамхаунд
джерело

1

Якщо ваш браузер завжди хеширует його однаково, то так, ваш хеш може використовуватися як пароль у будь-якому іншому місці. Але що робити, якщо браузери призначили сіль на основі сайту (можливо, домену?) Перед хешированием і відправленням на сайт? Я думаю, що це цікава ідея.

— Тессерекс

2

якщо це стосується клієнта, це компрометується, будь-яка сіль для клієнта очевидно, це нелогічне питання. якщо ви не розумієте відповідь @ Ramhound, ви не повинні писати код, який потрібно захистити, і почніть читати про безпеку та криптографію з самого початку.

3

Коли ви цитуєте оригінальний плакат, будь ласка, відформатуйте текст як такий (виберіть текст та скористайтеся піктограмою цитати безпосередньо над редактором)

— Marjan Venema

1

Jarrod, будь ласка, дотримуйся власних порад і поінформуйся про себе, перш ніж робити смішні претензії. Людина, що знаходиться в середині нападу, марна проти безпечних хеш-функцій з розумною довжиною солі. І моя пропозиція жодним чином не є "безпекою від неясності", вона фактично є безпечною, виходячи з того, що в даний час відомо і прийнято фахівцями в цій галузі, і воно використовується таким же чином у багатьох протоколах. Це не мій винахід, я просто застосував добре зрозумілу процедуру до входу на веб-сайт. Ваші помилкові припущення не отримують жодної речовини завдяки тому, що їх, очевидно, поділяють і багато інших.

— x4u

3

Якщо сіль відома клієнтом і вона надсилається з сервера в чистому режимі, це знає і все, що знаходиться в середині. Ніколи не говорив, мені потрібно було скасувати хеш, якщо ви знаєте сіль на клієнті, то це не захищено.

11

Тому що це мало додасть ніякої цінності. Причина хешування полягає в тому, що якщо ваша база даних буде зламана, хакер не матиме список дійсних паролів, а просто хеши. Тому вони не змогли видати себе за жодного користувача. Ваша система не знає пароль.

Безпечний походить із SSL-сертифікатів плюс певної форми аутентифікації. Я хочу, щоб мої користувачі ввели пароль, щоб я міг обчислити хеш з нього.

Також алгоритм хешування був би на сервері в більш захищеній області. Помістивши його на клієнта, отримати вихідний код Javascript досить просто, навіть якщо його приховані посилання на файли сценаріїв.

— Джон Рейнор
джерело

3

Це найкраща відповідь. Вам слід зашифрувати на транспортному шарі. Не роблячи цього, решта не захищена. Так, ви можете написати функцію шифрування ... але ця функція була б видимою для (зловмисних) кінцевих користувачів. Використовуйте SSL.

— pc1oad1etter

Захищеність алгоритму хешування не повинна залежати від секретності. Алгоритми хешування для безпеки повинні бути односторонніми функціями: навіть якщо у вас є код, важко його скасувати. Навпаки, слід використовувати відому хеш-бібліотеку, розроблену саме для паролів. Якщо це не добре відомо, це майже напевно баггі або неправильно.

— leewz

6

Рішення простіше, ніж це. Клієнтські сертифікати. Я створюю на своєму комп'ютері сертифікат клієнта. Коли я реєструюсь на веб-сайті, ми робимо рукостискання, використовуючи мій клієнтський сертифікат та сертифікат сервера.

Ніякі паролі не обмінюються, і навіть якщо хтось зламає базу даних, все, що у них буде, - це відкритий ключ мого клієнтського сертифіката (який повинен бути засоленим і зашифрованим сервером для додаткового рівня безпеки).

Клієнтський сертифікат можна зберігати на смарт-картці (і завантажувати в захищений онлайн-сейф за допомогою головного пароля).

Краса всього цього полягає в тому, що він знімає концепцію фішингу… Ви ніколи не вводите пароль на веб-сайт, ви просто рукостискаєте з цим веб-сайтом. Все, що вони отримують, - це ваш відкритий ключ, який є марним без приватного ключа. Єдина сприйнятливість - це зіткнення під час рукостискання, і це працювало б лише один раз на одному веб-сайті.

Microsoft намагалася забезпечити щось подібне у Windows за допомогою Cardspace і пізніше представила це як відкритий стандарт. OAuth дещо схожий, але він покладається на посередницьку "емісійну сторону". Інфокарти, з іншого боку, можуть видаватися самостійно. Це справжнє рішення проблеми з паролем ... видалення паролів взагалі.

Хоча OAuth - це крок у правильному напрямку.

— Майкл Браун
джерело

5

Хоча клієнтські сертифікати є розумним підходом для деяких випадків використання, вони не є те, що можна легко додати до входу на сайт. Вони вимагають великої співпраці з боку користувачів і залежать від того, наскільки захищений приватний ключ користувачів. Використання приватного ключа може бути безпечним або зручним, але не одночасно і обом.

— x4u

5

Більшість відповідей тут, здається, повністю пропускають точку зшивання пароля на стороні клієнта.

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

справа в тому, щоб захистити пароль користувача , який, як правило, набагато цінніший, ніж доступ до входу до окремих сайтів, оскільки більшість користувачів повторно використовуватимуть свій пароль для декількох сайтів (вони не повинні, але реальність полягає в тому, що вони не повинні відмовлятися від цього ).

ssl відмінно підходить для захисту від mitm-атак, але якщо на сервері порушено додаток для входу, ssl не захистить ваших користувачів. якщо хтось зловмисно отримав доступ до веб-сервера, він, ймовірно, зможе перехопити паролі в простому тексті, оскільки в більшості випадків паролі хешируються лише сценарієм на сервері. то зловмисник може спробувати ці паролі на інших (зазвичай більш цінних) сайтах, використовуючи подібні імена користувачів.

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

— хрусткий
джерело

2

Прийнята відповідь досить добре поділяє вашу думку. Незважаючи на те, що "більшість відповідей" не відповідає, і оскільки ваша відповідь насправді не надає великої цінності, немає сенсу в цьому питанні.

— Френк

це, мабуть, скоріше коментар, ніж відповідь (вибачення за те, що не з'ясував, як додати до прийнятої теми коментаря відповідь), і, хоча моя думка поділяється у прийнятій відповіді, це, мабуть, було недостатньо зрозумілим, оскільки відповіді на нього здаються чистити його ще. спасибі за відгук

— кричущий

@Frank прийнята відповідь межує з тим, що занадто довго не турбувати читання. укладається занадто багато деталей, як це можна здійснити, і до кінця перебирає переваги. Інша відповідь на TL; DR - корисна.

— Жуль

2

@Jules: Тому редагування існує.

— Роберт Харві

1

@JarrodRoberson Я думаю, ви не плутаєте більше безпечного з незахищеним ? Якщо MITM трапляється, доступ до сайту вже припинено, чи не так? Якщо ви не використовуєте клієнтський сертифікат замість пароля, який був би надмірно складним для звичайних користувачів. Як я це бачу, хешування на стороні клієнта запобігає порушенню того ж пароля на інших сайтах, припускаючи, що кожен алгоритм хешування є унікальним. Це може бути не більш безпечним, але і не менш захищеним? То чому ти так сильно тиснеш на це? Я натрапив на це з мета, і це найкраща відповідь, яку я бачу досі.

— zypA13510

1

Це, безумовно, можливо, і насправді вам не потрібно чекати веб-сайту.

Погляньте на SuperGenPass . Це закладка.

Він просто розпізнає поля паролів, поєднує те, що ви вводите з доменом веб-сайту, хешує його, дещо маніпулює ним, щоб отримати лише "допущені" символи в паролі, і тільки потім ваш хеш-пароль надсилається по дроту.

Використовуючи домен сайту в процесі, ви отримуєте таким чином унікальний пароль на кожен сайт, навіть якщо ви завжди використовуєте той самий пароль.

Це не надзвичайно безпечно (base64-MD5), але ви прекрасно розповсюджуєте реалізацію на основі ша-2, якщо хочете.

Єдиним недоліком є те, якщо зміна домену, і в цьому випадку вам потрібно буде попросити веб-сайт скинути пароль, оскільки ви не зможете відновити його самостійно ... Однак це трапляється не часто, тому я вважаю це прийнятний компроміс.

— Матьє М.
джерело

Це я думав, читаючи питання; Це практично марно для сайтів робити власне хешування на стороні клієнта, але розширення для браузера, яке робить це (використовуючи деяку сіль на основі домену), фактично зведе нанівець ризики, пов'язані з повторним використанням пароля. Звичайно, найцікавіша частина настає, коли ви намагаєтесь увійти з іншої машини ...

— Aaronaught

3

це вже не безпечно, ніж будь-яка інша схема, яка зберігає пароль чітко. Це робить пароль унікальним, але він все ще не зашифрований , але якщо у мене є сервер посередині, я можу просто захопити складний, але все-таки ясний пароль і використовувати його скільки завгодно, він не змінюється. Хеш - це не якась магічна куля, це навіть не шифрування, їх називають криптографічними хешами, але це не означає, що вони шифруються. Не має значення, чи є мій пароль passwordі чи SHA-256 passwordз трохию солі, яка відома клієнту, людина в середині вкладки може захопити його.

@Jarrod Roberson: ви, звичайно, можете використовувати пароль, але ви не можете використовувати його знову для моїх акаунтів, в чому справа. Тому, якщо один із веб-сайтів, на які я підключаюсь, вкрав його базу паролів, і він зберігав їх у відкритому доступі, то інші мої акаунти в безпеці.

— Матьє М.

@Aaronaught: саме там воно світить насправді. Оскільки надісланий пароль отриманий виключно з домену веб-сайту, на який ви входите, та основного пароля на ваш вибір, ви можете увійти з будь-якого комп’ютера (і браузера), поки у вас є закладка. Ось чому це дещо зручніше, ніж сертифікат.

— Матьє М.

6

@Jarrod: Це не заходи безпеки для сайту , це заходи безпеки для користувача . Якби всі користувалися такою схемою, повторне використання пароля не буде проблемою. Схема MITM може використовувати пароль хешеваного клієнта для отримання доступу до цього сайту, але лише до цього сайту. Ось тут і полягає поліпшення. Зазвичай ви очікуєте, що зможете отримати доступ до багатьох облікових записів, просто зламавши один пароль, оскільки цей пароль, ймовірно, буде повторно використаний; у цьому випадку зламаний пароль практично гарантовано є дійсним лише для сайту чи бази даних, в яких він був знайдений.

— Aaronaught

0

Мені подобається відповідь X4u, але, на мій погляд, щось подібне повинно бути інтегровано в браузер / специфікацію html - так як на даний момент це лише половина відповіді.

Ось проблема, яку я маю як користувач - я не маю уявлення, чи буде мій пароль хеширован на іншому кінці при зберіганні в базі даних. Рядки між мною і сервером цілком можуть бути зашифровані, але я поняття не маю, що станеться з моїм паролем, як тільки він досягне місця призначення - він може зберігатися як звичайний текст. Хлопець адміністратора бази даних може продати базу даних, і перш ніж ви дізнаєтесь про це, весь світ знає ваш пароль.

Більшість користувачів повторно використовують паролі. Не технічні люди, тому що вони не знають нічого кращого. Технічні люди, тому що, як тільки ви дістанетесь до 15-го пароля або близько того, більшість людей не мають шансу запам'ятати їх, якщо вони не записують їх (Що ми всі знаємо, це також погана ідея).

Якщо Chrome чи IE або що-небудь це я використовую, могло б сказати мені, що поле пароля миттєво стане хешированим на стороні клієнта за допомогою солі, створеної сервером, і ефективно пісочниці самого пароля - тоді я б знав, що як користувач я можу повторно використовувати пароль з меншим ризиком. Я все ще хочу, щоб зашифровані канали, а також я не хочу, щоб під час передачі жодних карнизів не випадало.

Користувачеві необхідно знати, що їх пароль навіть недоступний для надсилання на сервер - лише хеш. В даний час навіть використовуючи рішення X4U, вони не мають можливості знати, що це так, тому що ви не знаєте, чи використовується ця технологія.

— Кріс Невілл
джерело

1

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

— gbjbaanb

-1

Я думаю, що це хороший метод використовувати при побудові чогось на зразок фреймворку, CMS, форуму програмного забезпечення тощо, де ви не контролюєте сервери, на яких це може бути встановлено. Тобто, ТАК, ви завжди повинні рекомендувати використовувати SSL для входу та активності входу в систему, але деякі сайти, що використовують ваш фреймворк / cms, не матимуть цього, тому вони все ще можуть скористатися цим.

Як зазначають інші, перевага тут полягає не в тому, що атака MITM не могла б дозволити комусь іншому ввійти на цей конкретний сайт як ви, а скоріше, що той зловмисник не зможе потім використовувати те саме комбінаційне ім'я користувача / пароль, щоб увійдіть, можливо, в десятки інших сайтів, на яких у вас можуть бути облікові записи.

Така схема повинна соліти або з випадковою сіллю, або з деяким комбінацією солей, що стосуються конкретного сайту та імені користувача, так що той, хто отримує пароль, не може використовувати його для того ж імені користувача на інших сайтах (навіть сайти, що використовують ідентичну схему хешування ), а також проти інших користувачів сайту, які можуть мати той самий пароль.

Інші пропонують користувачам створити унікальні паролі для кожного окремого веб-сайту або використовувати менеджери паролів. Хоча це теоретичні поради в теорії, ми всі знаємо, що в реальному світі можна покластися на це глупоту. Відсоток користувачів, які роблять будь-яку з цих речей, невеликий, і я сумніваюся, що незабаром це зміниться.

Отже, хеш-код паролів JavaScript - це щонайменше, що розробник фреймворку / cms може зробити, щоб обмежити шкоду тим, хто перехоплює паролі під час транзиту (що сьогодні легко через Wi-Fi-мережі), якщо власник сайту та кінцеві користувачі недбалі. про безпеку (яка вони, швидше за все, є).

— matthewv789
джерело