Разни въпроси към WEB-аджиите...

[Tihomir(imageo)]

От: Разни въпроси към WEB-аджиите...

Това с криптирането на паролата при клиента беше модерно преди години, като масово сайтовете бяха на http://. Сега (почти) всичко работи с SSL, и няма особен смисъл от това. То и не си спомням да съм виждал някой сериозен сайт да го прави това. Освен това какво става ако клиента си забрани JS, или по някаква причина нещо гръмне в скриптовете(syntax error) - и не се заредят функциите? Няма как да се логне тогава усера... Кофти... Сериозните сайтове винаги имат fallback при липса на JS поддръжка.

Относно FormsAuthentication - напълно достатъчно е. Вече може да се правят разни хитринки отгоре му, но само ако има наистина нужда от това. Добре е да се сетне .Secure и .HttpOnly пропъртито на cookie-то(второто само ако няма AJAX рекуести които изискват куки). Ето едно детайлно обяснение как работи всичко това: http://msdn.microsoft.com/en-us/library/ff647070.aspx


P.S.
Освен това аз ако прихвана POST данните към сървъра... голяма полза, че паролата е криптирана На мен некриптираната такава не ми върши особена работа

[sparkybg]

От: Разни въпроси към WEB-аджиите...

Освен това какво става ако клиента си забрани JS

Така или иначе няма да може да работи, защото скриптове ще има на доста места, та и да се логне, полза никаква. То без скриптове и едно просто падащо меню не може да се направи.

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

[pecix]

От: Разни въпроси към WEB-аджиите...

Едно бързо примерче от голям фирмен сайт, където разбира се се ползва SSL, но при едно лееееееко пропускане на S-то от https и сайта пак се отваря. Да, админски неволи, защото някой не бил настроил правилно сървъра, но пък си е сериозна дупка този "малък" пропуск. Е, сайта е вътрешен, и за да се види, трябва VPN, но това не прави проблема сериозен.

За JS и хеширането на паролите: Модерно преди или сега? Плейн текст срещу нещо, което простосмъртните си нямат и представа какво представляват тези цифрички и буквички? А ми е интересно и да видя някой сайт без джава скрипт в момента. Навсякъде се ползва за щяло и нещяло AJAX, та да се притесняваме за криптирането на паролите....

В сигурността не може да се правят пропуски, защото не било модерно. Нямаме право да го правим.

Но всеки може да прави каквото си иска... Ако иска да си сложи и паролите скрити в джава скрипта, та да се прави client side check............

[Daniel]

Re: Разни въпроси към WEB-аджиите...

По добре си направи бан по ip при няколко грешни опита за логин.
И аз си мисля че няма нужда да криптираш при клиента ако е през SSL и няма да е публичен тулс. А каквото и секюрети да правиш ако е компрометиран компютъра на потребиля нищо няма да те спаси.

[Tihomir(imageo)]

От: Разни въпроси към WEB-аджиите...

Поискахте падащо меню без Javascript - ето го:

http://www.cssplay.co.uk/menus/final_drop.html

А когато един сайт може да се зареди по http:// то няма никаква техника на криптиране, която да дава сигурност в случая. Паролите се хешират само на сървъра, където се записват в база най-често. Защото ако някой открадне базата, да не може да използва данните за да се логва. Ако ползваме криптиране при клиента и на сървъра са записани паролите в MD5, и аз открадна базата - какво ще ме спре да си се логна като правят директен POST със скрипт към сървъра? За какво ми е да ползвам javascript криптиране в тоя случай? Просто плейн текста на паролата не ми върши никаква работа.
Докато ако се очаква да се събмитва плейн текст - то и да открадна MD5 паролите - няма начин да пусна POST заявка, защото тя ще очаква плейн текст парола, каквато аз не мога да екстрактна от MD5.... Простичко е всичко...

[pecix]

От: Разни въпроси към WEB-аджиите...

