[VB.NET] Database Wachtwoord versleuteld opslaan

[Armageddon_2k]

Hey mensen, ik zit met een vraag in mn hoofd over het opslaan van wachtwoorden.
En ik hoop dat mede tweakers mij hiermee kunnen helpen.

Ik heb namelijk een vb programma dat samenwerkt met een database.
Stel mijn login is: Admin | Wachtwoord

Uiteraard wil ik dit niet plain text opslaan, dus dit gaan we versleutelen.
Vooruit we salten het nog en gaan het dan encrypten via (bijvoorbeeld):
System.Security.Cryptography.RijndaelManaged
Deze maakt gebruik van een key waarmee je je User/Pass versleuteld op kan slaan.

Maar hoe zorg ik ervoor die niemand achter deze key kan komen?
Want deze key zal ik toch ook ergens moeten defineeren in mijn programma, en nou lijkt me:

Visual Basic .NET:

  Private Const EncryptionKey As String = "45F27Dxx98"

Nou niet echt een veilige optie, en dit is met een reflector natuurlijk veel te makkelijk te achterhalen.

Hoe lossen jullie dit op?

Kleine toelichting (op semi-verzoek)
Het gaat om een applicatie die data in een database opslaat, deze database moet niet te benaderen zijn door 'derden'. Deze applicatie kan op verschillende pc's worden geinstalleerd en gebruikt een voor mij bekend username/password. Mijn probleem is dus het hardcoded opslaan van het wachtwoord.

[Voor 16% gewijzigd door Armageddon_2k op 09-06-2011 18:06]

[Mavamaarten]

Gebruik een X-aantal keer md5 en encrypt de hash nog een paar keer.
Wanneer je checkt op het wachtwoord, voer hetzelfde algoritme uit op de textbox en vergelijk het met de encrypted hash. Dit is redelijk veilig maar toch nog te achterhalen met reflector...

Je kan natuurlijk ook een obfuscator gebruiken (ik geloof dat Skater gratis is / was)

[Armageddon_2k]

Mavamaarten schreef op donderdag 09 juni 2011 @ 16:15:
Gebruik een X-aantal keer md5 en encrypt de hash nog een paar keer.
Wanneer je checkt op het wachtwoord, voer hetzelfde algoritme uit op de textbox en vergelijk het met de encrypted hash. Dit is redelijk veilig maar toch nog te achterhalen met reflector...

Je kan natuurlijk ook een obfuscator gebruiken (ik geloof dat Skater gratis is / was)

Redelijk veilig is niet de bedoeling Het gaat om het principe
Uiteraard kan je (Inception Style), elke keer je versleuteling versleutelen. Maargoed dit is te achterhalen, dit is zelfs voor iemand met gemiddelde vb kennis en een Reflector te doen.

Het gaat hiet uiteraard om een 'best practice'.

Overgens zit er tegenwoordig standaar een dotfuscator in vb als ik me niet vergis.

[Voor 5% gewijzigd door Armageddon_2k op 09-06-2011 16:18]

[Evilbee]

Mavamaarten schreef op donderdag 09 juni 2011 @ 16:15:
Gebruik een X-aantal keer md5 en encrypt de hash nog een paar keer.
Wanneer je checkt op het wachtwoord, voer hetzelfde algoritme uit op de textbox en vergelijk het met de encrypted hash. Dit is redelijk veilig maar toch nog te achterhalen met reflector...

Maar als je het wachtwoord nog wilt gebruiken voor je connectie string naar je database is dat natuurlijk niet mogelijk

Als je het wachtwoord naar de database geheim wilt blijven houden, moet je zorgen dat er nog een data access layer tussen zit (bijvoorbeeld een webservice). Anders kan je het wachtwoord altijd via reverse engineering achter halen.

Armageddon_2k schreef op donderdag 09 juni 2011 @ 16:18:
[...]

Het gaat hiet uiteraard om een 'best practice'.

Best practice is het wachtwoord niet in je applicatie opslaan

[Voor 14% gewijzigd door Evilbee op 09-06-2011 16:19]

