Laden...

[erledigt] Compare SecureString (ohne decrypten)

Erstellt von rollerfreak2 vor 13 Jahren Letzter Beitrag vor 13 Jahren 3.566 Views
rollerfreak2 Themenstarter:in
916 Beiträge seit 2008
vor 13 Jahren
[erledigt] Compare SecureString (ohne decrypten)

Hallo zusammen,

ich habe ein kleines Problem. Ich möchte 2 SecureString Instanzen miteinander vergleichen ohne sie explizit wieder in einer string umwandeln zu müssen. Im Netz habe ich nichts brauchbares dazu gefunden. Microsoft

Mir scheint als müsse man das wirklich vor dem vergleich decrypten, oder gibt es da einen besseren, sichereren Weg?

Again what learned...

D
500 Beiträge seit 2007
vor 13 Jahren

Moin!

Ich denke nicht, dass man SecureString direkt miteinander vergleichen sollen koennte, da es meiner Ansicht nach zu Sicherheitsproblemen fuehren kann.
Angenommen Du bist derjenige, der den SecureString knacken moechte. Sollten die SecureStrings vergleichbar sein, dann koennstest Du theoretisch per BruteForce immer einen unverschluesselten String hernehmen, zu einem SecureString umwandeln und anschliessend mit dem zu kanckenden SecureString vergleichen. Wenn diese dann gleich sind, dann hast du den String geknackt. Also eine denkbar schlechte Funktionalitaet, wenn es diese gaebe.

Gruss,
DaMoe

rollerfreak2 Themenstarter:in
916 Beiträge seit 2008
vor 13 Jahren

????
Wo ist das der Unterschied, ob ich nun vor dem Vergleich den SecureString in einen UnsecureString umwandel, oder andersherum ist doch völlig egal.

Again what learned...

D
500 Beiträge seit 2007
vor 13 Jahren

Secure String

Note that SecureString has no members that inspect, compare, or convert the value of a SecureString. The absence of such members helps protect the value of the instance from accidental or malicious exposure.

rollerfreak2 Themenstarter:in
916 Beiträge seit 2008
vor 13 Jahren

Ich hab ja auch nicht gesagt dass das SecureString Object selber den Compare kann, ich will eine Möglichkeit einen SecureString "sicher" zu comparen, daher ohne ihn in seinen string Representant zu konvertieren.

Ohn bezüglich deines Einspruches, sicher wäre es nicht gut das am SecureString selber machen zu könne, trotzdem ist das Argument

Sollten die SecureStrings vergleichbar sein, dann koennstest Du theoretisch per BruteForce immer einen unverschluesselten String hernehmen, zu einem SecureString umwandeln und anschliessend mit dem zu kanckenden SecureString vergleichen. Wenn diese dann gleich sind, dann hast du den String geknackt.

aus meiner Sicht Quatsch, weil wenn einer mit BruteForce auf den SecureString los geht, kann er genauso den SecureString nehmen, ihn in den string representant umwandeln, und anschließend mit seinem string vergleichen.

Mein Idee war lediglich einen puren string vergleich im Code zu vermeiden, weil das aus meiner Sicht nicht schön und auch nicht sicher ist.

Again what learned...

Gelöschter Account
vor 13 Jahren

Mein Idee war lediglich einen puren string vergleich im Code zu vermeiden, weil das aus meiner Sicht nicht schön und auch nicht sicher ist.

dann hast du den sinn der securestring klasse nciht verstanden. es geht darum, das während der laufzeit des programmes der string nicht unverschlüsselt aus dem speicher gelesen werden kann... für den konkreten vergleich machst du dann eine echte, vergleichbare string instanz und verwirfst diese unmittelbar nach dem vergleich... die sicherheit ist also nicht absolut aber bei korrekter verwendung (also unmittelbarem verwurf der verglichenen string instanz) sicher genug.

rollerfreak2 Themenstarter:in
916 Beiträge seit 2008
vor 13 Jahren

Ich hab den Sinn schon verstanden. Beim auslesen des Passworts aus dem Modell ist sowieso noch eine Schicht dazwischen. Daher der SecureString in den UnsecureString ist nicht der klartext sondern wiederrum ein verschlüsselter string.

Es geht eigentlich um das DEFINIEREN des Passworts. Da muss der user in die Textboxen 2 mal das GLEICHE passwort eingeben. Die Textboxen sind per DataBinding verbunden und arbeiten nur auf SecureStrings. Wenn ich nun vergleichen wir ob der user überhaupt 2 mal das gleich Passwort eingetippt hat muss ich, da der SecureString.Equals ja nicht funktioniert, den SecureString in den KlarText umwandeln. Logisch verwerf ich die strings gleich wieder, genau genommen weise ich sie nicht mal einer Variable zu.

Jedoch finde ich es trotzdem nicht schön, aber was anderes wird wohl nicht möglich sein.

Again what learned...

Gelöschter Account
vor 13 Jahren

selbst wenn die textboxen mit securestrings arbeiten... ist in allererster und oberster instanz nur ein einfacher string in der textbox. an dieser stelle solltest du dir also keine gedanken um sicherheit machen, da man mit der winapi ohnehin recht einfach an den string kommt.... noch bevor der securestring greift....

daher solltest du dein validationsmechanismus so gestalten, das sie den konkreten eingabestring auf gleicheit prüfen und erst dann den securestring rausspucken und damit weiterarbeiten.

rollerfreak2 Themenstarter:in
916 Beiträge seit 2008
vor 13 Jahren

Jo die Textboxen kann man natürlich mit der WinApi auslesen. Von daher ist das Argument der Sicherheit an der Stelle des Vergleichs außer Acht zu lassen. Okay dann kann der Thread geschlossen werden.

Danke euch.

Again what learned...