Autor |
Beitrag |
nullplan001
      
Beiträge: 212
Win 2000 Professional, Debian Linux 4.0 (Etch,Stable)
Pascal (FreePascal 2.0.2, TurboPascal 7.0), C(++) (G++/GCC 3.4.2 + MinGW), Java (JDK 1.5.0_07), PHP (PHP 5.1.4)
|
Verfasst: Fr 07.04.06 17:53
Hi all,
ich bin dabei, ein Mailprogramm zu schreiben. Dazu muss man auch die Passwörter abspeichern (momentan bin ich noch bei Single Tasking, was bedeutet, dass ich momentan nur einen POP3- oder SMTP-Server bedienen kann.) Ich will mir jetzt nicht nachsagen lassen, ich schreibe die Passwörter einfach so in die Registry, also habe ich da ein Verfahren entwickelt. Wie kann ich die Effektivität meines Algorithmus überprüfen. Ich will ja nicht, das mein Programm kaum auf dem Markt ist, und schon ist die Verschlüsselung geknackt. Ich möchte vor allen Dingen auch die Resistenz gegen aktive Angriffe testen, also wo jemand haufenweise Passwörter verschlüsseln lässt und guckt, was damit passiert. Den Algorithmus zur Verschlüsselung werde ich verständlicherweise nicht posten.
Tschö,
nullplan
_________________ Ich fahr' nicht selber, weil ich festgestellt habe: ich fahre zu emotional. Bin 180 gefahren wo 30 erlaubt war... -- Jürgen von der Lippe
|
|
AXMD
      
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Fr 07.04.06 19:04
nullplan001 hat folgendes geschrieben: | Den Algorithmus zur Verschlüsselung werde ich verständlicherweise nicht posten. |
Damit ist dein Verfahren schonmal nicht vertrauenswürdig. KERKHOFF'SCHES PRINZIP
Abgesehen davon gehört das Topic dann auch nicht in die Algorithmensparte - wenn der Algorithmus nicht bekannt ist.
AXMD
|
|
zemy
      
Beiträge: 207
Win XP Prof.
D7
|
Verfasst: Fr 07.04.06 19:59
Regel 1 bei Kryptographie von Laien:
solls sicher werden, nehm was bekanntes!
Such dir was hübsches aus (Wiki hilft da weiter) und nehm den, der dir am sympatischsten (soll heißen für deinen Fall am zweckmäßigsten) ist. Falls du das machen solltest, kannst du deine Prozedur dann mal online stellen? Würde mich spaßeshalber interessieren
MfG
_________________ LifeIsToShortToThinkAboutTheShortness
|
|
delfiphan
      
Beiträge: 2684
Erhaltene Danke: 32
|
Verfasst: Fr 07.04.06 20:31
Naja, die Protokolle sind ja sowieso Cleartext. Weswegen sich die Mühe machen das ganze auf dem Computer zu verschlüsseln?
Jedenfalls wenn du's verschlüsselst musst du den Schlüssel nicht im Programm speichern, das wäre Unsinn. Du müsstest die Passworter mit einem anderen, benutzerdefinierten Schlüssel verschlüsseln. Sonst kann man einfach dein Programm dekompilieren und voila.
|
|
nullplan001 
      
