BG Development


Страници: (3) 1 2 [3]   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Криптирана база данни - мотики за настъпване?
SuN
Публикувано на: 19-09-2019, 07:24
Quote Post


Group Icon
Име:
Група: Администратор
Ранг: Почетен член

Мнения: 10601
Регистриран на: 27.01.05



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


--------------------
Само аз не троля.
Всички коментари са плод на художествена измислица и нямат общо с действителни и недействителни лица, събития и факти.
PMEmail Poster
Top
stewie
Публикувано на: 19-09-2019, 08:47
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 6577
Регистриран на: 14.07.16



И как клиент се връзва към криптната база? Пак с юзър и парола? сигурно и още една парола предава за декриптиране? И от какво се пазиме? Някой с взлом да не изнасили админа и открадне физически райда с базата тип мисията невъзможна?
PM
Top
thrawn
Публикувано на: 19-09-2019, 08:55
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2812
Регистриран на: 17.01.17



QUOTE (johnfound @ 19-09-2019, 07:19)
QUOTE (thrawn @ 19-09-2019, 07:20)
Открил е prepared statements ите и явни смята, че те са нещо уникално за sqlite и/или асемблер icon_smile.gif
Но въпреки това, най-вероятно хешира паролите. Но пък смята, че потребителските имена трябва са седят в криптирана база данни.

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

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

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

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

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

А защитата на целия носител ти гарантира единствено, че ако той попадне в чужди ръце няма да може да го ползва. Само че, шанса някои да ти свие сървъра практически е нулев. А дори това да се случи, ако данните в него са криптирани (чувствителните данни) то е все едно дали тоя някой ще види потребителските имена.
PMEmail Poster
Top
johnfound
Публикувано на: 19-09-2019, 09:02
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7831
Регистриран на: 27.05.04



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

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


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
PMEmail PosterUsers Website
Top
Gamma Goblin
Публикувано на: 19-09-2019, 09:14
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3575
Регистриран на: 21.02.18



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

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

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


--------------------
https://ncase.me/trust-bg/
---
Misanthropy is the general hatred, dislike, distrust or contempt of the human species or human nature. A misanthrope or misanthropist is someone who holds such views or feelings.
---
INTJ’s are good at being very good at everything
---
I have a problem. Let's use Microservices! Now I have 13 distributed problems.
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 19-09-2019, 09:21
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2812
Регистриран на: 17.01.17



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

Та ако ще криптираш трябва да намериш баланса. Какво има смисъл да се криптира и какво не. Също така, трябва да се съобразиш с GDPR (който практически изисква именно криптиране на личните данни) и да решиш кой данни ще замениш с техни хешове (за да не се водят вече лични данни и ти да не се налага да ставаш оператор на лични данни).
PMEmail Poster
Top
d3k4
Публикувано на: 17-03-2020, 19:59
Quote Post



Име: Волдеморт
Група: Потребител
Ранг: Новопостъпил

Мнения: 48
Регистриран на: 23.11.16



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

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

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

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

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


--------------------
When in doubt - encrypt, otherwise be in doubt!
Find me in ZnJlZW5vZGUK
PMEmail Poster
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (3) 1 2 [3]  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0