...
Освен това аз ако прихвана POST данните към сървъра... голяма полза, че паролата е криптирана На мен некриптираната такава не ми върши особена работа

Лузер: proba
Парола: parola

Сървъра генерира хтмл-че с някакъв salt: 123abc
Клиентската страна (броузера) показва логин екрана, като си знае, че има salt="123abc"
Генерира си SHA1 хеш на паролата + salt: parola123abc => sha1("parola123abc") = "aca4550cef322ac064e467314f0f708a73cfc787"
Прехващаме POST-a и си записваме този хеш на листче, за да си го залепим на монитора
...
Пробваме от нашия броузер да отворим сайта
Показва ни се логин страница, но пък вътре пише salt="987qwe", защото всеки път е рандъм.
Променяме си страничката да не прави хеш, а директно да праща данните и правим POST със записания вече хеш.
Обаче насреща сървъра очаква следното: sha1("parola" + "987qwe") = "ffee0083e8c59a18f4967ae8b025948bef07fbf1"
Показва се едно хубаво съобщение за сгрешена парола

И к'во правим? Май нищо

[sparkybg]

От: Разни въпроси към WEB-аджиите...

Да разбирам че наблягате на сигурността при съхранение повече, отколкото на сигурността при логване (при наличен SSL)? Поне натам разбирам че клоните?

[Tihomir(imageo)]

От: Разни въпроси към WEB-аджиите...

Спарки, проблема винаги е ако някой открадне нещо. В случая има 2 неща:

1. client cookie - ако аз ти открадна кукито - то няма какво да ме спре да се аутентикирам като теб, освен ако не се правят някакви много сложни проверки, каквито правят примерно Google, Amazon, Facebook и много други - ако се логна веднъж от България, и след 5 мин от Щатите с един и същ логин - Facebook например ми блокират акаунта моментално, а Google изпращат мейл за това, да го знам. Включи си сигурността във Facebook и примерно пробвай през Kindle с 3G да се логнеш във Facebook примерно(с browser-a) - той излиза от американско IP, и гледай шоу

2. Server data - ако се открадне базата с паролите, както се случва на не един голям сайт(последно на LinkedIn). Тогава трябва да има някаква сигурност, че не могат да се ползват тези данни. В последния брой на списание "2600" имаше страхотна статия как се кракват такива пароли с brute force.

има и трети случай - ако трансфера не е криптиран - не ползваме SSL. Там вече нищо няма значение, защото най-лесната атака е MITM. Затова за всякакви мерки за сигурност говорим само ако преди това сме разрешили само https:// за логване. Иначе са си празни приказки. А то може и да се логваме по https, но после сайта да е по http://, и ако кукито не е secure=only, стой та гледай шоу.

[pecix]

От: Разни въпроси към WEB-аджиите...

Да разбирам че наблягате на сигурността при съхранение повече, отколкото на сигурността при логване (при наличен SSL)? Поне натам разбирам че клоните?

Трябва да се наблегне и на двете. Защото и за SSL има доклад, че не е толкова сигурен, колкото ни се иска. Естествено, нормални хора нямат достъп до такива технологии.

Но защо да пропускаме нещо сравнително лесно и елементарно като криптиране на логина? То за това сигурността се мисли предварително, а не когато почват да се случват неприятностите. То това е същото като с адвокатите - винаги прибягваме до техните услуги, когато вече е късно

[Daniel]

Re: Разни въпроси към WEB-аджиите...

Много го задълбахме май То ако става за въпрос, ако сървера но който се хоства е калпаво настроен каквото и да правите всичко отива по дяволите
То самия уеб сървер има достатъчно дупки за хакове Няма как да запушите всичко.

Иначе ситеми има всякакви.
Например нямаш парола - даваш заявка и си получаваш временна парола на СМС, пейджър, мейл или подобно устройство, логваш се и паролата вече е невалидна, забравяш да се логнеш и паролата пак се деактивира

По скоро рестрикции по IP са по надеждни.

[pecix]

