[asp.net]Md5 encryptie

[bibawa]

Ik ben druk opzoek naar een functie waarmee ik in asp.net 2.0 een paswoord kan encrypteren dmv md5, ik heb momenteel deze functie:

code:

  Private Function EncryptOneWay(ByVal nonEncrypted As String) As String
        Dim encoding As New UTF8Encoding
        Dim hashBytes As Byte() = encoding.GetBytes(nonEncrypted)
        Dim md5 As New System.Security.Cryptography.MD5CryptoServiceProvider
        Dim encrypted = md5.ComputeHash(hashBytes)

        Dim strPassword As String = Convert.ToBase64String(encrypted)
        Return strPassword
    End Function

Deze code werkt, maar ik krijg een string terug die niet gelijk is aan de string die ik krijg wanneer ik een md5 neem in php.

Dit paswoord moet in md5 worden opgeslagen omdat ik via een java programma ook zou moeten in loggen, dus de md5 encrypties zouden compatibel moeten zijn.

Heeft iemand een idee?

[GlowMouse]

Heb je die functie zelf geschreven? Zoja, weet je wat base64 is?

[DarthPlastic]

Weet niet of het echt relevant is, maar md5 (unsalted) is te kraken tegenwoordig, en nog niet eens zo moelijk ook.
Als het om gegevens gaat die écht sterk beveiligd moeten worden zou ik toch naar iets anders kijken

[RobIII]

Daarnaast is MD5 geen encryptie (want die kun je weer 'ongedaan maken' en het originele bericht mee terughalen) maar een hashing functie.

[bibawa]

iets anders zoals wat?

[Snake]

Je zet de string eerst om naar base64. Laat regel 7 even weg, en kijk dan eens

[bibawa]

Maar wat is een manier die niet te kraken is? (niet omkeerbaar is !)

[Nvidiot]

MD5 + salt, SHA1 + salt, enzovoort. Door een salt te gebruiken heb je niets meer aan een enorme tabel met daarin MD5 en het bijbehorende wachtwoord.

[RobIII]

bibawa schreef op donderdag 19 april 2007 @ 12:26:
Maar wat is een manier die niet te kraken is? (niet omkeerbaar is !)

Als je nou zelf eens een keer wat onderzoek doet voor je post...

Nvidiot schreef op donderdag 19 april 2007 @ 12:27:
MD5 + salt, SHA1 + salt, enzovoort. Door een salt te gebruiken heb je niets meer aan een enorme tabel met daarin MD5 en het bijbehorende wachtwoord.

Dat haalt geen kont uit, omdat het voor een MD5 tegenwoordig relatief makkelijk is om een collision te vinden (en dan doet het originele pass + salt er dus niet meer toe).

[ Voor 46% gewijzigd door RobIII op 19-04-2007 12:30 ]

[BasieP]

ik weet niet precies wat de TS doet met de hashes, maar het maakt niet zo heel erg veel uit dat de hash te kraken is wanneer hij in een beveiligde db oid wordt opgeslagen.

[RobIII]

BasieP schreef op donderdag 19 april 2007 @ 12:37:
ik weet niet precies wat de TS doet met de hashes, maar het maakt niet zo heel erg veel uit dat de hash te kraken is wanneer hij in een beveiligde db oid wordt opgeslagen.

Als je zo redeneert kun je net zo goed een wachtwoord als plain text opslaan...

[Stephan Oudmaijer]

RobIII schreef op donderdag 19 april 2007 @ 12:37:
[...]

Als je zo redeneert kun je net zo goed een wachtwoord als plain text opslaan...

+1 Inzichtvol

[Nvidiot]

RobIII schreef op donderdag 19 april 2007 @ 12:28:
[...]
Dat haalt geen kont uit, omdat het voor een MD5 tegenwoordig relatief makkelijk is om een collision te vinden (en dan doet het originele pass + salt er dus niet meer toe).

Voor zover ik de informatie daarover kan volgen komt het er op neer dat je 2 verschillende bestanden kunt maken die naar hetzelfde hashen. Dat is niet erg boeiend als je alleen de hash hebt.

[RobIII]

Nvidiot schreef op donderdag 19 april 2007 @ 12:42:
[...]

Voor zover ik de informatie daarover kan volgen komt het er op neer dat je 2 verschillende bestanden kunt maken die naar hetzelfde hashen. Dat is niet erg boeiend als je alleen de hash hebt.

Juist wel. Als je de hash hebt kun je dus easy een ander 'wachtwoord' genereren dat dezelfde hash oplevert en dat wachtwoord (ook al is het dus niet het 'originele' wachtwoord) gebruiken om jezelf toegang te verschaffen.

[Gerco]

RobIII: Dat word toch voorkomen door salting? Als in in de database een per-user salt opsla en die salt gebruik om te berekenen wat de hash moet zijn (md5(salt+password)) kun jij wel een wachtwoord bedenken die dezelfde hash heeft als mijn wachtwoord, maar daar heb je niets aan want je weet de salt niet.

Als md5(mijnpassword) == md5(jouwstring) dan betekent dat nog niet dat md5(salt + mijnpassword) == md5(salt + jouwstring).

Zelfs al bedenk je een string waarvoor geld md5(jouwstring) == md5(salt + mijnpassword), heb je daar nog steeds niets aan, want md5(salt + jouwstring) != md5(salt + mijnpassword).

[ Voor 39% gewijzigd door Gerco op 19-04-2007 12:58 ]

[RobIII]

Uiteraard; maar als je al in de DB kunt is de kans dat de salt bekend is (of te vinden is) natuurlijk ook nogal groot
Uiteraard heb je gelijk; het ging even om het principe.

[GlowMouse]

RobIII schreef op donderdag 19 april 2007 @ 13:04:
Uiteraard; maar als je al in de DB kunt is de kans dat de salt bekend is (of te vinden is) natuurlijk ook nogal groot
Uiteraard heb je gelijk; het ging even om het principe.

De vraag is of je dan nog een collision kunt vinden die eindigt op de salt.

[BasieP]

RobIII schreef op donderdag 19 april 2007 @ 12:37:
[...]

Als je zo redeneert kun je net zo goed een wachtwoord als plain text opslaan...

dan begrijp jij me verkeerd.
het hashen van wachtwoorden in een DB is er zodat de beheerder(s) niet zo 123 het wachtwoord kunnen zien.
Wanneer een beheerder echt misbruik wil maken van de rechten die hij heeft kan hij ook gewoon het nog niet gehashde (ingegeven) wachtwoord van de gebruiker afvangen.

Dus zelfs met beste encryptie kan een kwaadwillende beheerder achter wachtwoorden komen.


Mijn punt is dus dat je sowieso moet zorgen dat niemand die hashes ziet, want idd alles is te kraken.

RobIII schreef op donderdag 19 april 2007 @ 13:04:
Uiteraard; maar als je al in de DB kunt is de kans dat de salt bekend is (of te vinden is) natuurlijk ook nogal groot
Uiteraard heb je gelijk; het ging even om het principe.

Als je zo redeneert kun je net zo goed een wachtwoord als plain text opslaan...

[ Voor 21% gewijzigd door BasieP op 19-04-2007 13:10 ]

[RobIII]

Waarmee mijn punt dus ook duidelijk wordt: je kunt tot op zekere hoogte beveiligen, maar je bent altijd zo sterk als de zwakste schakel. Don't overdo is voor (bijv.) een forumpje of een kijk-eens-mijn-kat-site