Monat: Dezember 2009

Google myself

Regelmäßig google ich nach mir selber, um zu sehen, was dort so über mich steht. Heutzutage ist sowas ja wichtig, da es ja auch (zukünftige) Arbeitgeber, welche diesen Weg nutzen, um mehr über jemand herauszufinden. Damals hatte ich keinen Skrupel irgendwas Online zu stellen, mittlerweile bin ich älter und sehe das etwas anders.
Aber ich bin absolut beruhigt. Suche ich nach meinen Namen, so finde ich zwar hier und dort einen Eintrag aber die sind eher die Seltenheit. Bilder habe ich zwei Stück auf der 10. Seite entdeckt, wobei das eine hier im Blog liegt und das andere mein Twitter Avatar / Gravatar ist.

Sowas ist doch schon beruhigend zu wissen 🙂

C#: Hashes versalzen

Kleine Vorgeschichte
Heute habe ich mir die Möglichkeit angeschaut, eigene MembershipProvider für ein ASP.NET MVC Projekt zu schreiben. Selbstverständlich wollte ich die Passwörter in der Datenbank nur als Hash speichern. Gleich ist mir wieder ein altes Problem aufgefallen, welches mir auch damals bei PHP aufgefallen ist. Vorteil der Hashmethode ist die fehlende Möglichkeit, wieder in Klartext umgewandelt zu werden. Allerdings ist der Hash immer gleich.
So wird aus

md5(„test“) immer „098f6bcd4621d373cade4e832627b4f6“

Das Problem
Selbst wenn nun ein böser Hacker die Datenbank ausliest, kommt er so an das Passwort. Der einfachste Weg liegt dabei so nahe, dass man gar nicht drauf kommt. Gebt mal so einen Hash bei Google ein, man wird das Passwort herausfinden können. Und mittlerweile gibt es ganze Rainbow-Tabellen, so dass es immer einfacher wird, die Werte zu vergleichen.
Aufgrund des Einfallsreichtums mancher Menschen tippe ich mal darauf, dass man ca. 50% der Passwörter der Otto-Normal-Benutzer daher innerhalb weniger Minuten knacken könnte.
C#: Hashes versalzen weiterlesen

ASP.NET MVC: Seiten gehen nicht auf IIS5.1

Wir hatten folgendes Problem, wir entwickeln an einer ASP.NET Seite. Mit dem lokalen Entwicklungswebserver funktionierten die Seiten tadellos.
Als wir sie dann hochluden, gingen einige Seiten nicht und wir wussten nicht genau warum.

Nach einiger Sucherei konnten wir dies auf die <connectionStrings> in der web.config zurückführen.
Durch einen Kollegen stand dort folgende zwei Einträge drin:

    <add name="PersonalSettingsEntities" 
    connectionString="metadata=res://*/Models.Personal.csdl|res://*/Models.Personal.ssdl|res://*/Models.Personal.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=WXPAPP02\SQLEXPRESS;Initial Catalog=IntranetDB;User ID=sa;Password=sa;Pooling=False;MultipleActiveResultSets=True&quot;" 
    providerName="System.Data.EntityClient" />
    <add name="PersonalEntities" 
    connectionString="metadata=res://*/Models.Home.csdl|res://*/Models.Home.ssdl|res://*/Models.Home.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=WXPAPP02\SQLEXPRESS;Initial Catalog=IntranetDB;User ID=sa;Password=sa;Pooling=False;MultipleActiveResultSets=True&quot;" 
    providerName="System.Data.EntityClient" />

Der Unterschied zu den anderen Connectionstrings war, dass diese Einträge die Einträge „Pooling=False;“ enthält, und den Eintrag „Persist Security Info=True;“ war nicht enthalten.
Die Zeilen entsprechend abgeändert, schon ging es.
Werde nachher noch mal genaue Erklärung zu den beiden Parametern raussuchen.