[Delphi] Security problem !!! paswoord lek !

[Cheater]

Als ik m'n .exe in Notepad/kladblok open kan ik daar gewoon het wachtwoord van m'n MySQL database in opvragen.

Wat een superzwakke beveiliging.
Dit moet veranderen. iemand een oplossing?

(A Delphi 5 programm)

[mulder]

Eeeuhm.... kunnen hackers dat bestand openen?

[Cheater]

Man. zelfs m'n vader (nog nooit achter computer gezeten) zou het kunnen vinden. gewoon Find Text: "pass"
en na een paar keer doorklikken zie je het paswoord + inloggegevens van m'n database staan.

[Wouter Tinus]

Op donderdag 28 februari 2002 23:12 schreef Cheater het volgende:
Man. zelfs m'n vader (nog nooit achter computer gezeten) zou het kunnen vinden. gewoon Find Text: "pass"
en na een paar keer doorklikken zie je het paswoord + inloggegevens van m'n database staan.

Er zijn wel programma's die je .exe files encrypten. Zoek maar eens op "packers" .

[mulder]

Tja... dan moet je misschien dan geen hackers op je computer laten. Een slot op je deur?

[koffercomputer]

Je moet dan ook het password niet als tekst in de .exe zetten, maar als een soort van gecodeerde ascii waarden.
Stel je pass is ABCD, dan kun je dus zeggen: pass:="ABCD";
of je zegt pass:=chr(65)+chr(66)+chr(67)+chr(68); bijvoorbeeld. En zo zijn er nog wel meer manieren.

[is wel heel simpel hoor, en makkelijk te kraken]

[Cheater]

nee nee. dit programma is nog niet verspreid. maar dat gebeurd dadelijk wel. Maar ik wil niet dat ze achter m'n wachtwoord kunnen komen.
PS. dit heeft niet zoveel met hacken te maken vindt ik.

[mulder]

Dat bestandje word niet meegelevert bij je programma neem ik aan. Tenzij je de MySQL server op elke client installeert.

[Wouter Tinus]

Ik hoop trouwens dat je een beveiligde verbinding gebruikt naar de database-server, omdat anders - zelfs als je dat wachtwoord in de .exe goed verstopt hebt - iedere gebruiker alsnog een packetsniffer aan kan zetten en je wachtwoord kan lezen.

Daarnaast is het aan te raden om voor dat programma een speciale account te maken in je DBMS, met zo min mogelijk rechten.

[Wouter Tinus]

En de allerbeste tip: maak een apart serverprogramma dat contact heeft met de database. Je clients rechtstreeks op de database laten werken is in de meeste gevallen niet de beste oplossing.

[mulder]

Op donderdag 28 februari 2002 23:26 schreef Wouter Tinus het volgende:
En de allerbeste tip: maak een apart serverprogramma dat contact heeft met de database. Je clients rechtstreeks op de database laten werken is in de meeste gevallen niet de beste oplossing.

Dit is nieuw voor mij, zo je dit iets kunnen toelichten? Waarom?

[Wouter Tinus]

Voor de beveiliging alleen al zou ik niet willen dat er SQL rechtstreeks naar de database toegestuurd kan worden, of dat de database rechtstreeks aan het internet hangt.

Daarnaast: wat doe je als je een bug ontdekt in je client? Of je databasestructuur wil aanpassen/uitbreiden? Misschien moet je upgraden naar een andere database, of verhuist je database een keer. Met een aparte server tussen client en database blijft het aantal keren dat de gebruiker een nieuwe client moet installeren beperkt.

Waarschijnlijk gaat het hier om een klein projectje waarvoor een extra applicatie te veel moeite is, maar voor een groter project waar beveiliging belangrijk is zou ik persoonlijk toch voor een middle-man gaan.

[mulder]

Dan nog, wat doet die middle man dan? De SQL controleren? Username en Password nog een keer controleren? Wat als er bug in je middle man zit? Ik zie het als een overbodige extra laag. Net zoiets al 2 firewalls installeren.

[Wouter Tinus]

Op donderdag 28 februari 2002 23:51 schreef Don Facundo het volgende:
Dan nog, wat doet die middle man dan? De SQL controleren? Username en Password nog een keer controleren? Wat als er bug in je middle man zit? Ik zie het als een overbodige extra laag. Net zoiets al 2 firewalls installeren.

