Когато искам да внедря система за влизане, винаги сравнявам MD5 на дадената парола с нейната стойност в таблицата с потребители от страна на сървъра.
Въпреки това, мой приятел ми каза, че "ясна" парола може да бъде надушена от мрежов софтуер.
Така че въпросът ми е: добра идея ли е да хеширате паролата от страна на клиента? По-добре ли е от хеширането от страната на сървъра?
По принцип вашият приятел е прав. Но простото хеширане на паролата от страна на клиента е просто по-добро от изпращането й като обикновен текст на сървъра. Някой, който може да слуша вашите пароли с обикновен текст, със сигурност също може да слуша хеширани пароли и сам да използва тези уловени хешове, за да се удостовери срещу вашия сървър.
По този въпрос по-сигурните протоколи за удостоверяване обикновено преминават през редица обръчи, за да се уверят, че такава повторна атака не може да работи, обикновено, като позволяват на клиента да избере куп произволни битове, които се хешират заедно с паролата , и също изпратени в чист вид на сървъра.
На сървъра:
На клиента:
Тъй като сървърът знае собствената си произволна информация, както и произволните битове на клиента (получи ги като ясен текст), той може да извърши по същество същата трансформация. Този протокол гарантира, че никой, който слуша в този разговор, не може да използва информацията по-късно, за да се удостовери фалшиво, като използва записаната информация (освен ако не е използван много слаб алгоритъм...), стига и двете страни да генерират различни "битове шум" всеки път, извършва се ръкостискане.
Редактиране Всичко това е податливо на грешки и е досадно и донякъде трудно за правилно (прочетете: сигурно). Ако някога е възможно, обмислете използването на реализации на протокол за удостоверяване, които вече са написани от знаещи хора (за разлика от мен! Горното е само по спомен за книга, която прочетох преди време.) Наистина не искате да пишете това сами обикновено.
Първо, това НЕ подобрява сигурността на вашето приложение (ако приемем, че е уеб приложение).
Използвайте SSL (или всъщност TLS, който обикновено се нарича SSL), всъщност не е скъп (измерете времето, което използвате, за да намерите начини да го заобиколите, и го умножете по минималната заплата, закупуването на сертификат печели почти винаги).
Причината за това е проста. TLS решава проблем (когато се използва с купени сертификати, а не самоподписани), който е доста голям в криптографията: Как да разбера, че сървърът, с който говоря, е сървърът, с който мисля, че говоря? TLS сертификатите са начин да се каже: „Аз, сертифициращият орган, доверен от вашия браузър, удостоверявам, че уебсайтът на [url] има този публичен ключ със съответния частен ключ, който (личен ключ) само сървърът знае, вижте Подписах се върху целия документ, ако някой го е променял, можете да видите".
Без TLS всяко криптиране става безсмислено, защото ако седя до вас в кафене, мога да накарам вашия лаптоп/смартфон да мисли, че аз съм сървърът, а MiTM (Man in The Middle) вас. С TLS вашият лаптоп/смартфон ще крещи „НЕДОВЕРЕНА ВРЪЗКА“, защото нямам сертификат, подписан от сертифициращ орган, който да съответства на вашия сайт. (Шифроване срещу удостоверяване).
Отказ от отговорност: потребителите са склонни да щракат точно през тези предупреждения: „Ненадеждна връзка? Какво? Искам само моите снимки на котенца! Добавяне на изключение Щракнете Потвърди Щракнете УРА! Котенца!“
Въпреки това, ако наистина не искате да закупите сертификат, все пак Въведете хеширане на javascript от страна на клиента (и използвайте standford библиотеката (SJCL) за това, НИКОГА НЕ ВНЕДРЯВАЙТЕ САМИ КРИПТО ).
Защо? Повторно използване на парола! Мога лесно да открадна сесийната ви бисквитка (която ми позволява да се преструвам пред вашия сървър, че съм вие) без HTTPS (вижте firesheep). Ако обаче добавите javascript към вашата страница за вход, който преди изпращане хешира паролата ви (използвайте SHA256 или дори по-добре използвайте SHA256, изпратете им публичен ключ, който сте генерирали, и след това шифровайте хеширана паролата с това, не можете да използвате сол с това) и след това изпраща хешираната/шифрована парола на сървъра. РЕХЕХАЙТЕ хеша на вашия сървър със сол и го сравнете с това, което се съхранява във вашата база данни (съхранявайте паролата така:
(SHA256(SHA256(password)+salt))
(запазете солта и като обикновен текст в базата данни)). И изпратете паролата си така:
RSA_With_Public_Key(SHA256(password))
и проверете паролата си така:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Защото, АКО някой надуши вашия клиент, той ще може да влезе като ваш клиент (отвличане на сесия), но НИКОГА няма да види паролата в обикновен текст (освен ако не промени вашия javascript , обаче хакерът на Starbucks вероятно няма да знае как да/се интересува от това.) Така че те ще получат достъп до вашето уеб приложение, но не и до своя имейл/фейсбук/и т.н. (за което вашите потребители вероятно ще използват една и съща парола). (Имейл адресът или ще бъде тяхното име за вход, или ще бъде намерен в техния профил/настройки на вашето уеб приложение).
Вероятно е добре да не се тревожите за това - както Дирк споменава, дори ако хеширате паролите, злонамерен потребител може да е в мрежа и да види изпращането на хеша и може просто да изпрати същия хеш.
Това е малко по-добро, тъй като не позволява на злонамерения потребител да разбере каква е паролата, но тъй като той все още може да влезе (или потенциално реконструирайте оригиналната парола), това не е толкова полезно.
Като цяло, ако сте загрижени за безопасността на паролите и данните на вашия потребител (и трябва да сте!), ще искате да използвате защитен SSL сървър. Ако това не ви притеснява по някаква причина, може и да не се занимавате с хеширане; това е просто сигурност чрез неизвестност.
Редактиране август 2014 г.: Google настоява все по-силно уебсайтовете да превключете към HTTPS навсякъде, тъй като защитата на самата комуникация е единственият начин за предотвратяване на атаки за подслушване на мрежата. Опитите за прикриване на предадените данни само ще попречат, но не и ще спрат, специализиран нападател и могат да дадат на разработчиците опасно фалшиво чувство за сигурност.
x потребител и достъпа до една услуга. Ако вземете предвид колективния ефект, бих казал, че е много по-добър; защото предотвратява изграждането на големи бази данни за търсене на пароли, използвани за груба сила на солени хешове в множество услуги. ИМО. Вижте какво прави AWS Cognito в клиента за справка.
- person f1lt3r; 06.09.2018
Всъщност не съм съгласен, че хеширането от страна на клиента е по-сигурно в този случай. Мисля, че е по-малко сигурно.
Целият смисъл на съхраняването на хеш на паролата във вашата база данни за разлика от истинската парола (или дори криптирана парола) е, че е математически невъзможно да се получи оригиналната парола от хеш (въпреки че теоретично е възможно да се получи сблъсък въвеждане на хеш, чиято трудност зависи от силата на сигурността на алгоритъма за хеширане). Възможният вектор на атака тук е, че ако потенциален нападател по някакъв начин компрометира вашата база данни за съхранение на пароли, той/тя все още няма да може да получи оригиналните пароли на вашите потребители.
Ако вашият механизъм за удостоверяване изпраща хеш на паролата, тогава в този сценарий за нарушаване на сигурността нападателят не трябва да знае истинската парола - те просто изпращат хеша, който имат, и хей, скоро, те имат достъп до акаунта на определен потребител, и като разширение, цялата ви система. Това напълно обезсмисля смисъла на съхраняването на хеширана парола на първо място!
Наистина сигурният начин да го направите е да изпратите на клиента еднократен публичен ключ, за да шифрова паролата, след което да я дешифрирате и хеширате отново от страна на сървъра.
Между другото, този тип въпроси вероятно ще получат повече експертни отговори в Security StackExchange.
Обърнете внимание, че защитата на паролите срещу трети страни не е всичко.
Веднага след като поверителността е намесена (и кога изобщо не е, в наши дни?), вие не искате да знаете паролата. Не можете да злоупотребявате или да издавате това, което нямате, така че и вие, и вашите клиенти можете да спите по-добре, ако никога не виждате паролите им в ясен текст.
Следователно хеширането/криптирането от страна на клиента има смисъл.
x потребители на n услуги, които криптират само на сървъра. Ако всяка услуга уникално хешира паролата, преди да напусне клиента, голямата база данни от пароли между услуги става много, много по-малка. Проверете трафика си за влизане в AWS, вижте какво правят. Това е вероятно, скъпи ми Уотсън.
- person f1lt3r; 06.09.2018
Зависи, можете да използвате хеширане от страна на клиента, но солта от страна на сървъра няма да е възможна.
погледнете връзката Криптиране на парола от страна на клиента
Наскоро GitHub и Twitter обявиха, че паролите се съхраняват във вътрешни регистрационни файлове. Случвало ми се е това по невнимание в доклади за грешки и други регистрационни файлове, които са попаднали в splunk и т.н. За twitter, ако паролата на Тръмп беше там, може да е голяма работа за администратора да „види“, за други сайтове вероятно не като голяма работа, тъй като администраторите няма да имат голяма полза от него. Независимо от това, че като администратори не ни харесва да виждаме паролите, нали.
Така че въпросът наистина е дали хеширането трябва да се случи от страна на клиента за сигурност, но как можем да защитим паролата, преди тя в крайна сметка да бъде хеширана и сравнена от страната на сървъра, така че да не бъде регистрирана по някакъв начин.
Шифроването не е лоша идея, защото разработчиците поне трябва да прескочат някои обръчи и ако откриете, че паролите са попаднали в регистрационни файлове, можете просто да промените ключа за криптиране, да унищожите оригинала и тези данни стават безполезни. Още по-добре завъртете ключовете всяка нощ и това може значително да намали прозорците.
Можете също да хеширате хеш във вашия потребителски запис. Изтеклите пароли ще бъдат хеширани пароли с обикновен текст. Сървърът ще съхранява хеширана версия на хеша. Разбира се, хешът става парола, но освен ако нямате фотографска памет, няма да запомните bcyrpt от 60 символа. Сол с потребителското име. Ако можете да съберете нещо за потребителя по време на процеса на влизане (без да излагате, че потребителският запис съществува), можете да добавите и това, като създадете по-стабилен хеш, който не може да бъде споделен между сайтове. Никой човек по средата не би могъл просто да изреже и постави уловения хеш между сайтовете.
Комбинирайте с бисквитка, която не се изпраща обратно на сървъра и може да се окажете на нещо. При първа заявка изпратете бисквитка на клиента с ключ, след което се уверете, че бисквитката не се връща обратно към услугата за влизане, така че шансът да бъде регистрирана е малък. Съхранявайте ключа в хранилище за сесии и след това го изтрийте веднага след влизане или когато сесията изтече... това изисква състояние за вас, момчета от JWT, но може би просто използвайте nosql услуга за това.
Така надолу по пътя администратор попада на една от тези хеширани и криптирани пароли в splunk или инструмент за докладване на грешки. Би трябвало да е безполезно за тях, тъй като вече не могат да намерят ключа за шифроване, а дори и да го намерят, тогава трябва да извършат грубо хеширане. Освен това крайният потребител не е изпратил нищо в обикновен текст по линията, така че на всеки човек по средата най-малкото му е по-трудно и не можете просто да отидете на друг сайт и да влезете.
Напоследък работя много по това, IRL има два проблема с хеширане / симетрично криптиране от страна на клиента, което наистина убива идеята: 1. Трябва да върнете солта обратно на сървъра НЯКАК... и за да го шифровате от страна на клиента, ще ви трябва парола... което проваля целта. 2. Разкривате своето хеширане (не е ГОЛЯМА сделка, тъй като повечето сайтове използват един от 3 или 4 алгоритма за хеширане), което прави атаката по-лесна (тъй като просто трябва да опитате един, а не n).
Това, към което в крайна сметка отидох, беше асиметрично криптиране на клиента, използвайки OpenPGP.js или подобен... Това разчита на импортиран или генериран от страна на клиента ключ на клиента и сървъра, изпращащ своя публичен ключ. Само публичният ключ на клиента може да бъде изпратен обратно на сървъра. Това предпазва от MIM атаки и е толкова сигурно, колкото и устройството (в момента съхранявам частния ключ на клиента по подразбиране в localStore, това е демонстрация).
ОСНОВНОТО предимство на това е, че никога не се налага потребителски данни да се съхраняват / дори в паметта некриптирани на моя сървър / хранилище за данни (и личният ключ на моя сървър е физически отделен)
Основата на това беше да се предостави на хората начин за сигурна комуникация там, където HTTPS е ограничен (напр. Иран / Северна Корея и др.), а също и просто забавен експеримент.
Далеч не съм първият, който се сеща за това, http://www.mailvelope.com/ използва това
Ако някой може да види данните във и извън вашата връзка, тогава удостоверяването няма да ви спаси. Вместо това бих направил следното за супер секретни неща.
Паролите са предварително хеширани от страна на клиента, преди да бъдат изпратени на сървъра. (Сървърът съхранява друга хеширана и осолена стойност на този хеш, изпратена от браузъра).
Така че атака на посредник може да им позволи да изпратят същата хеширана стойност за влизане като тях, но потребителската парола няма да бъде известна. Това ще ги спре да опитват други услуги със същите идентификационни данни, за да влязат другаде.
Потребителските данни са криптирани и от страна на браузъра.
А, така че атака на посредник би получила криптираните данни, но няма да може да ги дешифрира без действителната парола, използвана за влизане. (потребителска парола, съхранявана в DOM на браузъра, когато са влезли). Така че истинският потребител ще види дешифрираното съдържание, но посредникът не може. Това също означава, че която и да е NSA или друга агенция няма да може да поиска от вас/компанията/хостинг доставчика да дешифрира тези данни, тъй като за тях също би било невъзможно да направят това.
Някои малки примери и за двата метода са в моя блог http://glynrob.com/javascript/client-side-hashing-and-encryption/
Тази идея за хеширане от страна на клиента е да защити потребителя, а не вашия сайт. Както вече споменахме много пъти, обикновеният текст или хешираните пароли имат еднакъв достъп до вашия сайт. Не получавате облага за сигурност.
Но действителната, обикновен текст, парола на вашите потребители трябва да се знае само от тях. Да знаете какво са избрали като парола е информация, която може да се използва срещу тях в други сайтове и системи. Вие сте сайт, фокусиран върху клиентите, като ги предпазвате от откриване на избора им на парола от разработчиците на вашия сървър или от трети страни.
Помислете за това: -
Клиентът изпраща заявка до сървъра „Имам парола за проверка“.
Сървърът изпраща на клиента само еднократен произволен низ. R$
Клиентът вгражда паролата на потребителя в този низ (въз основа на всички (променливи) правила, които искате да приложите).
Клиентът изпраща низа до сървъра и ако паролата е ОК, сървърът влиза в системата.
Ако сървърът получи друга заявка за влизане с помощта на R$, потребителят се отписва и акаунтът се замразява в очакване на разследване.
Очевидно всички други (нормални) предпазни мерки за сигурност ще бъдат взети.
