Zahešované heslo v connection stringu k PostgreSQL

[CPU]

Ježiš
Ježiš
Ježiš

Chtěl jsem ti dát seznam toho, proč jsi vedle jako ta jedle, ale nebudu se namáhat.

neměl zbytečná práva do db... heslo praskne..

Rozhodně! To platí vždycky, protože "co kdyby", ale tak tragicky bych to s tím prasknutím neviděl, spousta mnohem horších čuňáren (Heslo napsané v plaintextu ve skriptu a podobně) nikdy nepraskla.

Taky bych byl pro SSO, ale SSO a řízení uživatelů je někdy nejen nevhodné, ale navíc i mimořádně zdlouhavé.

[Reklama]

[_Jenda]

Tool pro mnohem více lidí bez možnosti narušení CIA: https://pypi.org/project/aes-cipher/

Reality check: dám si breakpoint na pgxx::connection a přečtu si jaké dostává parametry - jakým způsobem je program vymyslel je mi úplně jedno.

Na to tazatele určitě napadne, že tu funkci přejmenuje, aby nešla tak snadno najít. Na to já zareaguji tak, že program zastavím v okamžiku, kdy se začne ověřovat proti databázi a přečtu si stacktrace (všimněte si, že prezentovaný connection string má dost jasný a zjevný formát, takže půjde i třeba jednoduše grepnout v coredumpu programu). Na to tazatele napadne nějaké další geniální řešení.

A to jsme ještě ani nezabrousili do toho, jestli je ten protokol odolný proti MITM, případně jak složité je té knihovně vnutit vlastní certifikát a ten MITM si udělat.

Tazatel se brání proti „útočníkovi“ který dokáže na binárku programu spustit strings, spustit si vlastního postgresql klienta a se získanými údaji se připojit, ale současně je dostatečně neschopný na jednoduchou analýzu běžícího programu.

[CPU]

Musel bych ti bezpečnost vysvětlit od začátku a to zadarmo dělat nebudu.

[czechsys]

Jeste bych upozornil, ze pokud tvurce dotazu chtel posilat hash, tak se zrejme bavi o md5 hashovani, coz je dira sama o sobe. Postgesql od 14/15 ma default scram-sha-256, takze zpusob overeni uzivatele je vyrazne zmenen a postup pro md5 tam jiz nefunguje.

[Vít Šesták (v6ak)]

Jak již bylo zmíněno, kdyby k autentizaci měl stačit hash hesla, pak by se ten hash vlastně stal heslem. Tudy cesta nevede.

Možná chcete mít nějakou embedded databázi, kterou budete dodávat přímo s aplikací, která by se zřejmě spouštěla a ukončovala zároveň s aplikací a která by se nepoužívala na nic jiného. To má lepší řešení než hardcodované heslo. Například se heslo může generovat náhodně a uložit do souboru (s vhodně omezeným oprávněním), případně na *NIXech by asi šlo nechat Postgres poslouchat jen na socketu, který by měl vhodně omezená oprávnění. Toto tahám z hlavy, možná by Google nasměroval i k jinému řešení.

[Reklama]

[jjrsk]

Musel bych ti bezpečnost vysvětlit od začátku a to zadarmo dělat nebudu.

To by sis o tom musel nekde neco precist, ze?

Harcoded heslo je naprosto nejvetsi volovina kterou kdo muze udelat. Ve 100% pripadu to dopadne tak, ze nekdo to heslo zmeni, jednoduse proto, ze ty 3 pismenka uz neodpovidaji firemni policy, a pak bude resit, kde to ma nastavit ty aplikaci (pripadne ta aplikace proste jen vsem prestane fungovat).

Xorovat heslo, kdyz to za stejnou cenu muzu udelat dobre, je opravdu uzasnej napad ...

Takze, bud mam aplikaci, kterou pouzivaji uzivatele, a pak neresim aplikaci, ale toho uzivatele (to vubec neznamena, ze musi nekde zadavat nejaka hesla, treba si prevezmu jeho prihlaseni ze systemu).

Nebo mam nejakou servisu, pak resim autorizaci ty konkretni servisy, bez hesel.

[Ivan Brezina]

Ahoj,
prosím, potřeboval bych poradit, jak se řeší situace, kdy do prográmku v c++ potřebuju zkompilovat hardcoded heslo pro připojení k (postgresql) databázi.

S použitím předpřipravené knihovny pgxx definuji connection string:

Kód: [Vybrat]

std::string connectionString = "host='server_ip_address' port='5432' dbname='database_name' user='username' password='Secret_12345'";

Pokud prográmek zkompiluju, heslo jde z binárky přečíst a to je problém.
Existuje nějaký nástroj, který by uměl pracovat jenom s HASHem hesla v connection stringu namísto vepsaného hesla?

Nebo jakým způsobem se tohle správně provádí?
Děkuji za radu.

Nenapsal jsi jestli tvoje aplikace pobezi na Windows anebo na Linuxu.
Pokud na Windows tak by doporucil jeste jednou se podivat na SSO, protoze AD udela hodne prace za tebe a rozbehat Kerberos autentizaci na PostgreSQL databazi je celkem jednoduchu.

Pokud to pobezi na Linuxu, tak bych doporucil aby tvoje aplikace mela SUID bit na "nobody". Aplikace s SUID bitem muze debugovat tak max. root. Beznej uzivatel kterej aplikaci spusti to bude mit mnohem tezsi se k heslu v aplikaci dostat.

[Vít Šesták (v6ak)]

Dost záleží na cílovém prostředí. V některých případech může SUID udělat svoje, ale uživatel nesmí mít možnost se dostat k binárce:

1. Musí mít oprávnění execute, nikoli read.
2. Nesmí mít binárku ke stažení.
3. Cokoli co zavání fyzickým přístupem k počítači, kde binárka běží, zavání průšvihem. Od čtení disku, bootu jiného OS, až po cold boot attack. Ano, vše lze nějak řešit, ale je potřeba na to myslet.
4. IIRC psaní aplikací, které počítají se SUID, je někdy trochu minové pole. Zkušenost nemám, ale rozhodně si to chce něco trochu předem nastudovat.

[RastikJ]

skus pozriet AWS Secret Manager a jeho implementaciu, podla mna najlepsie a najbezpecnejsie riesenie, tj. mimo ine aj automaticka zmena hesla po definovanom casovom obdobi