[Armageddon_2k]

Evilbee schreef op donderdag 09 juni 2011 @ 16:18:
[...]
Als je het wachtwoord naar de database geheim wilt blijven houden, moet je zorgen dat er nog een data access layer tussen zit (bijvoorbeeld een webservice). Anders kan je het wachtwoord altijd via reverse engineering achter halen.

Okay, stel (wat ook de situatie zl gaan zijn) we hebben het over een lokaal systeem, dus een lokale db, en een lokale applicatie. Dus er is geen mogelijkheid een autentication server oid te gaan neerzetten.

Evilbee schreef op donderdag 09 juni 2011 @ 16:18:
[...]
Best practice is het wachtwoord niet in je applicatie opslaan

Mja... en dan gewoon niet verbinding maken met een database
Veiligste is dan om een "Hello World" applicatie te maken, die compleet iets anders doet wat ik wel

[Voor 24% gewijzigd door Armageddon_2k op 09-06-2011 16:21]

[Evilbee]

Armageddon_2k schreef op donderdag 09 juni 2011 @ 16:20:
[...]


Okay, stel (wat ook de situatie zl gaan zijn) we hebben het over een lokaal systeem, dus een lokale db, en een lokale applicatie. Dus er is geen mogelijkheid een autentication server oid te gaan neerzetten.

Maar wat is het doel dan? Dan je alleen met jou applicatie de data in de database kan benaderen? Dat is volgens mij niet mogelijk, want ik kan toch ook rechtstreeks met die database dan verbinden?

[Alex)]

Lees dit eens door: MSDN: Protecting Connection Information (ADO.NET), en daarna het stukje onder "app.config" bij MSDN: Connection Strings and Configuration Files (ADO.NET)

[Armageddon_2k]

Alex) schreef op donderdag 09 juni 2011 @ 16:23:
Lees dit eens door: MSDN: Protecting Connection Information (ADO.NET), en daarna het stukje onder "app.config" bij MSDN: Connection Strings and Configuration Files (ADO.NET)

Mja ik heb daar eerder naar gekeken en vind het een beetje een farce
Want je kan dan je config file idd encrypten, maar iedereen kan met deze code het net zo hard weer tevoorschijn toveren.

Visual Basic .NET:

Shared Sub ToggleConfigEncryption(ByVal exeConfigName As String)
    ' Takes the executable file name without the
    ' .config extension.
    Try
        ' Open the configuration file and retrieve 
        ' the connectionStrings section.
        Dim config As Configuration = ConfigurationManager. _
            OpenExeConfiguration(exeConfigName)

        Dim section As ConnectionStringsSection = DirectCast( _
            config.GetSection("connectionStrings"), _
            ConnectionStringsSection)

        If section.SectionInformation.IsProtected Then
            ' Remove encryption.
            section.SectionInformation.UnprotectSection()
        Else
            ' Encrypt the section.
            section.SectionInformation.ProtectSection( _
              "DataProtectionConfigurationProvider")
        End If

        ' Save the current configuration.
        config.Save()

        Console.WriteLine("Protected={0}", _
        section.SectionInformation.IsProtected)

    Catch ex As Exception
        Console.WriteLine(ex.Message)
    End Try
End Sub

[Big Womly]

De gebruiker verplichten van een paswoord in te geven voordat hij met de tool kan werken is geen optie?
Als de data beveiligd moet worden met een paswoord, vind ik het ook niet meer dan normaal dat dit niet hard-coded opgeslagen wordt.
Anders kan je evengoed geen paswoord gebruiken.

[Janoz]

Mij is iig nog niet helemaal duidelijk wat nu precies de bedoeling is. De eerste reactie is een goede in de specifieke situatie waarbij je in je applicaties inloggegevens wil valideren. De manier waarop jij vervolgens reageert doet mij vermoeden dat het verschil tussen hashen en encrypten je niet opgevallen is.