От: Разни въпроси към WEB-аджиите...

Ако прескочим уеба, то за сигурността имат значение и други фактори:
- връзката към SQL сървъра през SSL ли е?
- SQL сървъра на друга машина в мрежата ли се намира, или на същата?
- всички сървъри настроени ли са от към сигурност - файъруоли, юзъри, които могат да се логват, администратори, роли и т.н.?
- какво става, ако просто има някъде пуснат впн сървър за достъп от вън в мрежата, където има лузер тест с парола пассворд и така да е забравен от години?
- всички пароли на всички сървиси сменени ли са от дефолтните или не (sa/sa за mssql си е класика в продакшън )
- партишъните по дисковете криптирани ли са?
- кой има физически достъп до сървърите и има ли видеонаблюдение да се знае, че някой чисто физически влиза (чистачка? някой да ремонтира климатика?), изключва, вади си хард диска/дисковете и ги копира съвсем необезпокоявано?
- ...
- ...
- ...

Много може да се говори за сигурността, като всяка възможна дупка е опасна. В технически и човешки аспект. По-горе писах да се лепне паролката на монитора, че да не я забрави "хакера" Което е МАСОВО действие при много от хората, които се занимават със счетоводство, трз и подобни дейности.
Добавено: Даниел вече е писал за сървърите

[sparkybg]

От: Разни въпроси към WEB-аджиите...

- връзката към SQL сървъра през SSL ли е?

Локална е. Рабирай - като в нормално локално windows-ко приложение, ползващо DAO, ADO, и квото там се сетиш. Поне така го мисля да е. Сървърите ще са няколко, съвсем автономни. Това се налага защото например може да имаме 1000 малки клиента върху един сървър и той да се справя и да иска още, а на друг да не може да се справи и с 5 големи. Много по различен начин стои въпроса например в голяма държавна структура и средностатистическа частна фирма. Толкова са различни че почти нямат общо.

- всички сървъри настроени ли са от към сигурност - файъруоли, юзъри, които могат да се логват, администратори, роли и т.н.?

Смятам да подходя към това максимално консервативно и рестриктивно, както съм правил до сега със всичко, касаещо работата ми. Но всяко нещо с времето си.

ПП: Точно такава дискусия ми се щеше да си "завъдим" тук. Идея си нямате понякога само с 2 думи прости колко ми отваряте очите, и колко ровичкане ми спестявате.

[pecix]

От: Разни въпроси към WEB-аджиите...

Аз въпросите ги зададох само теоретично, тъй като нямат връзка с темата, но просто да покажа, че има много други фактори, които също оказват голямо влияние върху сигурността.

Не е задължително да се направи всичко в самото начало, но е добре да се обмисли предварително да е лесно за промяна в бъдеще. Лош дизайн в началото = пренаписване при промяната му. При нас в много случаи бързаме и пропускаме design spec-а на приложението и после винаги сме губили в пъти повече време да дооправяме неразбории, за които не сме били помислили.

И на мен ми харесва дискусията, защото е доста офроуд спрямо широко разпространените разбирания при програмирането

[persuader]

От: Разни въпроси към WEB-аджиите...

Tihomir(imageo) - пъвро редно е сесията да е байндната към Ip addres дори и да ми земеш кукито с session id-то надали ще имаш някакъв успех.

За да brute-форснеш читаво криптирани пароли примерно sha2 плюс читав salt с което избягваш rainbow tables плюс stong password policy доста зор ще видиш най-малкото за времето за което ще издъниш паролата има голяма вероятност админите да сa се усетили че има пробив или потребителя да си е сменил паролите.

Другите неща които могат да се направят е - защита от csrf за което се спомена по горе. Както и доста сериозна валидация на input данните - случай на налепи sql jnectioni под път и над път.

Чета темата с интерес

[Людмил Кюковски]

От: Re: Разни въпроси към WEB-аджиите...

По скоро рестрикции по IP са по надеждни.

+ MAC !