Hallo!
Mein Vorschlag in aller kürze: die @Pwd$()-Funktion vom aktuellen Profan 7.0 durch eine einfach XOR-Verknüpfung ersetzen. Im folgenden will ich zeigen, warum.
Ich habe mal die @Pwd$()-Funktion von Profan getestet. Ein String wurde mit "PRO" verschlüsselt und danach wurden einfach alle dreistelligen möglichen Passwörter ausprobiert (im Bereich A-Z)(Brute-Force-Attack).
Erschreckendes Ergebnis: 252 Passwörter passten!!!
Nun nehmen wir einmal an, dass ein Passwort-Feld mit maximal 26 verschiedenen Zeichen
"besetzt" werden darf (A-Z). Das wären dann mit einer Brute-Force-Attacke genau
26*26*26 = 17576 Möglichkeiten, wenn man alles ausprobiert. Wenn nun 252 Passwörter passen
würde das heissen, dass ca. jedes 68. Wort passt! Ein bisschen viel oder?
Bei einem Passwort von einem Zeichen ist es sogar jedes 4. Passwort!!!!!!!
Bei einem Passwort von zwei Zeichen ist es jedes 16. Passwort.
Bei einem Passwort von drei Zeichen ist es, wie oben schon geschrieben, jedes 68. Passwort.
Bei einem Passwort von vier Zeichen ist es jedes 259. Passwort. (1764 Passwörter von 456976 möglichen passten)
Wie man sieht, steigt die Sicherheit pro verwendetes Zeichen. Trotzdem sind eine Quote von jedem 68. Passwort bei 3 Zeichen extrem viel!
Diese Zahlen lassen sich ziemlich einfach erklären: (da ich den Delphi-Quellcode der
Funktion nicht habe, vermute ich den folgenden Teil)
nehmen wir einmal an, Profan würde jeden Buchstaben einer von 4 "Klassen" zuordnen.
Das würde dann die Quote von 4 bei einem Passwort von 1 Zeichen erklären.
Wenn man nun sich vorstellt, dass Profan schön einfach das nächste Passwort-Zeichen
mit dem nächsten Plaintext-Zeichen verschlüsselt ergibt sich:
4 Möglichkeiten für das erste Zeichen, 4 Möglichkeiten für das zweite Zeichen
-> 4 * 4 = 16 Passt!
Weiter, nochmal das gleiche mit 3 Zeichen:
-> 4 * 4 * 4 = 64, Messung: 68, passt also auch ungefähr. Anscheinend gibt es doch noch
eine klitzekleine Veränderung.
Und nocheinmal mehr (mit 4 Passwort-Zeichen:
-> 4 * 4 * 4 * 4 = 256. Messwert: 259. Passt also auch ungefähr!!!!!
Und nun meine Frage (an Roland): warum diese seltsame Verschlüsselung? Warum nicht einfach die XOR-Funktion verwenden und jedes Plaintext-Zeichen ganz einfach mit dem passenden Schlüssel-Byte XORren?
Also praktisch: (bei einem Passwort von 3 Zeichen)
das 1. Zeichen mit dem 1. Schlüssel-Zeichen.
Das 2. mit dem 2. Schlüssel-Zeichen.
Das 3. mit dem 3. Schlüssel-Zeichen.
Das 4. mit dem 1. Schlüssel-Zeichen.
Das 5. mit dem 2. Schlüssel-Zeichen.
Das 6. mit dem 3. Schlüssel-Zeichen.
Das 7. mit dem 1. Schlüssel-Zeichen.
u.s.w...
Mit dieser Methode funktioniert wirklich nur EXAKT das Passwort, das zum Verschlüsseln benutzt wurde! Exakt! D.h. bei 17576 Möglichkeiten nur 1 Möglichkeit für richtiges Passwort! (und nicht 252!).
Einen Sonderfall muss man allerdings berücksichtigen: wenn das Schlüssel-Byte = Plaintext-Byte ist dann darf NICHT verschlüsselt werden! Sonst würde ein 0-Byte entstehen, was den String beenden würde!
Also ich keinen Grund warum man diese seltsame Verschlüsselung, die gerade im aktuellen Profan 7.0 verwendet wird, einer einfachen XOR-Verknüpfung vorziehen sollte.
Man bräuchte die Funktion nicht einmal in zwei Funktionen (Verschlüsselung/Entschlüsselung) splitten, da:
'Original-Byte' XOR 'Schlüssel-Byte' = 'Verschlüsseltes Byte'
'Verschlüsseltes Byte' XOR 'Schlüssel-Byte' = 'Original-Byte'
Vielleicht habe ich aber auch irgendwo einen Denkfehler... was meinst du Roland?
Wer mir nun die obigen Messungs-Zahlen nicht glauben sollte, ein Test-Programm in Profan. Zum Testen mit mehreren oder weniger Schlüssel-Zeichen ist Programm dementsprechend anzupassen.
DECLARE OriginalString$, TestString$, CryptedString$, Password$, Num1%, Num2%, Num3%, bEnd%
DECLARE _dlg%, m_lb%, m_static%, Temp%, nMode%
LET OriginalString$ = "Dies ist der Test-String!"
LET TestString$ = ""
LET Num1% = 65
LET Num2% = 65
LET Num3% = 65
LET bEnd% = 0
PASSWORD "PRO"
CryptedString$ = @Pwd$(OriginalString$)
WindowStyle 240
WindowTitle "@Pwd$()-Tester"
Window 0,0 - 1,1
USEFONT "MS Sans Serif", 10, 0, 0, 0, 0
SetDialogFont 1
PROC CreateReportDlg
let _dlg%=@createdialog(%Hwnd,"@Pwd()-Tester",208,144,295,531)
let m_lb%=@createsortedlistbox(_dlg%,"",8,48,272,448) ' 1484
let m_static%=@createtext(_dlg%,"",8,24,272,16) ' 1316
@createtext(_dlg%,"Aktuelles Passwort:",8,8,176,16) ' 2900
ENDPROC
PROC DestroyReportDlg
LET Temp% = @DestroyWindow(_dlg%)
ENDPROC
CreateReportDlg
While @Equ(bEnd%, 0)
INC Num1%
IF @Equ(Num1%, 91)
Num1% = 65
INC Num2%
ENDIF
IF @Equ(Num2%, 91)
Num2% = 65
INC Num3%
ENDIF
IF @Equ(Num3%, 91)
Num3% = 65
LET bEnd% = 1
ENDIF
LET Password$ = @Chr$(Num3%) + @Chr$(Num2%) + @Chr$(Num1%)
SetText m_static%, Password$
PASSWORD Password$
LET TestString$ = @Pwd$(CryptedString$)
IF @Equ$(TestString$, OriginalString$)
@AddString(m_lb%, Password$)
ENDIF
EndWhile
MessageBox "Fertig!", "@Pwd$()-Tester", 64
MessageBox @Str$(@GetCount(m_lb%)), "Gefundene funktionierende Passwörter:", 64
DestroyReportDlg
END
|