Indexierung von Elementen aus Strings fehlerhaft?

[m.fuchs]

Also, erstmal Danke an die ganzen Beiträge. Den Ironie-Kram hätte man sich sparen können. So etwas kann ich nicht leiden.

<Ironie>Das tut uns leid.</Ironie> SCNR

Ich verstehe nicht ganz, was es mit der (Byte-)Länge der einzelnen Zeichen auf sich haben soll.
Ich dachte, dass Lazarus intelligent genug wäre, um ein einzelne Zeichen aus einem String auszulesen. Das klappt zwar, aber manche Zeichen werden eben nicht ausgegeben, wie eben die Umlaute.

Das Thema String-Encoding kann hier zu abendfüllenden Diskussionen führen. Die dann auch mehr oder weniger zivilisiert ablaufen. Da mögen sich dann berufenere Menschen als ich äußern.
Nur meine Meinung: Man muss bei Lazarus im Zusammenhang mit String ein bisschen mehr nachdenken und ausprobieren, ehe es funktioniert. Das ist wohl auch der Preis für Multi-Plattformfähigkeit. In meinen Augen ein kleiner Preis.

@m.fuchs: Dein Code ist hilfreich, danke. Aber es kostet viel Zeit, das zu definieren. Gibt es denn keine andere Möglichkeit, die weniger Tipparbeit erfordert? Klar, ich könnte das einfach kopieren, aber ich würde gerne weniger Code verwenden.

Ist ja nur eine Möglichkeit. Alternativ kannst du AFAIK auch mit der Funktion UTF8Copy aus der Unit LazUTF8 ein beliebiges Zeichen aus deinen String kopieren.

[BeniBela]

huh, schon zweite Seite und noch niemand hat

Code: Alles auswählen

 
{$codepage utf8}
interface
const
  Charset: UnicodeString = '^°!"²§³$%&/{([)]=}?\`´*+~''#_-:,;µ@|<>1234567890qwertzuiopüäölkjhgfdsayxcvbnmQWERTZUIOPÜÄÖLKJHGFDSAYXCVBNM';
 

vorgeschlagen?

[m.fuchs]

Stimmt, das {$codepage utf8} kann nützlich sein. Allerdings löst es alleine noch nicht das Problem. Die Kopiererei muss trotzdem mit den UTF8...-Funktionen passieren.
Oder übersehe ich noch etwas?

[Socke]

Stimmt, das {$codepage utf8} kann nützlich sein. Allerdings löst es alleine noch nicht das Problem. Die Kopiererei muss trotzdem mit den UTF8...-Funktionen passieren.
Oder übersehe ich noch etwas?

Der Compiler sollte den Inhalt des Strings jetzt nicht mehr als reine Bytefolge interpretieren. Stattdessen nimmt er die Codierung UTF-8 an und kann diese in den Typ Unicodestring konvertieren. Wenn man jetzt UnicodeChar in der Schleife verwendet, sollte doch alles in Butter sein?

[mschnell]

Wenn Du wirklich mit String - Indexen arbeiten möchtest, solltest Du den betreffenden Abschnitt in Deinem Code mit UTF-16 Strings programmieren und nicht mit den (in Lazarus momentan defaultmäßig verwendeten) UTF-8 Strings. Entsprechende Umwandlungs-Funktionen gibt es in der Lazarus Library.

Du kannst die String - Intexierung aber sicher auch vermeiden (ist ja keine high-Performance-Anwendung).

-Michael

[m.fuchs]

[...]Wenn man jetzt UnicodeChar in der Schleife verwendet, [...]

Vielleicht stehe ich gerade auf dem Schlauch, aber wie macht man das?

[theo]

@Dee: Vllt. solltest du den ganzen Ansatz überdenken und das gleich von Anfang an International machen mit Unicode.
Die Unit character gibt z.B. Auskunft über die Art eines Unicode Zeichens (IsNumber, IsCharacter, IsSeparator...).
Ich verstehe auch nicht ganz, warum der User die möglichen Zeichen selber auswählen soll.

Man müss sonst übrigens auch nicht unbedingt an der Codepage schrauben, so geht auch

Code: Alles auswählen

 
const
  CharsetUTF8 = '^°!"²§³$%&/{([)]=}?\`´*+~''#_-:,;µ@|<>1234567890qwertzuiopüäölkjhgfdsayxcvbnmQWERTZUIOPÜÄÖLKJHGFDSAYXCVBNM';
var
  CharsetUC:UnicodeString;
 
....
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  CharsetUC:=UTF8Decode(CharsetUTF8);
  TuWasDamit;
end;

[theo]

[...]Wenn man jetzt UnicodeChar in der Schleife verwendet, [...]

Vielleicht stehe ich gerade auf dem Schlauch, aber wie macht man das?

Ich weise in diesem Zusammenhang auch gerne auf Unit unistring hin:
http://www.lazarusforum.de/viewtopic.ph ... ing#p54025

[Antrepolit]

