Що б ви зробили, якби зрозумів, що постачальник хостингів електронної пошти може бачити ваші паролі?

Ми минулого року отримали електронний лист від нашого хостинг-провайдера стосовно одного з наших облікових записів - це було порушено та використовувалось для надання щедрої допомоги спаму.

Мабуть, користувач скинув свій пароль, щоб змінити її ім’я (прізвище - це те, про що, напевно, можна було здогадатися вперше.) Її негайно зламали протягом тижня - її акаунт розіслав чужий 270 000 спам-листів - і це було дуже швидко заблокований.

Поки нічого особливо незвичайного. Це трапляється. Ви змінюєте свої паролі на щось більш безпечне, навчаєте користувача та рухаєтесь далі.

Однак щось мене хвилювало навіть більше, ніж те, що один із наших рахунків був порушений.

Наш хостинг-провайдер, прагнучи бути корисним, насправді цитував нам пароль у такому електронному листі:

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

Наскільки часто хостинг-провайдер може дізнатися фактичний пароль, який використовується в обліковому записі?

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

Чи законним є хостинг-провайдер таким чином, щоб він міг виявляти паролі облікових записів таким чином? Мені це просто здається неймовірним.

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

З нетерпінням чекаю Вашої думки з цього приводу.

Так, звичайно для провайдерів Інтернет-послуг та постачальників послуг електронної пошти зберігати ваш пароль у простому тексті або у форматі, який легко відновити до звичайного тексту.

Причина цього пов'язана з протоколами аутентифікації, які використовуються серед PPP (комутований і DSL), RADIUS (комутований, 802.1x тощо) та POP (електронна пошта).

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

Наприклад, аутентифікація PPP або RADIUS може використовувати CHAP, який захищає дані аутентифікації під час транзиту, але вимагає простого текстового пароля, щоб зберігати Інтернет-провайдером. Аналогічно з розширенням APOP до POP3.

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

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

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

Дивіться також Чи я помиляюся, що паролі ніколи не підлягають відновленню (хеш-спосіб)? на нашому сестринському сайті IT Security

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

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

Вони, ймовірно, або зберігають паролі у простому тексті, або використовують якесь оборотне шифрування.

Як ви вже здогадалися, це дуже погано.

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

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

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

Усі інші відповіді чудові і мають дуже хороші історичні моменти.

Однак ми живемо в епоху, коли зберігання паролів у простому тексті спричиняє величезні фінансові проблеми і може повністю знищити бізнес. Надсилання паролів у простому тексті через незахищену електронну пошту також звучить смішно в епоху НСА, висмоктуючи всі пропущені дані в.

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

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

Я б перейшов до іншого постачальника електронної пошти. Пошук на "захищеному постачальнику електронної пошти" дає багато результатів.

У коментарях було кілька хороших моментів. Можливо, пошук "безпечного постачальника електронної пошти" матиме сенс, оскільки всі постачальники електронної пошти можуть похвалитися, що вони захищені. Однак я не можу рекомендувати певну компанію, і це, мабуть, не дуже добре робити. Якщо ви визначите конкретну компанію, яка спочатку задасть важке запитання щодо безпеки, це буде добре.

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

Для вирішення ще однієї заяви відповіді минули дні веселкових столів. Вони були замінені потужними графічними процесорами і займають занадто багато місця для зберігання (двійкові хеші, очевидно, не стискаються добре; і все одно ви не зберігали б їх у ASCII). Швидше (повторно) обчислити хеш на графічному процесорі, ніж прочитати його з диска.

Залежно від використовуваного алгоритму хешу та графічного процесора, можна очікувати, що сучасний комп’ютер з розірванням пароля прокручується приблизно від 100 мільйонів до мільярда хешів в секунду. Відповідно до цього (що трохи датоване тим, що, на його думку, може зробити комп'ютер / суперкомп'ютер), це означає, що будь-який 6-знаковий пароль може бути зламаний за лічені секунди. Таблиці для 7 та 8 хеш-знаків у всіх різних алгоритмах (MD5, SHA-1, SHA-256, SHA-512, Blowfish тощо) витрачали б непомірну кількість дискового простору (розумійте, що вам потрібно зберігати їх на SSD , а не магнітна пластина для швидкості доступу), і ви можете зрозуміти, чому атаки на основі словника за допомогою GPU швидше отримуватимуть паролі.

Приємна стаття для тих, хто виходить на сцену, - Як я став зламачем паролів у Ars Technica.

Це сталося зі мною!

Деякі роки тому моя особистість була порушена, коли мій провайдер хостингу (який в той час був і моїм постачальником електронної пошти) зазнав порушення безпеки. Я прокинувся, не можу перевірити свою електронну пошту, оскільки пароль був скинутий. Під контролем моєї електронної пошти вони намагалися скинути мій пароль на Amazon та PayPal. Ви можете здогадатися, що було далі, правда? Шахрайські збори з кредитної картки!

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

Немає жодних причин, щоб це сталося з вами, наша компанія!

У мене були підозри щодо ретельності цієї компанії, коли справа стосувалася безпеки, те, що я помічав тут і там протягом своїх років роботи з ними. Але я завжди переконував себе, що це не велика справа чи, можливо, я помилявся. Я не помилявся, і ви ні!

Якби я діяв, коли я вперше підозрював, що вони не ставляться до безпеки всерйоз, цілий міні-кошмар ніколи б не стався. Подумати, що може статися у випадку зіпсування цінного корпоративного рахунку? Ви будете легко виходити, якби надіслали лише СПАМ. Компанія, в якій я працював у той час, також використовувала цього провайдера, і ми зробили свій пріоритет якнайшвидшим переходом.

Довіряйте своїм інстинктам! Не передавайте долара на міграцію з-за ліні або через те, що ваша існуюча установка "працює нормально". Найбільш грізна частина недоліків безпеки, як зберігання паролів у чистому тексті, неправильне налаштування серверів тощо, - це те, що вони говорять про загальну некомпетентність та / або лінь у технічній культурі, і це культура, яку я не хотів би, щоб місія моєї компанії була критичною договір на обслуговування в будь-якому місці поблизу.

Я бачу альтернативне пояснення, коли Ваш пароль насправді хеширується на серверах вашого постачальника.

Оскільки постачальник зв’язався з Вами лише через день, він, ймовірно, (і це припущення) витягнув його з журналів серверів, оскільки його сценарій зміни пароля надсилає дані методом GET.

Це звучить простіше, ніж у вашого провайдера, що має базу даних, повна записів про те, коли, хто і як змінив пароль. Ви знаєте бритву Оккама ...;)