Beiträge: 212
Win 2000 Professional, Debian Linux 4.0 (Etch,Stable)
Pascal (FreePascal 2.0.2, TurboPascal 7.0), C(++) (G++/GCC 3.4.2 + MinGW), Java (JDK 1.5.0_07), PHP (PHP 5.1.4)
|
Verfasst: Fr 07.04.06 20:34
Hmpf... das hatte ich nicht beachtet. (Das mit der kerckhoffschen Regel) Also mein Algorithmus basiert auf Stringverschlüsselung über xor. Allerdings mit einem zufallsgenerierten Schlüssel. Wenn ich den Wert dann in die Registry schreibe, sieht das so aus: Es ist ein Hex-Wert (REG_BINARY). Als erstes steht dort die Länge des eigentlichen Wertes, und dann kommt der chiffrierte String. Und dann darf ich nach Kerkhoffschem Prinzip nicht weierreden. Die schlauen wissen jetzt, was dann kommt. Das Auslesen des Schlüssels, unter dem mein Programm registriert ist, zeigt folgendes:
Quelltext 1: 2:
| password REG_BINARY 87,54,AF,21,89,55,31,80,4A,F5,C8,54,23,88,25,1A,CD key REG_BINARY 08,2B,50,7E,EB,2F,06,1A,43,45,25,12,87,5F,6A,7B,2D |
Und dieses Wertepaar maskiert das Wort "nullplan". Tja,wie auch immer das funktioniert. Auf Anfrage stelle ich gern weitere Wertepaare zur Verfügung.
Tschö,
nullplan
P.S.: Na gut, ihr habt gewonnen. Nachfolgend meine Unit:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37:
|
{$SMARTLINK ON} unit wscrypt; {$MODE OBJFPC} interface type Twscrypt = class procedure encrypt (clear:shortstring; var cipher:shortstring; var len:longword); procedure decrypt (cipher:shortstring; len : longword; var clear:shortstring); end;
implementation procedure Twscrypt.encrypt(clear: shortstring; var cipher:shortstring; var len:longword); var key : shortstring; i : longword;
begin randomize; for i := 1 to length(clear) do key[i] := chr(random(254) + 1); for i := 1 to length(clear) do cipher[i] := clear[i] xor key[i]; len := length(cipher); cipher := cipher + key; end;
procedure Twscrypt.decrypt(cipher : shortstring; len: longword; var clear:shortstring); var key : shortstring; i : longword;
begin key := copy (cipher, len+1, length(cipher) - len); delete (cipher, len+1, length(cipher) - len); for i := 1 to length(cipher) do clear[i] := cipher[i] xor key[i]; end; end. |
Das ist nur die reine Codierung. Von Reinschreiben in die Registry steht da noch gar nichts.
Anm.: Shortstrings sind in Delphi normale Strings (in FreePascal meckert er dann rum wegen Typkonversion und so). Viel Spaß mit der Unit.
Achso, und die Protokolle sind eben nicht alle Plain Text. Z.B. ESMTP läuft mit Base64. und wenn ich dazu noch TLS oder SSL nutze, gibt es rein gar nichts lesbares mehr.
P.P.S.: Na gut, nachdem der Trick jetzt raus ist (wer es nicht geschnallt hat: Password ist zufällig erzeugt, Key ist das verschlüsselte Passwort, mit dem ersten Byte als Originallänge), werde ich mich wohl auf ein anderes Verfahren stützen. Ich frage mich, wie man asymetrisch verschlüsselt. Ich meine, eine Tür mit einem Schlüssel zuzuschließen und sie nur mit einem anderen wieder aufzubekommen, ist nicht natürlich, oder?
_________________ Ich fahr' nicht selber, weil ich festgestellt habe: ich fahre zu emotional. Bin 180 gefahren wo 30 erlaubt war... -- Jürgen von der Lippe
|
|
zemy
      
Beiträge: 207
Win XP Prof.
D7
|
Verfasst: Sa 08.04.06 11:45
Deine Prozedur hat wirklich ein geringes Sicherheitspotential. (Sorry) Ein einfaches XOR hält zwar erstmal ein ScriptKiddie davon ab, die Registry auszulesen. Wenn man sich aber länger damit beschäftigt (z.B. das Bitmuster anschaut), fällt es schnell auf....
Zu den asymetrischen Verschlüsselungen: Mit der Tür ist das natürlich schlecht erklärbar. Aber mit nem Briefkasten klappt das schon eher. Alle, die wissen wie man an den Einwurfschlitz kommt, können Briefe einwerfen. Aber nur der, der den Schlüssel hat, kann die Briefe auch entnehmen... Ist aber vieleicht nicht das optimale für dein Programm (asymetrische Schlüssel sind aufwendig und ver- und entschlüssler sind die selben Personen)
Für dich ist wohl eher was symetrisches geeignet. Die Frage ist blos, wie hebt man da den Key auf?
MfG
_________________ LifeIsToShortToThinkAboutTheShortness
|
|
DaRkFiRe
      
