За криптирането на важни данни в СУБД и кода.

[Stilgar]

Нещо ме съмнява да получиш много смислени въпроси. Я обади как се прави симетричната криптография в примера с CC номерата в базата. Не че нещо ама това съм го правил в един проект (не беше мое решение и всъщност беше за пароли, но някой хора над мен настояваха, че е много гадно като си забравиш паролата да ти пратят нова вместо твойта си). Все пак не се сещам за очевидно по-добри начини за това изпълнение.


^{//wuser промяна на заглавието}

[gat3way]

Ами зависи от реализацията - предполагам си ползвал общ ключ за това, хардкоднат някъде в кода. Това може да се направи със stream cipher като RC4, което е фатална грешка или с блоков шифър, което пак би било донякъде  проблемно ако се ползва ECB и алгоритъм с малка големина на блока като DES. В случаят с stream cipher-а, регистрираш потребител с някаква достатъчно дълга парола. XOR-ваш оригиналната парола с криптираната, получаваш keystream-а. XOR-ваш keystream-а с която и да е друга чужда криптирана парола, получаваш оригиналната им парола в чист вид.

Ползването на блоков шифър в ECB не е толкова фатално, но ти дава възможност да "отгатваш" кои пароли споделят общи неща или при повече късмет да отгатваш (част от) паролите на хората.

[Stilgar]

Изпуснах те. Не знам какво е steam cypher. Вече съм забравил но предполагам, че съм ползвал Rijndael алгоритъм и да key-а беше hardcode-нат в кода. Аз нещо не разбирам как може изобщо да е сигурно такова нещо при положение, че key-а сам по себе си не е по-сигурен от базата щото все пак трябва да е някъде в системата. Аз не разбирам много от криптография, но знам основното правило, че сигурността на криптирането всъщност произтича от сигурността на key-а. В крайна сметка key-ът е там някъде в системата. Ако някой има достъп до системата ще изкопа key-а и готово. Това не важи за хеширани пароли например щото там операцията е необратима.

[gat3way]

Има два вида симетрични шифри - поточни и блокови. Поточните грубо могат да се оприличат на един PRNG - seed-ваш го с началната стойност (ключа) и това ти генерира поредица от стойности, уникална за ключа (keystream). Този keystream го XOR-ваш с plaintext-а и получаваш ciphertext. Когато искаш да декриптираш, отново "seed"-ваш с ключа, генерираш поредицата числа, XOR-ваш ги с ciphertext-а и получаваш plaintext-а. Това работи защото:

(P xor K) xor K  =  P xor (K xor K)  = P xor 0 = P

Проблемът е че ако имаш P и (P xor K) много лесно можеш да вземеш K. Ако всички пароли са криптирани с един и същ ключ, тогава K се преизползва за всички и тогава е елементарно да вземеш плейнтекст паролите като ги XOR-неш с вече известното K.

Другият тип симетрични шифри са блоковете (Rijndael е такъв случай). Там нямаш keystream, с който XOR-ваш байт по байт плейнтекста, а оперираш върху блокове от плейнтекста с фиксирана дължина (примерно 128-битови блокове). Там има други въпросителни, като например режима на операция (всеки блок за себе си или нещо навързано). Ако е всеки блок за себе си (ECB) тогава има известни проблеми, примерно че е лесно дали паролите (част от паролите) са едни и същи за различните потребители.


Иначе няма как да е по-сигурно, човек сдобие ли се с ключа, всичко заминава. Симетричната криптография не е много добра идея за пазене на пароли, в този си вид. Разбира се, можеш да подходиш по друг начин и вместо да ползваш отделен хардкоднат ключ, за да криптираш паролата, можеш да ползваш паролата като ключ за криптиране на някакъв фиксиран (примерно нулев) блок. Това е далеч по-сигурно, защото ако лошият се сдобие с контрол върху системата, няма как лесно да разбие паролите. Обаче по този начин също така губиш и възможността да възтановяваш забравените пароли. На практика, нещата стават почти същите като с хешираните пароли. Ползването на хеш алгоритмите е по-добра идея обаче, от performance гледна точка най-малкото. После, ако ползваш симетрична криптография в такъв вид, трябва да решаваш още един проблем - ако директно ползваш паролата като ключ, дължината на ключа е равна на максималната дължина на паролата. Примерно блоковия алгоритъм работи с 128-битови ключове - максималната дължина на паролата става 16 символа. Има разни схеми, по които част от тези недостатъци могат да се решават, но като цяло е доста по-удобно с еднопосочен хеш алгоритъм.

[Stilgar]

А, да, аз симетричното криптиране на паролите го направих щото не бях в позиция да споря повече не че смятам, че така се прави. Обаче за това с номерата на кредитните карти просто не виждам друг начин в крайна сметка key-ът трябва да е наличен в системата за да се върне обратно plaintext-ът. Реално пазиш се само от ситуацията, в която ти налазят базата, но не и самият код. И сега не разбрах при block cypher и хардкоднат key могат ли да декриптират паролите ако налазят само базата?

[gat3way]

В случая с кредитните карти може да се жертва малко сложност за сигурност. Примерно може да се ползва асиметрична криптография - уеб приложението ги пази в базата криптирани с публичен ключ, отделна машина, dedicate-ната за транзакциите с payment processor-а ги декриптира с частния  ключ преди да ги прати. Тогава ако потрошат уеб сървъра, няма да могат да декриптират номерата на картите. Но това не пречи да атакуват и другата машина и да се сдобият с частният ключ, просто сложността скача.

[Stilgar]

Еми да ама така просто местиш проблема на друга машина:)

[gat3way]

Проблемът със сигурността така или иначе не можеш да го решиш генерално. Но това със сигурност ще вдигне летвата за който иска да прави поразии - и да се добере до базата и до файловата система на уеб сървъра, няма да ти компрометира вече съществуващите записи с номера на карти. За новопостъпващите оттам нататък  вече...не е много сигурно.

[echeveria]

Нямам си на представа от де сте започнали темата, ма и аз да се изкажа (неподготвен). Преди време (ма отдавна беше де) трябваше да правя някво такова дето паролите да не са на достъп до полезрението на апача. Решението не го намерих аз ама си работеше без проблеми. Самото приложение си бачкаше на рнр обаче базата с паролите бе на част от дисковете до която апача няма права за четене и писане и се доставяха от един пърл скрипт който разбира се няма проблеми да се мотае в другата част на диска извън полезрението на апача и рнр. Не знам дали щото никой не се е занимавал да го хаква или щото бе горедолу сигурен, но докато бачкаше никой не е изпищял!