Ich verfolge diesen Thread schon länger. Vllt. kann mir mal jemand erklären, warum ein Passwort überhaupt Sonderzeichen und Zahlen enthalten muss. Ausschlaggebend für die Sicherheit ist ja die Länge des Passwortes, nicht der Zeichenvorat. Bei Dictionary-Attacken kriegt man ja schon einfache Passwörter (vor allem Namen) einfach raus. Bei Sonderzeichen braucht man Brute Force, aber auch Sonderzeichen und Zahlen sind da kein Problem mehr, bei - sagen wir - 8 Zeichen. Das dauert mit "John the ripper" nicht lange. Wenn man jedoch ein langes Passwort nimmt - z. B. ein vollständiger Satz ohne Leerzeichen wie "HeuteNachtWirdEsFrühDunkel", dann ist das Passwort sehr viel sicherer als mit kryptischen Sonderzeichen, die sich ohnehin kaum jemand merken kann. Denn der Aufwand zum Knacken des Passwortes ist immer Zeichenvorat^Anzahl_Zeichen. Und unabhängig von Sonderzeichen und Zahlen bleibt es der selbe Aufwand für standardisierte und gut beschriebene Angriffsverfahren wie Wörterbücher und Brute Force.

Darum sind meine Passwörter immer möglichst lang. Ich werde nur nie verstehen, warum dann Administratoren von irgendwelchen Seiten Maximallängen vorgeben für Passwörter, wenn später daraus ohnehin ein Hash errechnet wird. Das wirkt der Sicherheit entgegen.

[mschnell]

http://www.lazarusforum.de/viewtopic.php?f=29&t=5894&p=54025&hilit=unistring#p54025

Sicher die beste, benutzerfreundlichste Lösung hier !

-Michael

[Dee]

Ich bin ich erstaunt, dass es so viele Beiträge mittlerweile zum meiner Frage gibt. Danke euch!

@Dee: Vllt. solltest du den ganzen Ansatz überdenken und das gleich von Anfang an International machen mit Unicode.
Die Unit character gibt z.B. Auskunft über die Art eines Unicode Zeichens (IsNumber, IsCharacter, IsSeparator...).
Ich verstehe auch nicht ganz, warum der User die möglichen Zeichen selber auswählen soll.[/code]

Ich möchte das Programm aber nur auf bestimmte Zeichen beschränken. Außerdem ist der Zeichenvorrat schon groß genug. Vielleicht werde ich bei Gelegenheit den ganzen Unicode-Zeichensatz implementieren. Außerdem muss ich auch sehen, dass ich die Zeichen auch mit der Methode keybd_event() gedruckt bekomme.

Ich habe meine eigene Funktionen geschrieben, welche ermitteln, ob das Zeichen eine Zahl, ein Buchstabe oder ein Sonderzeichen ist. Aber danke für den Hinweis mit der Unit char. Ich werde sie mir mal bei Bedarf ansehen.

Der Nutzer soll deshalb den Zeichvorrat bestimmen können, weil manche Seiten bestimmte Zeichen nicht unterstützen oder nur Zahlen oder Buchstaben zulassen. Vielleicht möchte man nur eine PIN-Nummer generieren, dann sind Buchstaben und Sonderzeichen fehl am Platz.

... Denn der Aufwand zum Knacken des Passwortes ist immer Zeichenvorat^Anzahl_Zeichen ...

Durch Weglassen der Sonderzeichen ergeben sich weniger Kombinationsmöglichkeiten. Wenn du danach gehst, dass die Länge das entscheidene ist, dann könnte man auch nur ein Zeichen x-mal wiederholen, sei es ein Buchstabe, eine Zahl oder sogar das Leerzeichen.

Wenn jetzt aber jeder auf Sonderzeichen verzichten würde, dann würden die BruteFroce-Angriffe viel schneller das Passwort herausfinden können, da weniger Kombinationsmöglichkeiten durchprobiert werden müssten.

Ich werde nur nie verstehen, warum dann Administratoren von irgendwelchen Seiten Maximallängen vorgeben für Passwörter, wenn später daraus ohnehin ein Hash errechnet wird.

Würdest du den Teil mit dem Hash bitte etwas näher erläutern? Mich interessiert das sehr was es damit auf sich hat. Maximallängen kann ich auch nicht nachvollziehen. Auch verstehe ich nicht, warum manche Websites beim Passwort Restriktionen bezüglich der Zeichenwahl stellen.

PS: Mein Problem habe ich schon behoben.

[creed steiger]

http://xkcd.com/936/



http://de.wikipedia.org/wiki/Hashfunktion

es sollten keine Klartextpasswörter im System/Datenbank wasauchimmer gespeichert sein , sondern nur der Hashwert der dann gegen die Passworteingabe geprüft wird.
So wird verhindert das bei einem Angriff Klartextpasswörter gestohlen werden.

[Dee]

http://xkcd.com/936/

Okay, überzeugt...

es sollten keine Klartextpasswörter im System/Datenbank wasauchimmer gespeichert sein , sondern nur der Hashwert der dann gegen die Passworteingabe geprüft wird.
So wird verhindert das bei einem Angriff Klartextpasswörter gestohlen werden.

Skandal, dass nicht überall für das Passwort der entsprechende Hash gespeichert wird.