Beiträge: 526
WinXP Home & Professional
C, C++, Delphi
|
Verfasst: Sa 08.04.06 13:37
Verschlüsselungsverfahren unbekannt / nicht veröffentlicht??? Weniger Angriffsmöglichkeiten - Kerkhoff'sches Prinzip schön und gut...
Ach ja - desweiteren: bei XOR Verschlüsselung kann man den CBC Mode benutzen, zusammen mit einem Blockbasierten Wert einer Tabelle, der zusätzlich das Bitmuster verschleiert.
_________________ Lang ist der Weg durch Lehren - kurz und wirksam durch Beispiele! Seneca
|
|
MrSaint
      
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Sa 08.04.06 13:50
Also wenn es nur um die "verschlüsselung" von Passwörtern geht, verschlüsselt man die normaler weise gar nicht! Man erzeugt von dem Passwort einen Hash (MD5, SHA1 oder ähnliches) und speichert den. Wenn dann ein Benutzer ein Passwort eingibt überprüft man den Hash von diesem mit dem in der Registry gespeicherten. So ein Hashing hat eben den Vorteil, dass man aus dem Hash die eigentlichen Daten nicht zurückrechnen kann.
MrSaint
_________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
AXMD
      
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Sa 08.04.06 13:55
MrSaint hat folgendes geschrieben: | Also wenn es nur um die "verschlüsselung" von Passwörtern geht, verschlüsselt man die normaler weise gar nicht! Man erzeugt von dem Passwort einen Hash (MD5, SHA1 oder ähnliches) und speichert den. Wenn dann ein Benutzer ein Passwort eingibt überprüft man den Hash von diesem mit dem in der Registry gespeicherten. So ein Hashing hat eben den Vorteil, dass man aus dem Hash die eigentlichen Daten nicht zurückrechnen kann. |
Eben deshalb sind Hashes hier unbrauchbar  . Das Passwort muss ja wieder an den Mailserver übetragen werden - und da hilft der Hash wenig
AXMD
|
|
MrSaint
      
Beiträge: 1033
Erhaltene Danke: 1
WinXP Pro SP2
Delphi 6 Prof.
|
Verfasst: Sa 08.04.06 14:00
_________________ "people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
|
|
DaRkFiRe
      
Beiträge: 526
WinXP Home & Professional
C, C++, Delphi
|
Verfasst: Sa 08.04.06 14:21
Aus Hashes kann man das eigentliche Passwort nicht zurückrechnen?
Hashes komprimieren nicht, es gehen Informationen verloren - demnach erzeugen mehrere Strings einen gleichen Hash - man spricht von Kollision.
MD5: 128bit
SHA1: 160bit
Man hat das Passwort: P
Ein anderer (gut gewählter String): A
MD5-Hash von P: M(P)
SHA1-Hash von P: S(P)
MD5-Hash von A: M(A)
SHA1-Hash von A: S(A)
Also kann M(A) = M(P) sein, aber M(A) = M(P) UND S(A) = S(P) ist doch schon viel unwahrscheinlicher.
Auszuschließen ist es aufgrund des Informationsverlustes jedoch nicht.
Im Grunde genommen ist die Verschlüsselung - und erst recht das Hashing - pure Stochastik.
_________________ Lang ist der Weg durch Lehren - kurz und wirksam durch Beispiele! Seneca
|
|
AXMD
      
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Sa 08.04.06 14:25
@Darkfire: und was hat dein Beitrag jetzt mit dem eigentlichen Thema zu tun  ?
AXMD
|
|
nullplan001 
      
