Що повинні знати веб-програмісти про криптографію? [зачинено]


27

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

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

Чи знайшли ви коли-небудь необхідність використовувати криптографію у веб-програмуванні, окрім цих двох простих прикладів?


4
Вони повинні знати достатньо, щоб знати, що не повинні цього робити.
СЛАкс

@SLaks: +1 100% згідний. Я написав відповідь на цю тему, щоб розширити, чому це так.
Кріс Єстер-Янг

Відповіді:


41

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

Зокрема, це означає, що жоден експерт із питань безпеки не повинен торкатися жодного криптографічного примітиву безпосередньо. Вони не повинні думати на рівні AES, SHA-1 тощо. Натомість вони повинні використовувати функції високого рівня для шифрування та підписання повідомлень та "хеш" паролів.

Чому? Бо в іншому випадку людей вводять в оману, думаючи, що:

  • AES-256 - це "велике шифрування", незважаючи на те, що вони використовують його в режимі ECB, або використовують невипадкові значення IV тощо. Так багато.)
  • Вони можуть використовувати один і той же симетричний ключ для шифрування декількох повідомлень (або, що ще гірше, зберігати симетричний ключ у коді для прямого використання).
    • Вони можуть навіть вирішити використовувати парольну фразу як ключ безпосередньо, не використовуючи жодних ключових функцій.
  • Вони можуть використовувати RSA для шифрування даних безпосередньо.
  • Вони можуть просто "посолити та MD5" свої паролі, щоб захистити їх. (Якщо ви вважаєте, що столики веселки - це найслабша ланка, подумайте ще раз .)

Просто щоб бути на одній сторінці, жоден із перерахованих вище пунктів не в порядку . Якщо ви цього не зрозумієте, то не варто торкатися криптовалюти 10-футовим полюсом! (AES-256 - це чудове шифрування, але лише якщо ви його правильно використовуєте. "Важливий не той розмір, це те, що ви з ним робите." :-))

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

  • Він не використовує RSA для шифрування даних безпосередньо, а натомість генерує випадковий (симетричний) ключ сеансу на повідомлення (це важливо), і використовує RSA для шифрування цього сеансового ключа.
  • Він використовує функцію виведення ключа для перетворення парольних фраз у ключі. (У мові OpenPGP це називається S2K, але я думаю, що "ключова функція виведення" є більш стандартним терміном.)
  • Він справляється з вибором хорошого режиму, тому ви ніколи не закінчите користуватися ECB.
  • Він обробляє керування ключами для вас, тому вам не доведеться приймати спеціальні рішення про те, які клавіші надійні тощо.

Резюме: якщо ви не експерт з безпеки, і думаєте на рівні AES, або SHA-1, або (не дай бог) MD5, ви робите це неправильно . Використовуйте бібліотеку, написану експертами з безпеки (наприклад, Bouncy Castle), які реалізують протоколи, розроблені експертами з безпеки (наприклад, OpenPGP для шифрування, або bcrypt або scrypt для хешування паролів), а не прокатуйте свій власний.

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


4
приголомшливий сподобалася публікація в блозі, пов’язана з "подумайте знову". chargen.matasano.com/chargen/2007/9/7/…
davidhaskins

+1, але використовувати один і той же симетричний ключ кілька разів добре. Ось для чого призначений IV (інакше він вам не знадобиться).
orip

1
Крім того, Колін Персиваль про скріпт (та іншу) славу має чудову статтю під назвою "Криптографічні правильні відповіді", в якій викладаються криптовалютні рішення, які потрібно прийняти. SSL дуже проблематичний (скасування ключа дуже важко здійснити). Більше інформації тут: daemonology.net/blog/…
orip

@orip Погоджуюся, хоча я б сказав, що використання одного і того ж ключа з іншим IV зазвичай корисніше у випадку, коли ваше повідомлення довше за розмір блоку вибраного симетричного шифру, а не для окремих повідомлень, де у вас не було б контекст для відстеження IV, використовуваних для попередніх повідомлень. Також погоджуйтеся зі статтею Коліна Персіваля.
Кріс Єстер-Янг

1
@Ajoy Я змінив посилання на щось більш актуальне.
Кріс Єстер-Янг

14

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

Основні сфери безпеки, які ви, безумовно, повинні знати, як веб-розробник:

  1. Введення SQL Це, мабуть, єдина найнебезпечніша діра, яку веб-розробник може пробити в системі.
  2. Перехресні сценарії та файли cookie.
  3. Спам-боти та капчу.
  4. Введення SQL Не можна підкреслити, наскільки це важливо.

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

@ user1525 Це я мав на увазі як основи криптографії. Вам точно не потрібно знати, як насправді працює будь-який алгоритм шифрування.
biziclop

Я ціную відповідь і погоджуюся щодо ін'єкцій SQL та інших атак, але мене справді питали про криптографію.
davidhaskins

2
@davidhaskins Так, я просто думав, що це варто вказати, тому що кожен рівень базується на попередньому. Знати, як працює AES, нічого не варто, якщо ви не зможете захистити свою програму на більш базовому рівні. На мій досвід, це пастка, в яку потрапляють багато розробників (я робив це кілька разів), щоб сконцентруватися на шифруванні і втратити з поля зору свою роль у довгому ланцюзі безпеки.
biziclop

4

Я пам’ятаю, як бачив цю розмову під назвою « Що потрібно кожному інженеру знати про безпеку та де це навчитися» , оратором є Ніл Дасвані, і саме те, що він дав Google Tech Talk, може стати гарним місцем для початку!

Хоча це не стосується лише веб-програмістів, можливо, питання має бути перейменовано у розділ "Що повинні знати програмісти про безпеку?" так як їм не потрібно знати більше, ніж основи криптографії (наскільки це цікаво)


2

Криптовалюта стане в нагоді в багатьох ситуаціях. Приклад, який ми використовували, - це шифрування файлу cookie сесії, створеного та встановленого хостом Win / IIS для використання на хості LAMP.

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


2

На мою думку, ви повинні знати все про криптовалюту, про що буде знати хтось, хто атакує ваш код. Ви повинні розуміти хеші, сіль, невипадковість випадкових випадків, основні алгоритми шифрування (RSA, 3DES, AES тощо), SHA-1 / MD-5 / та ін. Вам не потрібно запам’ятовувати їх, але ви повинні принаймні знати, що ефективність алгоритму хешу та як зробити його сильнішим. Ви повинні знати, що таке зіткнення та помилкові позитиви. Ви не повинні мати змогу декламувати алгоритми шифрування, але вам слід ознайомитись із їхніми орієнтирами, які з них ідеальні для сценаріїв. Ви повинні мати можливість описати та пояснити симетричне та асиметричне шифрування та коли їх використовувати. Ви повинні знати, що таке PKI і як він використовується. Ви повинні знати, що таке орган сертифікації та як він взаємодіє з вашими серверами.

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

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


2

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

Див. Як безпечно зберігати пароль для отримання додаткової інформації.


0

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

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

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