Три відповіді і купа лайків.
Що характерно, якщо тих же самих людей запитати, чи треба хешірованного паролі на сервері - все дружно, ладом і хором скажуть - ПОТРІБНО!
При цьому думка, як поєднати обидві технології, не спадає на думку жодному з них. А вони не поєднуються. Якщо "сервак зі свого боку так само солить пароль і вважає хеш" то це означає. що паролі зберігаються у відкритому вигляді!
Це квінтесенція подобнийх сайтів. Відповідь чомусь завжди дається самий буквальний. При цьому питання ніколи не ставиться під сумнів або хоча б мінімальної перевірці на свідомість. Таке відчуття, що відповідають сприймають питання як іспит чи що? Або як челендж - відповісти за всяку ціну, хай навіть і неймовірних збочень і гарантувати граблів в майбутньому. Або - як зараз - ціною ЗНИЖЕННЯ захищеності! Але зате відповідь буквальний. І так не тільки тут - так практично в будь-якій відповіді. Ну ніколи ні у кого не твремені задуматися над питанням - все поспішають відповідати.
Я не знаю, що з цим робити. Такий підхід дуже шкодить як самому сайту, так і тим, хто задає питання. Замість того, щоб показати правильний підхід, йому старанно, сопучи і напружуючи рештки звивин, допомагають вистрілити собі в ногу.
Перед тим як відповідати, ТРЕБА СПОЧАТКУ ПОДУМАТИ. Порахувати на хід вперед - "а що буде, якщо зробити, як я раджу?" Порахувати на хід назад - "а навіщо йому потрібно це? Чи не схожий це питання на мій власний, який я колись ставив від нестачі знань?" І спробувати відповісти так, щоб РЕАЛЬНО допомогти запитувачу, а не просто видати зазубрений відповідь.
Я дивлюся у вас широта мислення перевершує всі мислимі масштаби.
При чому тут взагалі хешування на сервері, якщо мова йде про безпечної передачі пароля до нього?
Чому реалізація асиметрично шифрованого каналу на рівні ajax не може забезпечити ту ж надійність передачі даних як і SSL?
Коротше не потрібно вважати на зайве ходи якщо не знаєш який напрямок "вперед".
FanatPHP. та й хрін би з ним.
Сам питання при цьому цілком можна вирішити. До речі "сервак зі свого боку так само солить пароль" можна легко замінити на "сервак зі свого боку так само солить хеш" і, вуаля, у нас знову карета. Правда все одно не Едіт, але це інша історія.
У будь-якому випадку захищену передачу організувати можливо і це ніяк не заважає зберігання хеша.
FanatPHP. Ні. Не потрібно. Тому, що якщо передавати сіль, то вона позбавляється сенсу для використання. Весь смак солі в тому, що вона зберігається на сервері і не доступна. Від використання солі потрібно буде відмовитися. Це не так страшно як прийнято думати, тим більше що існують альтернативні методи.
Як ми зазвичай зберігаємо пароль? hash (pass + sold)
А що нам заважає замість цього зберігати його так: encrypt (hash (pass), sold), де encrypt функція симетричного шифрування використовує в якості ключа sold.
Можна навіть крутіше: encrypt (hash (pass) + rand (), sold)
Сподіваюся зрозуміло.
Завжди приємно, тупанув самому, побачити смітинку в очах співрозмовника :) 1. Сенс солі зовсім не в цьому. Сіль заздалегідь вважається скомпрометованої і тому-то і зберігається у відкритому вигляді. Завдання солі - захист від прекомпілірованние пошуку АКА райдужних таблиць. Головне, щоб вона була завжди різною. А відома вона чи ні - має бути не важливо. 2. Зберігання пароля в оборотно зашіврованном вигляді - це нове слово в безпеці. Правда, боюся, занадто нове. Чи не зрозуміють-с :) (в даному випадку ми виходимо знову на Дерибасівську, в якій ash (pass) виступає в ролі відкрито зберігається пароля)
1) Ну да, логічно. Я дурень. Можна передавати.
2) Ні, не в оборотному. Ми шифруємо НЕ пароль, а хеш. Він не звернемо з визначення. Але так - предвичесленние таблиці зроблять нам боляче - згоден.
На Дерибасівській ж ми не виходимо. Тут ви помилилися - ми ж не передаємо хеш!