Beiträge: 212
Win 2000 Professional, Debian Linux 4.0 (Etch,Stable)
Pascal (FreePascal 2.0.2, TurboPascal 7.0), C(++) (G++/GCC 3.4.2 + MinGW), Java (JDK 1.5.0_07), PHP (PHP 5.1.4)
|
Verfasst: Sa 08.04.06 20:07
zemy hat folgendes geschrieben: | Deine Prozedur hat wirklich ein geringes Sicherheitspotential. (Sorry) Ein einfaches XOR hält zwar erstmal ein ScriptKiddie davon ab, die Registry auszulesen. Wenn man sich aber länger damit beschäftigt (z.B. das Bitmuster anschaut), fällt es schnell auf.... |
Und was macht der Crack? Ich meine, der findet einen unsinigen Wert in der Registry und denkt, dass es sich um das verschlüsselte Passwort handelt. Stimmt aber nicht, es handelt sich um puren Stuss. Und selbst wenn er den Trick durchschaut, wie lange wird es brauchen, um das Format des verschlüsselten Passwortes festzustellen? (welches da ist: Länge der Verschlüsselungssequenz, Verschlüsselung, Schlüssel) Was hat man als Handle? Länge(Chiffre) = 2 * Länge(Klartext) + 1. Das ist nicht viel, aber man kommt drauf, wenn man einen aktiven Angriff startet.
zemy hat folgendes geschrieben: | Für dich ist wohl eher was symetrisches geeignet. Die Frage ist blos, wie hebt man da den Key auf? |
Meine Rede. Ich habe es ja so wie oben versucht, also Key in Chiffre eingearbeitet. Andere Möglichkeit wäre, beide getrennt abzuspeichern. Da kann man sich auch gleich in den Fuß schießen. Wie soll man das sicher machen? OK, nennen wir den Chiffretext "Key" und den Schlüssel "Password". Freude! Und irgendwann kriegt Kollege Hacker spitz, wie der Hase läuft. Verschiedene Schlüssel im Programm speichern und dann eine Method-Option in die Registry schreiben? Sodass ich den Key nirgends sichtbar abspeichere und ihn nur durch eine Nummer identifiziere? Auch schlecht, dass kann durchschaut werden -> dekompilieren -> Schlüssel rausfinden -> herzhaft lachen und E-Mail-Konten zum Spamen nutzen. Wie wäre es mit Method-Option als Key verkleidet? Wenn das geht, ist Kryptographie so wie aufräumen: 90% bestehen aus kaschieren und verstecken.  Mir dröhnt der Schädel. Gibt es nicht irgendwas, sagen wir, zu 90% Sicheres, womit man ein Passwort so verschlüsseln kann, dass man es wieder entschlüsseln kann? Wie steht es mit Trap Doors? Wie schreibt man die (also jetzt nicht ortographisch sondern informatisch)?
Tschö,
nullplan
_________________ Ich fahr' nicht selber, weil ich festgestellt habe: ich fahre zu emotional. Bin 180 gefahren wo 30 erlaubt war... -- Jürgen von der Lippe
|
|
Grenzgaenger
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Sa 08.04.06 21:51
also die idee mit dem hash, find ich für gut. der one-way-algo ist doch ausreichend. wenn du dann deinen hash mit dem abgespeicherten verglichen hast, hast doch noch das orginal im zugriff. du musst also das passwd gar nicht mehr entschlüsseln sondern kannst es direkt an den server überleiten....
nimm einfach MD5 das ist denk ich für deine anforderungen mehr als ausreichend und codestrecken liegen hier zu hauf in der gegend rum... auch hier im forum....
noch viel spass und erfolg.
|
|
DaRkFiRe
      
Beiträge: 526
WinXP Home & Professional
C, C++, Delphi
|
Verfasst: Sa 08.04.06 23:21
Gehe direkt über 2 Antworten und rechtfertige Dich vor AXMD...
Also - es ginge wohl darum, ein Passwort zur Absicherung eines Programmes zu nutzen, dass mit Hilfe eines MD5 Algorithmus (One-Way) abgelegt werden sollte.
Ich hab nun nichts anderes gepostet, als dass man doch besser 2 Algorithmen benutzen sollte, da ich selbst schon zu meinem Passwort, zu dem ich ziemlich genau den MD5 Hash kenne ein anderes Passwort herausgefunden habe, das denselben Hash erzeugt! (Kollision!)
Also - 2 Algorithmen nehmen (MD5 + SHA1 [zum Beispiel] [+eigenen?]), damit die Sache sicherer wird.
Hier ist MD5 allein vielleicht sogar noch unsicherer, da es durch seine Byte-Länge von 16 auf sich aufmerksam macht. Man könnte vielleicht mit Padding arbeiten, um zu verwirren und zu verschleiern, dass es sich um einen MD5-Hash handelt. Natürlich hängt es davon ab, wie gespeichert wird.
Und da es hier ja um Sicherheit geht ( um eine Menge sogar, wenn es um das Speichern anderer [ und vor allem: mehrerer ] Passwörter geht ), dürfte mein Post doch von Relevanz sein, oder irre ich?
_________________ Lang ist der Weg durch Lehren - kurz und wirksam durch Beispiele! Seneca
Zuletzt bearbeitet von DaRkFiRe am Sa 08.04.06 23:24, insgesamt 1-mal bearbeitet
|
|
AXMD
      
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Sa 08.04.06 23:24
nullplan001 hat folgendes geschrieben: | ich bin dabei, ein Mailprogramm zu schreiben. Dazu muss man auch die Passwörter abspeichern (momentan bin ich noch bei Single Tasking, was bedeutet, dass ich momentan nur einen POP3- oder SMTP-Server bedienen kann.) |
Nur mal um das klarzustellen: was soll gespeichert werden? Ein Passwort für das Programm oder ein Passwort zum Anmelden auf dem Server? Falls es letzteres ist, ist die Diskussion über einen Hash überflüssig, da der Mailserver mit dem Hash nichts anfangen kann... das habe ich vorhin gemeint.
AXMD
|
|
DaRkFiRe
      