Alle overige reacties gaan meer over situaties waarbij je applicatie ergens op in moet loggen. Hierbij hoef je dus niet enkel te weten of het meegegeven wachtwoord goed is, maar moet je daadwerkelijk het wachtwoord zelf weten.

Dus in het kort:

Gaat het om het valideren van gebruikers gegevens, of gaat het om het encrypten van login gegevens voor bronnen waar je applicatie bij moet?

[Woy]

Kijk ook eens naar MSDN: ProtectedData Class (System.Security.Cryptography)

Dit zou je kunnen gebruiken, en dan zou je voor de optionalEntropy parameter eventueel een masterKey o.i.d. kunnen gebruiken.

Als het puur en alleen gaat om het "secure" opslaan van de connection-strings kun je het best de links van Alex) even goed doorlezen.

[Voor 67% gewijzigd door Woy op 09-06-2011 17:04]

[Davio]

Ik denk dat het gaat om het valideren van een login door een ingevoerd wachtwoord te vergelijken met een hashed wachtwoord in de database.

Maar waar de TS tegenaan loopt, is waar je de sleutel opslaat die gebruikt wordt om de wachtwoorden te hashen, een master salt als het ware...

Volgens mij is dat in dit geval niet nodig en kan het gewoon goed als je per user een salt in de database opslaat.

Dan krijg je code als (vereenvoudigd):

C#:

string inputHash = Hash(inputPassword, User.Salt);

if (inputHash != User.Hash) MessageBox.Show("ERROR!");

Dit werkt als boosdoeners niet zomaar toegang hebben tot je database en daar kan je prima voor zorgen.


Het encrypten en decrypten is alleen nodig als de oorspronkelijke informatie ook weer achterhaald moet kunnen worden. Dat is in dit geval niet nodig, omdat we ervan uitgaan dat die informatie in het hoofd van de gebruiker zit.

Die user salt kan je random genereren en opslaan, dan krijg je iets als:

User	Salt	PasswordHash
Japie	#^@#ds32	cde35656ewdede65334
Pietje	hhj322	djhjhjereue3@#67267

EDIT: Als het niet gaat om het valideren van logins, maar om het versleutelen van de login-informatie van de database, kun je ook kijken of je gewoon Windows-logins kunt gebruiken; je maakt immers een VB-programma, dus ik neem aan dat het voor Windows is en je SQL Server oid gebruikt?

Anders moet je inderdaad kijken naar die links van de anderen, dat heb ik in het verleden ook wel eens gedaan, maar ben er nooit echt uitgekomen hoe ik het écht veilig kan doen.

[Voor 31% gewijzigd door Davio op 09-06-2011 17:07]

[Armageddon_2k]

Janoz schreef op donderdag 09 juni 2011 @ 16:52:
Gaat het om het valideren van gebruikers gegevens, of gaat het om het encrypten van login gegevens voor bronnen waar je applicatie bij moet?

Het laatste.
Heb een kleine toelichting gegeven in de startpost.

Woy schreef op donderdag 09 juni 2011 @ 17:01:
Kijk ook eens naar MSDN: ProtectedData Class (System.Security.Cryptography)

Zal hier even een blik op werpen

[Voor 37% gewijzigd door Armageddon_2k op 09-06-2011 18:08]

[sonix666]

Zolang je direct vanuit je desktopapplicatie naar de database toe gaat, dan heeft iedere gebruiker in principe de mogelijkheid om achter je wachtwoord te komen. Je kunt dat allemaal iets moeilijker maken door wat truukjes te doen als encrypten, maar die key is beschikbaar lokaal, anders dan kon je applicatie die niet decrypten.

De enige manier die safe is wat dat betreft is je applicatie op te splitsen in je desktopapplicatie en een backend (web)service waar alleen geautoriseerde gebruikers toegang toe hebben. Alleen die backend service bevat daadwerkelijk de databaselogingegevens.

[tomw]

Door te werken met een backend verschuif je het probleem alleen maar. Want dan heb je weer logingegevens nodig voor die backend..

[sonix666]

