Чи дійсно SSL має значення для більшості веб-сайтів?


11

Я був досить паранояльним щодо того, щоб навчитися "правильно робити безпеку" для цього сайту, який я будую (перший нетривіальний сайт, який я створив), і помітив щось, що мене турбує: SSL.

Я прочитав безліч потоків безпеки тут, у StackOverflow та інших місцях, про які йде мова про відновлення ідентифікаторів сеансу після n використання та про те, як ваші паролі потрібно солити, хешировать та ніколи не зберігати у простому тексті. Я багато читав про те, як виявити, коли сеанс був викрадений, відстежуючи IP-адреси, користувацькі агенти та використовуючи файли cookie відстеження.

Я не розумію, що це має значення, коли веб-сайт входить у систему через звичайний HTTP POST та надсилає ваш пароль через провід у простому тексті?

Я розумію, що всі інші перераховані нами методи потрібні для зменшення загальної експозиції, і, можливо, є деякі сайти, які так чи інакше не потребують такої безпеки, але я думаю, що я прошу:

  • Коли це нормально не турбуватися з SSL?

Такі сайти, як Gmail, ваш банк та LinkedIn, я можу помітити, що є причина використовувати SSL, але те, що добре, що такі сайти, як Facebook та reddit, не турбують (пекло, PlentyOfFish навіть зберігає ваш пароль у простому тексті та навіть надсилає електронні листи) вам щотижня як нагадування!?!)?

Наскільки я повинен бути переконаним, що програма SSL налаштована (тим більше, що я починаю з спільного хоста, і я коштую досить дешево)? На моєму веб-сайті не зберігається особливо особиста інформація, якщо це допоможе. Якщо сайт стане успішним, я серйозно погляну на плату за додаткову безпеку.

Відповіді:


7

Це важливо стільки, скільки ви та ваші користувачі вважаєте, що це має значення. Надсилання паролів через http у вигляді простого тексту робить їх вразливими до нюхання пакетів. Тепер, чи дійсно хтось буде турбувати нюхати ці пакети, це зовсім інша історія. Якщо ви хочете забезпечити своїм користувачам максимально безпечний досвід роботи, використовуйте SSL для подання даних про вхід. Якщо ви думаєте, що ваші користувачі будуть щасливішими та більш імовірно взаємодіятимуть із вашим веб-сайтом позитивно (тобто купувати речі, робити речі тощо), тоді використовуйте SSL для подання даних про вхід. Якщо у вас є щось, що варто красти (тобто інформація про користувачів), тоді використовуйте SSL.

Якщо у вас нічого не варто красти, не думайте, що SSL значно покращить безпеку, або ж ваші користувачі не сприйматимуть це як корисну функцію, тоді ви, можливо, захочете не використовувати SSL.

Скільки коштує встановити SSL-серт, якщо ви не маєте бюджету на замовлення, ніколи не погано забезпечити вхід на сайт. І не дозволяйте, що інші сайти впливають на вас, оскільки більшість великих веб-сайтів не повинні дотримуватися кращих практик, і тому, здавалося б, є постійний потік новин про те, що хтось компрометований.


1
+1 «багато великих сайти не необхідні наступні кращі практики» - я впевнений , що там будуть якісь - то сміховинні заголовки , коли нігерійські 419'ers з'ясувати спосіб монетизації викрадені профілі сайт знайомств :)
danlefree

"якщо тільки ви не маєте бюджету, який вам цікавий", - але я. Я дійсно, справді є, до того, що я розглядаю можливість переходу m + m на дешевий загальний хост, а не значно менший за місяць, щоб платити за рік вперед. Таким чином я можу витягнути плагін, якщо сайт не почне платити за себе відносно швидко. Я думаю, що зараз я схиляюся до no-ssl, оскільки тільки отримання статичного ip, необхідного вдвох, майже вдвічі збільшить мою щомісячну вартість, не кажучи вже про вартість самого cert. Сайт досить близький до форуму, і більшість даних є загальнодоступними, тому немає необхідності в шифруванні поза входом у систему.
AgentConundrum

@danlefree, Це легко. Використовуйте особисті дані на сайтах знайомств, щоб відповісти на запитання щодо відновлення пароля для електронної пошти та банківського веб-сайту. Або просто захопити пароль, оскільки люди багаторазово використовують свої паролі.
Zoredache

@AgentConundrum Startssl пропонує сертифікат SSL безкоштовно. Якщо ви обмежуєте бюджет, але у вас є статичний IP, ви можете піти на це.
Рана Пратхап

