Изпращане на парола чрез html форма по некриптирана връзка?
| Автор |
|
| insecteaterВто, 17.08.10, 00:05 |
Заглавието на темата е красноречиво. Като почна да го премислям и ми се завъртат из главата разни симетрични и несиметрични криптирания, и неприятния факт, че от едната страна седи php с неговите си функции, а от другата (клиентската) javascript, който откъм криптиращи функции не е особено навътре. Началото - имаме отворена сесия, и форма за изпращане на клиента. Само че не знам каква точно форма да му изпратя, какъв JavaScript да сложа при клиента и той да ми върне нещо така, че ако някой подслушва междинния трафик, да не може да се log-не и той на свой ред. Може да си мислите че съм параноик, но като знам колко лесно се подслушва трафик (и забавно, ако го правиш ти) ... един такъв алгоритъм и съответно конкретната му реализация би ми била доста полезна не само в момента, а и за в бъдеще. | | | stoqnchoВто, 17.08.10, 00:21 | RE: Изпращане на парола чрез html форма по некриптирана връзка?
” Заглавието на темата е красноречиво. Като почна да го премислям и ми се завъртат из главата разни симетрични и несиметрични криптирания, и неприятния факт, че от едната страна седи php с неговите си функции, а от другата (клиентската) javascript, който откъм криптиращи функции не е особено навътре. Началото - имаме отворена сесия, и форма за изпращане на клиента. Само че не знам каква точно форма да му изпратя, какъв JavaScript да сложа при клиента и той да ми върне нещо така, че ако някой подслушва междинния трафик, да не може да се log-не и той на свой ред. Може да си мислите че съм параноик, но като знам колко лесно се подслушва трафик (и забавно, ако го правиш ти) ... един такъв алгоритъм и съответно конкретната му реализация би ми била доста полезна не само в момента, а и за в бъдеще. „
Добре, че не те разбрах иначе щях да прихвана от твоята параноя.  редактиран от stoqncho на 17.08.10 00:21 | | | insecteaterВто, 17.08.10, 12:39 |
Обикновено, паролата се праща в криптиран вид. Не е проблем например да направя така, че преди да се изпрати паролата да и се приложи някакъв хеш. Така паролата няма да пътува в явен вид по некриптираната връзка. Но си мисля следното - всеки който подслушва трафика, може да прихване POST заявката, която съдържа хешираната парола. Може да се пробва с bruteforce или rainbow ако иска, но ми е чудно друго. Няма проблем да използва абсолютно същата POST заявка за да се лог-не вместо мен. Паролата дефакто не му трябва. С най различните добавки за firefox си е направо детска игра. Срещу кражба на сесия не смятам да се боря | | | anonymousВто, 17.08.10, 12:47 | | | | insecteaterВто, 17.08.10, 13:33 |
Благодаря, някои от идеите които използват там вече съм ги обмислял. Спрях се на следния алгоритъм: Сървъра генерира СЛУЧАЕН ключ.
Този ключ се съхранява в сесията.
Ключа се изпраща на клиента.
Клиента използвайки този ключ криптира (еднопосочно) паролата
Клиента връща на сървъра криптираната парола, заедно с ключа
Сървъра сравнява получения от клиента ключ с ключа съхранен при него в сесията - ако съвпаднат, тогава пристъпва към проверка на паролата.
Ако всичко съвпада, ключа се изтрива от сесията, и клиента се смята за удостоверен в тази сесия. Така, дори някой да повтори POST заявката, тя няма вече да е валидна, понеже ключа който е бил използван вече не съществува при сървъра. По този начин ако някой подслушва, трябва да действа незабавно, докато не изтекла сесията. От сайта който ми даде koko5 си харесах механизма за сравняване на IP адреси - т.е. ако в рамките на една сесия IP адреса на клиоента се смени, значи нещо не е наред. Това може да представлява и неудобство, но според мен предимството е по-голямо от неудобството. Все пак доста рядко се случва да браузваш удостоверено като едновременно с това сменяш доставчик / IP адрес. Другият механизъм с постоянна смяна на сесийното ID не ми допадна, понеже е неудобен за техническа реализация, а и бутона back няма да сработва както се очаква. Лек недостатък е, че паролата трябва да се съхранява в явен вид някъде на сървъра, за да може сървърва да я криптира със същия ключ, с който я криптира и клиента. Но съм някак си по-склонен да вярвам в сигурността на сървъра, отколкото на това, какво изпраща клиента. | | | anonymousВто, 17.08.10, 13:57 |
Ами напиши си декриптируем алгоритъм, ако ти е толкова важно. Значи моята идея, за която съм се сетил е измежду base64 да се ръгне помалко произволно криптирани MD5 знаци. Тоест MD5 се ръзхвърля из base64 и после се връща само base64 по обратен път(чрез знаци между base64 и MD5 хеша.  Трудно е да го обясня редактиран от anonymous на 17.08.10 13:57 | | | insecteaterВто, 17.08.10, 16:44 |
Не ми трябва да декриптира. Гледам, че и ти се въртиш около MD5 и BASE64 - почна да ми се избистря: Най вероятно този начин го има някъде описан, но в onilne джунглата ако не знаеш какво точно търсиш, върви че се оправяй - тогава обикновено се открива топлата вода наново. 1. Генерирам достатъчно дълъг случаен низ и го записвам в сесията
2. Пращам го и на клиента
3. Клиента чрез JavaScript взема този случаен низ, долепя отзад паролата и на така полученото нещо прави MD5 хеш
4. Клиента връща на сървъра две неща - случайния низ и полученият MD5 хеш *
5. Сървъра сравнява случайния низ от сесията и от клиента - трябва разбира се да са еднакви
6. След това долепя истинската парола която се съхранява в сървъра зад случайния низ и генерира MD5 hash.
7. Получения хеш от сървъра и получения от клиента трябва да съвпаднат.
8. В сесията се отбелязва, че потребителя е лог-нат и случайния низ се изтрива от сесията
9. При иницииране на сесията се записва в нея и IP адреса, за да се следи при всяко обръщение дали друг IP адрес не се опитва да ползва същата сесия. Този който подслушва вижда случайния ключ, и MD5 хеша, който обаче зависи от паролата, като тази двойка е валидна само един единствен път - т.е. не може да ги използва същите за фалшифицирана заявка. (макар да не му е проблем просто да открадне SSID-то, ако е достатъчно бърз)
Не знам дали ако подслушвача се добере до повече бройки случаен низ - MD5 хеш това би му помогнало по някакъв начин да разбере паролата. Ако някой може да посочи как може да се атакува паролата чрез посочения алгоритъм, ще се радвам да сподели и да посочи слабото място или пък някакъв по-лесен и достатъчно надежден начин. Дотогава действам по описания алгоритъм. Благодаря ви и на двамата за насоките и за подсказките. *Всъщност три неща - да не забравяме и потребителското име. | | | tegoteВто, 17.08.10, 19:23 |
Инсект. Нищо против, ама ако си забелязъл тук пишат малцина в затворена система. Навън е друго. Там всеки пише, всеки вижда. Съответно и шансовете да намериш отговор са...... -> Другото което, наостряш ушите на хората, занимаващи се с подслушването. | | | phrozencrewСъб, 21.08.10, 12:08 |
Insecteater, мисля, че алгоритъма ти е достатъчно сигурен, дори за корпоративни нужди! Не съм се замисля как точно може да се пусне https (SSL) криптирана връзка, а и може би се плаща за подобна възможност, но това е другия вариант. Темата ти ме накара да се замисля за техниките за снифене и кракване на подобни връзки... Тук има интересни неща: http://www.owasp.org/index.php/Session_hijacking_attack | | | anonymousСъб, 21.08.10, 14:29 | RE: Изпращане на парола чрез html форма по некриптирана връзка?
” Не ми трябва да декриптира. Гледам, че и ти се въртиш около MD5 и BASE64 - почна да ми се избистря: Най вероятно този начин го има някъде описан, но в onilne джунглата ако не знаеш какво точно търсиш, върви че се оправяй - тогава обикновено се открива топлата вода наново. 1. Генерирам достатъчно дълъг случаен низ и го записвам в сесията
2. Пращам го и на клиента
3. Клиента чрез JavaScript взема този случаен низ, долепя отзад паролата и на така полученото нещо прави MD5 хеш
4. Клиента връща на сървъра две неща - случайния низ и полученият MD5 хеш *
5. Сървъра сравнява случайния низ от сесията и от клиента - трябва разбира се да са еднакви
6. След това долепя истинската парола която се съхранява в сървъра зад случайния низ и генерира MD5 hash.
7. Получения хеш от сървъра и получения от клиента трябва да съвпаднат.
8. В сесията се отбелязва, че потребителя е лог-нат и случайния низ се изтрива от сесията
9. При иницииране на сесията се записва в нея и IP адреса, за да се следи при всяко обръщение дали друг IP адрес не се опитва да ползва същата сесия. Този който подслушва вижда случайния ключ, и MD5 хеша, който обаче зависи от паролата, като тази двойка е валидна само един единствен път - т.е. не може да ги използва същите за фалшифицирана заявка. (макар да не му е проблем просто да открадне SSID-то, ако е достатъчно бърз)
Не знам дали ако подслушвача се добере до повече бройки случаен низ - MD5 хеш това би му помогнало по някакъв начин да разбере паролата. Ако някой може да посочи как може да се атакува паролата чрез посочения алгоритъм, ще се радвам да сподели и да посочи слабото място или пък някакъв по-лесен и достатъчно надежден начин. Дотогава действам по описания алгоритъм. Благодаря ви и на двамата за насоките и за подсказките. *Всъщност три неща - да не забравяме и потребителското име. „ Няма начин, освен ако не ти знае алгоритъма.
Иначе аз за това писах, че всеки път за MD5 се генерира нов символ за криптиране. Това ще доведе обаче до доста по-сложен алгоритъм, защото сравняването ще е по-сложно. Успех! И да не се бъхтиш много ако е общшнски сайт редактиран от anonymous на 21.08.10 14:29 | |  Коментар
|
Отговор
За печат