tomw schreef op zaterdag 11 juni 2011 @ 22:53:
Door te werken met een backend verschuif je het probleem alleen maar. Want dan heb je weer logingegevens nodig voor die backend..

Ik ben vergeten te zeggen dat die back-end service een onderdeel is wat ergens centraal gedeployed is. Alleen administrators kunnen op die machine. Andere mensen kunnen de service alleen aanroepen. In dat geval moeten die login gegevens geen probleem zijn. En andere mensen die van die service gebruik maken kunnen ook niet direct op de database.

[Voutloos]

^ Juist. Des te minder in de client (cq. de software waar iedereen bij kan) zit, des te minder kan er geklooid worden. Tevens zal de API ook de mogelijkheden beperken tov SQL, want zolang er totale vrijheid van queries is gaan stricte DB permissies je toch echt niet redden.

Uiteraard heb je voor de API ook een authenticatie nodig, en belangrijkste is dat je die per gebruiker uniek maakt, zodat je ook per gebruiker kan autoriseren, loggen en limiteren.

[Herko_ter_Horst]

Je gaat dit niet goed krijgen. Je kunt niet voorkomen dat de ene applicatie wel automatisch kan inloggen op de database en de andere niet. Je hebt namelijk altijd te maken met het feit dat de secret bekend moet zijn in jouw applicatie. Dat betekent dat dat secret eigenlijk geen secret meer is.

Je zult dus hoe dan ook de gebruiker in het verhaal moeten betrekken.

[Armageddon_2k]

sonix666 schreef op maandag 13 juni 2011 @ 11:10:
[...]

Ik ben vergeten te zeggen dat die back-end service een onderdeel is wat ergens centraal gedeployed is. Alleen administrators kunnen op die machine. Andere mensen kunnen de service alleen aanroepen. In dat geval moeten die login gegevens geen probleem zijn. En andere mensen die van die service gebruik maken kunnen ook niet direct op de database.

Ja, maar als je mijn startpost ook leest. Dan zie je dat dit niet een oplossing is. Het gaat hier om 1 systeem bijvoorbeeld een lokale pc. En nou kan je idd wel met een backend gaan werken, maar das niet echt een optie hea.
Je kan moeilijk iemand een backend aanpraten, als hij alleen maar om een stukje software vraagt

Herko_ter_Horst schreef op maandag 13 juni 2011 @ 13:06:
Je gaat dit niet goed krijgen. Je kunt niet voorkomen dat de ene applicatie wel automatisch kan inloggen op de database en de andere niet. Je hebt namelijk altijd te maken met het feit dat de secret bekend moet zijn in jouw applicatie. Dat betekent dat dat secret eigenlijk geen secret meer is.
Je zult dus hoe dan ook de gebruiker in het verhaal moeten betrekken.

Dat was ook mijn conclusie, maar ik hoopte eigenlijk dat er iemand nog een leuke oplossing zou hebben
Helaas is "een gebruiker" in het verhaal betrekken, niet echt een optie. Ik ga puur een stukje software leveren met een database. En ik wil dat alleen mijn applicatie bij de database kan.

[Voor 33% gewijzigd door Armageddon_2k op 14-06-2011 11:23]

[Voutloos]

Armageddon_2k schreef op dinsdag 14 juni 2011 @ 11:19:
Je kan moeilijk iemand een backend aanpraten, als hij alleen maar om een stukje software vraagt

Ik kan dat prima hoor.

Maar goed, je gaat het dus niet waterdicht krijgen dus in dit geval houdt het 'aanpraten' in dat je 2 verschillende implementaties/offertes hebt of zo.

[Armageddon_2k]

Voutloos schreef op dinsdag 14 juni 2011 @ 11:23:
[...]
Ik kan dat prima hoor.

Maar goed, je gaat het dus niet waterdicht krijgen dus in dit geval houdt het 'aanpraten' in dat je 2 verschillende implementaties/offertes hebt of zo.

Mja, het probleem is: ik wil niet dat zij ook in de database kunnen rommelen.
Zij zouden dat best leuk vinden als ze er wel in kunnen, dus ze gaan niet zo snel extra betalen voor een beperking