@AgentConundrum вам більше не потрібен виділений IP для SSL, якщо ваш хост підтримує SNI (а якщо цього немає, знайдіть нового хоста, оскільки він не знає, що робить). Ви можете отримати сертифікат безкоштовно, так що це також не додаткова вартість ...
Doktor J

3

Приймаючи протилежний підхід до відповіді Джона, я думаю, що ви повинні серйозно розглянути SSL, якщо ви обробляєте будь - яку особисту інформацію - включати: імена з фізичними адресами, адреси електронної пошти, фінансову інформацію та комунікації, від яких користувачі могли б розраховувати на приватність .

Якщо на вашому веб-сайті користувачі не можуть публікувати інформацію про себе, ви повинні вважати, що будь-яка особиста інформація, надана вашими користувачами, зберігається вами, і ви маєте лише сувору довіру, якщо тільки політика конфіденційності вашого веб-сайту не інформує користувачів про інше.

Забороняйте стороннім сторонам бачити інформацію відвідувачів та інформуйте своїх користувачів про те, як ви використовуєте їх інформацію для підтримки довіри відвідувачів.

Навіть Facebook робить це, наскільки я можу сказати.

<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form" onsubmit=";var d=document.documentElement;if (d.onsubmit) { return d.onsubmit(event); }else { return Event.fire(d, &quot;submit&quot;, event); }">

(Джерело HTML для входу в Facebook.com)


Незвичайно. Я не знаю, як я цього не помітив у Facebook. Я дивився на це з HTTPFox і якось пропустив 's' за початковим запитом. Я редагую, щоб видалити це. Фактом все ще залишається факт, що багато сайтів роблять це (reddit, новини хакерів, TDWTF тощо), тож у гіршому випадку я не буду кращим за них. Бюджет є моєю серйозною турботою, тому витратити додаткові $ 5 на місяць для статичного IP (на 8-мільйонний долар на місяць ...), а також на купівлю гідного серта. сайт.
AgentConundrum

@AgentConundrum - Строго кажучи, нормально передавати пароль, що проходить через алгоритм одностороннього хешування через HTTP, якщо пароль засолений, тому я не буду дуже здивований, побачивши хеш-реалізацію MD5 на сайтах, які не використовують SSL: pajhome.org.uk/crypt/md5
danlefree

і як би створити хеш на стороні клієнта щось допомогло? У цьому випадку в основному хеш - це пароль . Я повинен мати можливість захопити хеш і повторно його відтворити так само легко, як і я можу захопити пароль.
Зоредаче

1
@Zoredache Саме тому хеш повинен бути солоним . Ось як це працює: я надсилаю вам сторінку входу із заздалегідь заповненим маркером, який включає microtime()дзвінок із сервера. Ваш переданий хеш - це комбінація вашого пароля +, microtime()і, як тільки я отримаю ваш хеш, я визнаю недійсною microtime()пару викликів / відповідей паролем (його неможливо використовувати знову).
danlefree

3

З серпня 2014 року Google офіційно вказав, що HTTPS буде використовуватися як сигнал ранжування.

Це означає, що навіть якщо ваш веб-сайт є повністю статичним веб-сайтом, якщо ви дбаєте про SEO, вам слід принаймні розглянути можливість створення сертифіката SSL.

Звичайно, HTTPS - це лише один сигнал з рейтингу сотень, тому, можливо, є більш важливі речі, які ви можете зробити для SEO.


Google також оголосив, що оскільки установка сертифіката SSL вимагає ресурсів, робити це потрібно лише в тому випадку, якщо цього вимагає ваш веб-сайт. Коротше кажучи, вони згадували, що ваш рейтинг не вплине лише тому, що ви не встановили сертифікат SSL у своєму особистому блозі.
Рана Пратхап

1

Ось такий кут, який ви, можливо, не враховували: не використовуючи SSL / TLS, можна піддавати користувачів пасивному моніторингу, навіть якщо на вашому сайті немає входів.

Актор загрози може просто сидіти між вашим користувачем та іншою частиною Інтернету, переглядаючи всі URL-адреси, які запитує ваш користувач, та будуючи шаблони речей, які переглядає ваш користувач. Окремі біти інформації дійсно можуть бути незначними ізольовано, але поєднання безлічі невеликих шматочків інформації може створити набагато більшу картину.

Саме тому я пропоную HTTPS на своєму власному сайті, який надає лише статичний контент.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.