Beiträge: 526
WinXP Home & Professional
C, C++, Delphi
|
Verfasst: Sa 08.04.06 23:28
Wenn es sich um das Speichern der Zugriffspasswörter zum Mailserver handelt - AXMD - dann hast Du natürlich Recht: hier müssen die Passwörter SELBST verschlüsselt werden, keine Frage.
Ich hatte mich auf MrSaint bezogen (okay, okay, nicht alles gelesen), der meinte, es müsse das Programm mit einem Passwort (ebenso?) geschützt werden.
_________________ Lang ist der Weg durch Lehren - kurz und wirksam durch Beispiele! Seneca
|
|
AXMD
      
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Sa 08.04.06 23:32
DaRkFiRe hat folgendes geschrieben: | Ich hatte mich auf MrSaint bezogen (okay, okay, nicht alles gelesen), der meinte, es müsse das Programm mit einem Passwort (ebenso?) geschützt werden. |
Was aber nichts weiter als eine Vermutung ist - es wird zumindest nicht explizit im Beitrag des Autors ersichtlich; daher würde ich vorschlagen, dass wir erst einmal warten, was der Autor des Beitrags dazu sagt - denn ohne jetzt sicher zu wissen, um welches Passwort es sich handelt, ist es nicht sehr sinnvoll weiterzudiskutieren, da die Anwendungsfälle hier doch zu unterschiedlich sind.
AXMD
|
|
DaRkFiRe
      
Beiträge: 526
WinXP Home & Professional
C, C++, Delphi
|
Verfasst: Sa 08.04.06 23:38
Ich hatte vor, meine Bedenken über die Verwendung (also mit einem [bekannten] Algorithmus, ohne jegliche Weiterverarbeitung) von Hashes zur Speicherung von Passwörtern äußern.
Demnach erst noch auf nullplan warten 
_________________ Lang ist der Weg durch Lehren - kurz und wirksam durch Beispiele! Seneca
|
|
zemy
      
Beiträge: 207
Win XP Prof.
D7
|
Verfasst: So 09.04.06 00:59
nullplan001 hat folgendes geschrieben: | Hi all,
ich bin dabei, ein Mailprogramm zu schreiben. Dazu muss man auch die Passwörter abspeichern (momentan bin ich noch bei Single Tasking, was bedeutet, dass ich momentan nur einen POP3- oder SMTP-Server bedienen kann.) Ich will mir jetzt nicht nachsagen lassen, ich schreibe die Passwörter einfach so in die Registry, also habe ich da ein Verfahren entwickelt. Wie kann ich die Effektivität meines Algorithmus überprüfen. Ich will ja nicht, das mein Programm kaum auf dem Markt ist, und schon ist die Verschlüsselung geknackt. Ich möchte vor allen Dingen auch die Resistenz gegen aktive Angriffe testen, also wo jemand haufenweise Passwörter verschlüsseln lässt und guckt, was damit passiert. Den Algorithmus zur Verschlüsselung werde ich verständlicherweise nicht posten.
Tschö,
nullplan |
Ich bin mir ziemlich sicher, das nullplan001 Mehrere Passwörter meinte, die er verwenden will um sich an diversen Servern anzumelden. Aber bevor ich noch weiter durch die gegend zitiere und behaupte, das ich sowieso alles besser weiß, bring ich lieber ne neue Idee:
Wie währe es, aus einem (möglichst kryptischen) Passwort einen Key über irgend welche Hashs zu generieren. Somit hat man kein Problem mehr, wie man ihn aufhebt. Mann müsste eben nur möglichst zufälligen "Datenmüll" aus ca. 10 Zeichen saugen. ([sehr] Billige Variante: Zufallsgenerator als Seed mit nem Hashwert aus dem PW füttern)
@Nullplan: wegen dem XOR... Ich meinte nur, es währe das erste, wonach ich schauen würde, wenn ich auf eine schwache Verschlüsselung hoffe. Und auf mehr läufts nicht hinaus. Vor allem bei "Known Plaintext"...
_________________ LifeIsToShortToThinkAboutTheShortness
|
|
|