Криптирана база данни - мотики за настъпване?

Ей това като идея го давам само: ако хешираш и потребителските имена, тогава форума ще е и анонимен.

И как клиент се връзва към криптната база? Пак с юзър и парола? сигурно и още една парола предава за декриптиране? И от какво се пазиме? Някой с взлом да не изнасили админа и открадне физически райда с базата тип мисията невъзможна?

Че то prepare на заявката е задължително за всеки SQL. Тъй като по същество представлява компилация на заявката във вид удобен за изпълнение. Какво общо може да има това конкретно с SQLite или асемблер???

И какво общо има с хеширането на паролите??? Паролите се хешират съвсем не за да не ги видят външни хора, а на първо място за да не изкушават вътрешните хора. Криптирането на базата данни никак не изключва хеширането на паролите.

Дам, има ги на всякъде и sql инжекциите също ги има. Та "аз сън защитен" не е много вярно. Винаги може да се открие бъг, и това че за сега такъв няма не ти гарантира, че няма да се появят проблеми в бъдеще.

Относно паролите - точно за това ти говоря - практически е безпредметно да криптираш носителя. Защитават се данните в него. Когато не ти трябва да ги ползваш директно, можеш да ги хешираш (това важи в пълна сила не само за паролите а и за IP адреси, ЕГН-та и изобщо за данни който ти трябват само за валидиране). Когато обаче ти трябват ги криптираш, като в зависимост от това кой ще ги ползва се реализира схема за подаване на ключът. Това го коментирахме когато извади идеята за частните теми. Ползваш асиметрично криптиране и казваш, че единия ключ е за четене, другия за публикуване. Като и двата ключа можеш да ги направиш сертификати които да се издават за конкретни потребители. Така ще имаш възможност да определяш кой сертификати са невалидни (да отнемаш права).

Тия зашити не се правят само за да не се изкуши някой на сървъра. Така се гарантира, че при бъг в приложението потребителите му няма да получат достъп до данни които не са за тях. SQL инжекциите са пример за подобен бъг.

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

@stewie: В случая говорим за SQLite - тя не е клиент-сървър, а базата е просто файл на диска. Тоест говорим за криптиран файл.

@thrawn: В общи линии съм съгласен, със забележката, че IP4 адреси е безсмислено да се хешират. Пространството на адресите е твърде малко и хеша се реверсва много бързо и лесно. Същото май важи и за ЕГН-тата.

затова не се прави "чисто" хеширане, асе ползват схеми като pbkdf2 където освен данните които хешираш се подава и ключ, така че без ключа да не можеш да познаеш какво е хеширано

Въпроса не е в това дали ще намериш ЕГН-то или не (при 6 числа за дата на раждане, едно за контролна сума, код на населено място остава само да нацелиш поредния номер, като вариантите падат на половина заради полът). Идеята е, че при изтичане на данните трябва да си сигурен, че егн-тата от базата данни няма да лъснат публично.
Тия данни основно се ползват за валидация. Да речем правиш някакъв център за обслужване на клиенти. Звъни клиент по телефона и ти му викаш - кажете си ЕГН-то, номера на личната карта или там каквото друго ти трябва. Той го диктува и ти проверяваш в базата данни за съвпадение. Или идват милиционерите и ти казват - я ми дай всички постове от тоя и тоя ИП адрес.

Та ако ще криптираш трябва да намериш баланса. Какво има смисъл да се криптира и какво не. Също така, трябва да се съобразиш с GDPR (който практически изисква именно криптиране на личните данни) и да решиш кой данни ще замениш с техни хешове (за да не се водят вече лични данни и ти да не се налага да ставаш оператор на лични данни).

Ако си убеден че можеш да се оправяш с ключовете, най-добре си я криптирай. Има си трикчета после да обфускираш ключа (тъй като ще ти трябва като искаш да ползваш базата) и да се предпазваш от дебъгинг, ОИ и пясачници, но за повечето такива не издържат дълго.

В същото време ще е грозно някой да удари един strings и да му изкача ключа. Един съвет, недей пиши приложението на C# или .net. Преди 2 седмици попаднах на един Password Manager - etatsdrowssaP, клиента ми вика "имаме сигурен криптиран меринджей за паролите". Апликацията писана на .net, декомпилирах го до сорса(dotPeek) видях къде са скатани 4те тайни, copy&paste, copy&paste, и успях да им декриптирам бекъпите (profit).

Естествено този метод не е универсален, но според зависи случая, модела на заплаха варира. Гугъл миналата година направиха няколко демота на enclave апликации, но не съм убееден че случая е същия.

И за финал, пусни strings да видим дали ще изкочи ключа ако си направил имплементацията.

(щях да прикача скрииншоти ама не уви, трябва съм ги бил качил някъде предварително, слабо)