Премини към съдържанието
simtech

Хеширащи функции и защита на информация.

    Препоръчан отговор


    Правя една система, която трябва да има потребителски вход.
    Коя хешираща функция е най-удачно да използвам за сравнение на парола с хеш в базата данни?
    И кой е най-сигурният начин да направя така, че никоя подстраница да не може да се отваря без вярно въведени данни за вход, т.е трябва да няма директен достъп. Мислех си за реферер и бисквитка.

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Ползвай password_{hash,verify} функциите в PHP > 5.5. Ползват bcrypt по default ползват bcrypt, от PHP 7.2 по default има поддръжка и на libsodium и можеш да ползваш Argon2 със същите функции.
    Относно проверката на достъп - можеш да я имплементираш както ти е кеф. Примерно може в бисквитка/localstorage/sessionstorage да сетваш  token , който да пращаш със всяка заявка, може да сторваш променлива в сесията на потребител и да правиш проверка по нея, това си е въпрос на имплементация.
    Най-добре да си организираш проверката като middleware за да не се налага да пишеш логики за всеки endpoint на APP-a.

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 2 часа, borovaka написа:

    Относно проверката на достъп - можеш да я имплементираш както ти е кеф. Примерно може в бисквитка/localstorage/sessionstorage да сетваш  token , който да пращаш със всяка заявка, може да сторваш променлива в сесията на потребител и да правиш проверка по нея, това си е въпрос на имплементация.

    Мога да правя проверка, но ме интересува най-лесният и сигурен начин за проверка за достъп.
    Писал съм дребни неща на PHP, но с това не съм се занимавал. Сподели малко подробности, за да не се налага да ровя документация.
    Защото тая бисквитка трябва да я направя сесийна, не може да е една и съща, защото иначе контрола на достъпа твърде лесно се заобикаля.

    Редактирано от Питоня (преглед на промените)

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Губят ти се основни моменти. 

    Първо, хеширането на пароли не се прави с цел да се повиши сигурността при логване/работа със системата. А за да се повиши сигурността и при евентуалното изтичане на базата данни (на съхранените пароли). 

    За тази цел, хеширането не е достатъчно. Затова се ползват допълнително генерирани (случайно) данни които се прибавят към паролата преди тя да бъде хеширана. Това се нарича "посоляване" и някои бази данни предлагат готови функции за тая работа. Та е хубаво да ползваш тях вместо голо хеширане. Ако базата данни не поддържа нещо подобно ще трябва да си го реализираш сам. 

     

    Второ, бисквитките са неразделна част от сесиите. Така че, няма как да минеш без тях. Проверката за това дали потребителя е логнат се свежда до вдигане на флаг в потребителската сесия (login) и в последствие до проверка дали този флаг съществува и дали е вдигнат (isLogin). Функцията logout респективно се реализира като флагат се свали или изтрие. 

    Тук проблемът е именно в кражбата на бисквитките. Затова можеш да обвържеш сесията и с някакъв константен параметър на конекцията. За целта можеш да ползваш всичко от ИП адрес до идентификацията на браузерът в зависимост от това колко си параноичен. 

    • Харесва ми 1

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Офтопик

    Ще си позволя един офтопик за да внеса малко светлина по случая Питоня за да имат идея помагащите и всеки да си прецени дали си заслужава изобщо или някой си генерира вятър на клавиатурата.

    преди 3 часа, Питоня написа:

    Писал съм дребни неща на PHP, но с това не съм се занимавал. Сподели малко подробности, за да не се налага да ровя документация.

    Страхувам се че подробностите хич няма да са малко и че ще трябва да се обърне темата на училище като се започне от буквата А. И ти не дребни а точно никакви неща не си писал. Стига заблуждава хората че имаш идея за какво питаш.
    Писал дребни неща пък инак беше щедър на съвети колко "бъга" имал сайта и как трябвало да се оправят и как се правели нещата. Сега се оказа че писал дребни неща !!! Как може да си толкова нагъл тогава? Да даваш акъли на хора с опит в програмирането как да си оправят сайта.
     

    Както и очаквах веднага те разкриха.

    преди 2 часа, mr mcwolf написа:

    Губят ти се основни моменти. 

    Човек, за този всезнайко които в последно време ни се представя за някакъв "инженер" няма тайни и очаквам след няколко поста дори да си позволи да ви даде съвети на всички къде се опитвате да му помогнете.
    Само като му видиш титлата под ника и трябва да ви стане ясно че случая е много тежък.
    Човек без грам опит в програмирането тръгнал да прави система !!!
    Та той дори търсачката на форума не може да ползва а е тръгнал система да прави. Дори не може да си открие старата тема по случая. Не че изобщо прави нещо а иска да прави впечатление че прави неща и програмира.

    И тука е изписа доста глупости които го издават че с нищо подобно не се занимава.


    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 2 часа, mr mcwolf написа:

    Губят ти се основни моменти. 

    Първо, хеширането на пароли не се прави с цел да се повиши сигурността при логване/работа със системата. А за да се повиши сигурността и при евентуалното изтичане на базата данни (на съхранените пароли). 

    За тази цел, хеширането не е достатъчно. Затова се ползват допълнително генерирани (случайно) данни които се прибавят към паролата преди тя да бъде хеширана. Това се нарича "посоляване" и някои бази данни предлагат готови функции за тая работа. Та е хубаво да ползваш тях вместо голо хеширане. Ако базата данни не поддържа нещо подобно ще трябва да си го реализираш сам. 

     

    Второ, бисквитките са неразделна част от сесиите. Така че, няма как да минеш без тях. Проверката за това дали потребителя е логнат се свежда до вдигане на флаг в потребителската сесия (login) и в последствие до проверка дали този флаг съществува и дали е вдигнат (isLogin). Функцията logout респективно се реализира като флагат се свали или изтрие. 

    Тук проблемът е именно в кражбата на бисквитките. Затова можеш да обвържеш сесията и с някакъв константен параметър на конекцията. За целта можеш да ползваш всичко от ИП адрес до идентификацията на браузерът в зависимост от това колко си параноичен. 

    Чистото хеширане на пароли , дори + salt не се смята за добра практика. Първо, че не е по-трудно за разбиване, поради простата причина, че salt-a така или иначе го пазиш някъде (обичайно в базата) и ако базата leak-не, така или иначе е ясно какъв е salt-a. Така, че е добре да се използват криптиращи функции. - Няма да навлизам в детайли, но ако те интересува можеш да почетеш доста по темата.

    преди 4 часа, Питоня написа:

    Мога да правя проверка, но ме интересува най-лесният и сигурен начин за проверка за достъп.
    Писал съм дребни неща на PHP, но с това не съм се занимавал. Сподели малко подробности, за да не се налага да ровя документация.
    Защото тая бисквитка трябва да я направя сесийна, не може да е една и съща, защото иначе контрола на достъпа твърде лесно се заобикаля.

    Сесията по принцип се пази server side (като файл, в база, в momory storage или където и да е), в бисквитката се предава само референция, за да може сървъра да направи разлика, коя сесия към коя кънекция се отнася. Вече за предпазване на бисквитката от кражба могат да се ползват доста неща. Най streight forward варианта е да ползваш TLS + secure flag (предава бисквитката по TLS), httponly ( забранява JS достъпа до бисквитката, предпазва от XSL  ), може и use_only_cookies да прегледаш ( задължава  session id да се предава само през бисквитката ). В PHP разгледай : session.cookie_httponly , session.use_only_cookies , session.cookie_secure. Другото, което може да разгледаш е HSTS (HTTP Strict Transport Security) - предпазва от downgrade на TLS сесията към HTTP.
    В един пост едва ли ще може да се обясни цялата тема, има доста информация - мисля, че това ти е достатъчно за старт. 

    Редактирано от borovaka (преглед на промените)

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 2 часа, mr mcwolf написа:

    Губят ти се основни моменти. Първо, хеширането на пароли не се прави с цел да се повиши сигурността при логване/работа със системата. А за да се повиши сигурността и при евентуалното изтичане на базата данни (на съхранените пароли)....
    ... Второ, бисквитките са неразделна част от сесиите.

    Мисля, че не съм се изразил ясно. Хеширащите функции са едноосочни функции. Използват се за повишаване на сигурността на съхранените в базата данни пароли. Може вярна парола да се хешира и сравни с хеша в базата данни, но е невъзможно/много трудно от хеша да се получи парола. Единственият начин е да имаш речник и да знаеш дадена функция - кой хеш точно отговаря на дадена дума. Проблемът се състои в това, че промяна на един явен или неявен символ води до съвсем друг хеш. А ако хешът се соли, то е още по-трудно да направиш каквото и да е било.
    За това в момента се прибягва основно към MITM атаки и fishing.
    Това, което ми се губи на мен е, че не съм работил с кукита.

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 12 минути, BMW Маниак написа:

    Офтопик

    Ще си позволя един офтопик за да внеса малко светлина по случая Питоня за да имат идея помагащите и всеки да си прецени дали си заслужава изобщо или някой си генерира вятър на клавиатурата.

    Страхувам се че подробностите хич няма да са малко и че ще трябва да се обърне темата на училище като се започне от буквата А. И ти не дребни а точно никакви неща не си писал. Стига заблуждава хората че имаш идея за какво питаш.
    Писал дребни неща пък инак беше щедър на съвети колко "бъга" имал сайта и как трябвало да се оправят и как се правели нещата. Сега се оказа че писал дребни неща !!! Как може да си толкова нагъл тогава? Да даваш акъли на хора с опит в програмирането как да си оправят сайта.
     

    Както и очаквах веднага те разкриха.

    Човек, за този всезнайко които в последно време ни се представя за някакъв "инженер" няма тайни и очаквам след няколко поста дори да си позволи да ви даде съвети на всички къде се опитвате да му помогнете.
    Само като му видиш титлата под ника и трябва да ви стане ясно че случая е много тежък.
    Човек без грам опит в програмирането тръгнал да прави система !!!
    Та той дори търсачката на форума не може да ползва а е тръгнал система да прави. Дори не може да си открие старата тема по случая. Не че изобщо прави нещо а иска да прави впечатление че прави неща и програмира.

    И тука е изписа доста глупости които го издават че с нищо подобно не се занимава.

    Мен грам не ме интересува дали разбира или не разбира :) Казах си мойте 5 пари по въпроса ( аз по принцип съм малко просто и твърденията ми трябва да се подлагат на съмнение ), ако някой има мерак да прави нещо - ще го направи без значение дали е наясно или не.

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Не ми се влиза в излишни спорове. Разликата между криптиране и хеширане ти е ясна, предполагам? 

    Криптирането е двупосочна операция - а това значи, че паролата се съхранява и всеки може да я види (независимо от това с какво си я криптирал, ключовете трябва да са на сървърът за да може той да прави проверките). Затова се пази само хеш от паролата (никой не я знае, следователно рискът от изтичането и го няма). 

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

     

    Относно сесиите, бисквитката е нейния идентификатор. На нейна база сървърът зарежда потребителските данни които пази. Та който има достъп до сесийния идентификатор, той има достъп до сесията. 

    Ssl решава частично тоя проблем. Но бисквитката в края на краищата се пази на клиентската машина и всеки с достъп до нея може да я вземе (вирус да речем). Затова в сесията се записва и допълнителен параметър който да не може да се подправи лесно (да речем ИП адрес). Така се налагт изкуствени ограничения за това от къде може да се използва конкретната сесия което повишава сигурността и. 

    • Харесва ми 1

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 2 часа, mr mcwolf написа:

    Не ми се влиза в излишни спорове. Разликата между криптиране и хеширане ти е ясна, предполагам?

    Човек, защо си мислиш, че не ми е ясна разликата между хеширане и криптиране? Или че не знам какво е rainbow table?
    Знам какво представлява хеширането. По-горе писах. Еднопосочна функция. Криптирането е двупосочна функция и се използва за предаване на информация по несигурен канал. Понеже криптирането и декриптирането са математически свързани операции е възможно да се изчисли с достатъчно изчислителна мощ.
    Ако това ще те успокои, курсовата ми работа по криптиране и защита на информацията беше програма, която трябва да кракне RSA с определени параметри. Писах я на C++
    Понеже аз съм предимно писал на C++, за това потърсих тук идеи и написах тема. Аз н съм много по web приложенията, правил съм бази данни, връзки, форми и взаимодействие. Но ме интересува живо защита на иформацията.
    Пиша точно за методики за кукитата и реферите. За да не се налага да преоткривам топлата вода.
    HTML/CSS знам, но не съм се занимавал сериозно с PHP. Не може човек да знае всичко, мама му стара.
    Ако толкова те интересува, мога да ти постна програмчета на C и да видиш дали толкова не знам какво е криптиране и какво е хеширане.
    Това, което искам да знам е как дa реализирам най-лесно кукитата и сесиите в средата на PHP.
    А и аз искам да ползвам SHA, a не MD5

    преди 3 часа, BMW Маниак написа:

    И тука е изписа доста глупости които го издават че с нищо подобно не се занимава.

    Ти си една глупост и грешка, която администраторът трябва да поправи с подходящия бутон(блокирай потребител).
    Онези въпроси съм си ги решил и сега тръгвам по програмната реализация.

    Редактирано от Питоня (преглед на промените)

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 17 минути, Питоня написа:

    Човек, защо си мислиш, че не ми е ясна разликата между хеширане и криптиране? Или че не знам какво е rainbow table?
    Знам какво представлява хеширането. По-горе писах. Еднопосочна функция. Криптирането е двупосочна функция и се използва за предаване на информация по несигурен канал. Понеже криптирането и декриптирането са математически свързани операции е възможно да се изчисли с достатъчно изчислителна мощ.
    Ако това ще те успокои, курсовата ми работа по криптиране и защита на информацията беше програма, която трябва да кракне RSA с определени параметри. Писах я на C++
    Понеже аз съм предимно писал на C++, за това потърсих тук идеи и написах тема. Аз н съм много по web приложенията, правил съм бази данни, връзки, форми и взаимодействие. Но ме интересува живо защита на иформацията.
    Пиша точно за методики за кукитата и реферите. За да не се налага да преоткривам топлата вода.
    HTML/CSS знам, но не съм се занимавал сериозно с PHP. Не може човек да знае всичко, мама му стара.
    Ако толкова те интересува, мога да ти постна програмчета на C и да видиш дали толкова не знам какво е криптиране и какво е хеширане.
    Това, което искам да знам е как дa реализирам най-лесно кукитата и сесиите в средата на PHP.
    А и аз искам да ползвам SHA, a не MD5

    След като си писал такава курсова работа не вижда какъв е проблема с HTTP като цяло, cookies се ползват, защото HTTP e stateless протокол. Мисля, че до сега ако беше направил 2 теста щеше да си го имплементирал и да си забравил.
    И както казах ползвай bcrypt вместо SHA - имаш стандартни функции в PHP
     

     

    преди 2 часа, mr mcwolf написа:

    Не ми се влиза в излишни спорове. Разликата между криптиране и хеширане ти е ясна, предполагам? 

    Криптирането е двупосочна операция - а това значи, че паролата се съхранява и всеки може да я види (независимо от това с какво си я криптирал, ключовете трябва да са на сървърът за да може той да прави проверките). Затова се пази само хеш от паролата (никой не я знае, следователно рискът от изтичането и го няма). 

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

     

    Относно сесиите, бисквитката е нейния идентификатор. На нейна база сървърът зарежда потребителските данни които пази. Та който има достъп до сесийния идентификатор, той има достъп до сесията. 

    Ssl решава частично тоя проблем. Но бисквитката в края на краищата се пази на клиентската машина и всеки с достъп до нея може да я вземе (вирус да речем). Затова в сесията се записва и допълнителен параметър който да не може да се подправи лесно (да речем ИП адрес). Така се налагт изкуствени ограничения за това от къде може да се използва конкретната сесия което повишава сигурността и. 

    Не споря и си прав. Ако трябва да влизаме в детайли bcrypt също е хеш функция ( паролата не се sotre-ва )  и ползва salt, просто се базира на blowfish и има преимущества upgrade на cost примерно ...
    Просто не виждам смисъл в конкретната тема да навлизаме в детайли ... поради причини, които мисля, че станаха ясни вече :)

    А за  browser fingerptint и IP restriction и т.н. мисля, че изобщо не са практични - имат доста "странични" ефекти, които компенсират полезността - пак мисля, че не е мястото да го обсъждаме

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 8 минути, borovaka написа:

    След като си писал такава курсова работа не вижда какъв е проблема с HTTP като цяло, cookies се ползват, защото HTTP e stateless протокол. Мисля, че до сега ако беше направил 2 теста щеше да си го имплементирал и да си забравил.
    И както казах ползвай bcrypt вместо SHA - имаш стандартни функции в PHP

    Така е, но с питане се стига до Цариград.

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Регистрирайте се или влезете в профила си за да коментирате

    Трябва да имате регистрация за да може да коментирате това

    Регистрирайте се

    Създайте нова регистрация в нашия форум. Лесно е!

    Нова регистрация

    Вход

    Имате регистрация? Влезте от тук.

    Вход


    ×

    Информация

    Този сайт използва бисквитки (cookies), за най-доброто потребителско изживяване. С използването му, вие приемате нашите Условия за ползване.