Neuh, er wordt dan geen SQL van client naar server gestuurd, en ook geen wachtwoord. Alleen opdrachten. De client roept naar de server "hej, ik wil de gegevens van klant 10!". De server verbindt vervolgens met de database, stelt de SQL samen en stuurt de gegevens in een voor de client leesbaar formaat terug.

Een bug in de middle man is natuurlijk ook niet prettig, maar kan wel snel opgelost worden en is dan meteen voor alle clients gefixed. Als alle code in de client zit moet iedereen updaten bij iedere bug.

[mulder]

Ah ja, daar zie ik wat meer in, heb ik zelf ook wel eens overnagedacht, want dan zou het oa mogelijk zijn om een totaal andere (merk..type..euuh) database er onder te hangen. Maar vaak in de praktijk niet echt nodig.

[Wouter Tinus]

Op vrijdag 01 maart 2002 00:00 schreef Don Facundo het volgende:
Ah ja, daar zie ik wat meer in, heb ik zelf ook wel eens overnagedacht, want dan zou het oa mogelijk zijn om een totaal andere (merk..type..euuh) database er onder te hangen. Maar vaak in de praktijk niet echt nodig.

Nee, dat zei ik al, voor kleine dingen is het te veel werk . Maar alles is natuurlijk beter dan het db-wachtwoord in plaintext in de .exe zetten .

[Infinitive]

Als ik bij de ODBC-gegevens de SQL-Trace optie aan zet, dan worden alle SQL-functie aanroepen gelogt, waaruit je de username en wachtwoord ook kan halen.

Weet ik overigens niet helemaal zeker, dus pin me er niet op vast

Maar dat zou dus wel suggereren dat het niet uit maakt of je het password wel of niet in je exe-file zit.

Of wat denk je van een vervanging van de SQL-dll's in windows door een dll die hetzelfde doet maar ook nog eens bij het connecten het wachtwoord wegschrijft in een filetje en vervolgens de originele connect functie aanroept?

[Delphi32]

Ik heb dit ook eens bekeken, en geconstateerd dat je password idd rechtstreeks in de .exe komt, als je de TDatabase-component (of afgeleide hiervan) designtime voorziet van username + password.
Het probleem is er ook nog wel als je het password en username runtime door een functie laat invullen; ook dan belanden variabele en waarde van deze twee properties in de symbol table en zijn dus via een hex editor (of desnoods notepad) te achterhalen, alleen wat lastiger. Encoden met Chr(x) + Chr(y) heeft weinig zin ben ik bang.
Een heel aardige verberg-methode is de volgende:

code:

function CanConnectToDatabase: boolean;
begin
  MyDatabase.Username := TBlowFish.Decode('ditiseenencryptedpassword', GetDecryptCode);
  //herhaal voor Password
end;

Wat ik dan doe is middels een proggie mijn gewenste password laten encrypten met een 'magic string'. De 'magic string' maak ik dan in code het result van de function GetDecryptCode. De ge-encrypte versie van mijn password komt dan in plaats van 'ditiseenencryptedpassword', en de TBlowFish.Decode function decodeert het encrypted password met behulp van de 'magic string'. Dit is nog steeds te achterhalen, maar alleen als je thuis bent in debugging tools als SoftIce.

[whoami]

Idd, de strings kun je gewoon in iedere exe zien als je die in een hex-editor ofzo stopt.

Wat ik dus doe, is (zoals velen het hier al gezegd hebben), m'n username en pwd niet gewoon in m'n exe te zetten maar als een gecodeerde waarde. En dan voor je uw databank connectie opent doe je het volgende:

code:

dbStd.Params.Add('User=' + Decrypt('AC44FEBB32');
dbStd.Params.Add('pwd=' + Decrypt('12FDCCA23');

dbStd.Open();

(dbStd is een TDatabase component).

[raptorix]

Ook decoden heeft geen enkele zin, als je gewoon een http proxy er tussen zet heb je alsnog het password te pakken, wat je moet doen is de database de juiste rechten geven, security bouw je niet alleen in je applicatie in maar juist ook in je database, je kan per database object de users specificeren, jammergenoeg zijn er maar weinig ontwikkelaars die hier gebruik van maken, in ontwikkeling gebruikt men gewoon de administrator rechten, als het tegen het eind loopt is het vaak haastwerk en vergeet men de rechten van applicatie te wijzigen en gebruikt men nog steeds administrator als user, kortom laat je db de rechten bepalen en niet je applicatie.

[Delphi32]

Op vrijdag 01 maart 2002 10:56 schreef raptorix het volgende:
Ook decoden heeft geen enkele zin, als je gewoon een http proxy er tussen zet heb je alsnog het password te pakken, wat je moet doen is de database de juiste rechten geven, security bouw je niet alleen in je applicatie in maar juist ook in je database, je kan per database object de users specificeren, jammergenoeg zijn er maar weinig ontwikkelaars die hier gebruik van maken, in ontwikkeling gebruikt men gewoon de administrator rechten, als het tegen het eind loopt is het vaak haastwerk en vergeet men de rechten van applicatie te wijzigen en gebruikt men nog steeds administrator als user, kortom laat je db de rechten bepalen en niet je applicatie.

mmm het is lastig om een klein stukje te quoten uit een post die slechts 1 zin lang is
Maar je hebt volledig gelijk: een password is altijd nog te sniffen en dan ben je alsnog de pineut. Beveiligen op db-level is absoluut noodzakelijk maar helaas een ondergeschoven kindje.

Maar ja, als je vanuit je code een user wilt aanmaken op je database (en dat wil je als je geen maatwerk app maakt maar bv een desktop achtig geval) dan heb je alsnog het password van de administrator nodig. Dat heb je meestal ook als je db structuurwijzigingen ondergaat. Dan kan je ervoor kiezen om het wachtwoord iedere keer opnieuw in te laten typen, je kan het ook in de registry opslaan (ECHT gezien bij een app, en nog unencrypted ook )

[mulder]

Op vrijdag 01 maart 2002 12:24 schreef Delphi32 het volgende:
Maar ja, als je vanuit je code een user wilt aanmaken op je database dan heb je alsnog het password van de administrator nodig.

Ja dat is ook niet de bedoeling natuurlijk,je moet een admin met een admin account gebruiken om users aan te maken.

[Delphi32]

Op vrijdag 01 maart 2002 12:34 schreef Don Facundo het volgende:

[..]

Ja dat is ook niet de bedoeling natuurlijk,je moet een admin met een admin account gebruiken om users aan te maken.

Stel ik distribueer een app die gebruik maakt van een database die eventueel ook over een netwerk benaderd moet kunnen worden. De app wordt dus single- en multi-user ineen, maar het meest waarschijnlijke gebruik is single-user.
Stel mijn ontwerper (lees: ik als ontwerper ) wil geen admin tooltje hebben bij mijn app, maar alles moet onzichtbaar voor de gebruiker gebeuren. Dus na de installatie van de database (met default dus zeer onveilig wachtwoord).
Dan moet onder water het volgende gebeuren:
1. password administrator veranderen (dit mag de gebruiker invoeren)
2. user aanmaken voor mijn applicatie (password administrator nodig maar dat had ik uit stap 1)

Betekent dus dat mijn app op gezette tijden (nl bij de start, bij het toevoegen van gebruikers en bij het uitvoeren van database updates) het admin password moet gaan vragen aan de gebruiker. Want onthouden/opslaan is niet de bedoeling natuurlijk.

En dan maar hopen dat de gebruiker het in stap 1 ingevoerde wachtwoord onthouden heeft

[igmar]

Als ik m'n .exe in Notepad/kladblok open kan ik daar gewoon het wachtwoord van m'n MySQL database in opvragen.

Wat een superzwakke beveiliging.
Dit moet veranderen. iemand een oplossing?

(A Delphi 5 programm)

Meer domme programmeur in dit geval. MySQL accept ook wachtwoorden in hash vorm. Nog steeds niet waterdicht, maar beter als gewoon plain in de .exe

Kan dat niet dan kun je zelf met een klein loopje dat wachtwoord onleesbaar maken.

[FireWire]

Ik weet niet of het ook werkt in delphi (of kan)

text = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'

pass = mid(text,8,1) + mid(text,15,1) + mid(text,9,1)

pass is dan hoi

hoop dat je er wat aan hebt..

[Verwijderd]

Op vrijdag 01 maart 2002 16:07 schreef Delphi32 het volgende:
Stel mijn ontwerper (lees: ik als ontwerper ) wil geen admin tooltje hebben bij mijn app, maar alles moet onzichtbaar voor de gebruiker gebeuren. Dus na de installatie van de database (met default dus zeer onveilig wachtwoord).
Dan moet onder water het volgende gebeuren:
1. password administrator veranderen (dit mag de gebruiker invoeren)
2. user aanmaken voor mijn applicatie (password administrator nodig maar dat had ik uit stap 1)

Wanneer je het voor het "grote boze internet" geheim wilt houden, is 't aardig veilig te houden via een secure connectie (https, SSL, VPN).
Wil je 't ook binnen je eigen netwerk beveiligen, dan is de methode van een "middle man" eigenlijk de enige oplossing. En die "middle man" moet dan ook nog een niet te sniffen verbinding met de database hebben (eigen dedicated netwerkverbinding, of hij moet gewoon op de database server draaien).

Die "middle man" is een fraaie oplossing, maar die schrijf je niet op een regenachtige zondagmiddag. Daar zit een flink traject van ontwerpen en afwegen achter, heb ik gemerkt...

[Delphi32]

Op vrijdag 01 maart 2002 22:43 schreef Afterlife het volgende:

[..]

Die "middle man" is een fraaie oplossing, maar die schrijf je niet op een regenachtige zondagmiddag. Daar zit een flink traject van ontwerpen en afwegen achter, heb ik gemerkt...

Komt bij dat je voor de reeds verkrijgbare middleware meestal ook een vracht dollars moet meebrengen om de boel legaal te houden.
* Delphi32 denkt met veel plezier terug aan zijn MIDAS-projecten

Dus gezien de kosten is middleware lang niet altijd haalbaar. Terwijl het wel degelijk een goed alternatief voor lastige constructies is.

[Verwijderd]

Op zaterdag 02 maart 2002 00:54 schreef Delphi32 het volgende:
* Delphi32 denkt met veel plezier terug aan zijn MIDAS-projecten

Dat heeft ons wel de ClientDataset gebracht, al moet ik toegeven dat ik die nog nooit gebruikt heb...

Dus gezien de kosten is middleware lang niet altijd haalbaar. Terwijl het wel degelijk een goed alternatief voor lastige constructies is.

Wanneer je een project vanaf het begin kunt inrichten, zonder 'legacy' zaken en zo, is middleware prima haalbaar, zonder meerkosten t.o.v. standaard client/server benaderingen. Je kunt dan nl. die agent, broker, of hoe je 'm ook wilt noemen zelf schrijven, en wanneer je dat ding ook nog alle "business logic" laat afhandelen, ontwikkelt 't nog 's sneller ook!

De client houdt zich alleen bezig met de user interface en de directe validaties ("klopt die datum wel?"), de server beheert de data maar ook niet meer dan dat (triggers en stored procs zoveel mogelijk beperken, scheelt ook wanneer je een andere database moet ondersteunen).

En daartussen zit "het hart" dat alle regels bepaalt, maar dat zich aan de ene kant niet hoeft te bekommeren met hoe 't er op het scherm uitziet, en aan de andere kant niet met hoe 't wordt opgeslagen.

[jelmervos]

En een andere UI (Internet) zou ook kunnen gebruik maken van die 'middle-man', en daarmee ook zijn buisness rules toch?


* jelmervos is momenteel druk bezig met een DCOM server (+ een klein deel van de UI) voor zijn werk en het werk zeer goed allemaal.
Security gaat via Windows 2000, maar heb daar weinig mee te maken eigenlijk.


_{Namen e.d. heb ik een beetje veranderd/weg gehaald}

[jelmervos]

Overigens is dit toch niet echt een Delphi 'probleem'?

toch? toch? toch?

[Verwijderd]

Op zaterdag 02 maart 2002 01:29 schreef jelmervos het volgende:
En een andere UI (Internet) zou ook kunnen gebruik maken van die 'middle-man', en daarmee ook zijn buisness rules toch?

Dabedoelik!
Bij mij is dat nu ook vooral (D)COM, maar ook SOAP etc. (maar dan zit er weer een laagje tussen). Jammer dat Delphi geen prettige CORBA IDE heeft...

[jelmervos]

SOAP is toch stateless?

[Cheater]

eeew. hoeveel km's zijn we van het topic verwijderd?

Vraag niet waarom, maar ik kies voor direct connection naar de database. Het is immers maar voor een 20tal mensen bedoeld. Er kunnen dus maar 20 mensen inloggen en de rest heeft pech, die komt niet in het programma.
maar m'n password moet natuurlijk niet uit m'n programma 'vallen' . snap je?