[Herko_ter_Horst]

Armageddon_2k schreef op dinsdag 14 juni 2011 @ 11:19:
Dat was ook mijn conclusie, maar ik hoopte eigenlijk dat er iemand nog een leuke oplossing zou hebben
Helaas is "een gebruiker" in het verhaal betrekken, niet echt een optie. Ik ga puur een stukje software leveren met een database. En ik wil dat alleen mijn applicatie bij de database kan.

Met "de gebruiker in het verhaal betrekken" bedoelde ik, dat de gebruiker een password moet ingeven voor het benaderen van de database. Een andere applicatie zal de gebruiker dan ook om een wachtwoord moeten vragen. Daarmee voorkom je dat een andere applicatie zonder medeweten van de gebruiker met jouw database kan communiceren.

Dat is natuurlijk minder gebruiksvriendelijk, maar dat is de afweging die moet maken. 100% waterdicht krijg je het niet. De vraag is of de potentiële schade de extra kosten/inspanning rechtvaardigt.

Maar ik begrijp dat jij het niet wil en het geen gebruikerswens is? Bevat de database dan jouw data? Anders snap ik het niet.

[Voor 6% gewijzigd door Herko_ter_Horst op 14-06-2011 13:07]

[Voutloos]

^ Nou ja, een beetje afschermen kan nooit kwaad, maar je zou het ook in een contractje kunnen zetten. DB aanraken == einde support. Krabbeltje eronder hatsikidee.

(Overigens zou bij mijn API verhaaltje de gebruiker ook verantwoordelijk zijn voor het goed omgaan met de eigen credentials.)

[Armageddon_2k]

Herko_ter_Horst schreef op dinsdag 14 juni 2011 @ 13:06:
[...]
Maar ik begrijp dat jij het niet wil en het geen gebruikerswens is? Bevat de database dan jouw data? Anders snap ik het niet.

Yep het is mijn keuze. Het is mijn database, en het is mijn data
Het idee is, dat ik data ga opslaan in deze database. En als een "Man in the middle" deze data kan aanbieden aan clients. Op deze manier zorg ik er voor dat de data 'geborgd' is, dus dat niet iemand zelf data invoert. En daarnaast kan ik het aantal clients dat verbinding maakt limiteren. En als de klant dan meer clients wil gaan connecten, dan moet hij daarvoor een licentie aanschaffen.

Daarnaast biedt het "Man in the middle" concept me nog een aantal voordelen, maar dit zijn de voornaamsten.

Voutloos schreef op dinsdag 14 juni 2011 @ 13:32:
Overigens zou bij mijn API verhaaltje de gebruiker ook verantwoordelijk zijn voor het goed omgaan met de eigen credentials.)

Het gaat dus niet alleen maar om verantwoordelijkheid, maar ook om euro's

[Voor 16% gewijzigd door Armageddon_2k op 14-06-2011 15:05]

[Janoz]

Zolang je hele applicatie in een untrusted omgeving draait is er geen mogelijkheid om het waterdicht te krijgen. Technisch krijg je het niet dicht dus dan is de juridische weg de enige overgeblevene.

[Armageddon_2k]

Janoz schreef op dinsdag 14 juni 2011 @ 15:09:
Zolang je hele applicatie in een untrusted omgeving draait is er geen mogelijkheid om het waterdicht te krijgen. Technisch krijg je het niet dicht dus dan is de juridische weg de enige overgeblevene.

Mja, was mijn conclusie ook al een beetje. Had nog hoop op iemand met een briljante ingave.
Maar helaas, dan maar spatwaterdicht

[YopY]

Als het gaat om misbruik te voorkomen (bijv. applicaties van derden die je service / db misbruiken) zou je evt. nog wel flood control kunnen toepassen. Geef elke client-applicatie een unieke sleutel (of ken die toe bij het verbinden met je DB, een soort van session key), en beperk het aantal queries per seconde/uur/dag/week (wat je voorkeur maar is).