qtforum.de

Hallo,

ich habe eine Applikation geschrieben, welche nun HTTP/GET fähig werden soll. Dafür habe ich ein Dialog geschrieben, in welchem ich alle relevanten Einstellungen via in eine *.ini Datei schreibe und von dort lese.

Desweiteren habe ich in der *.ini Datei auch einen Abschnitt Network mit den Werten
proxy=127.0.0.1
port=5648
user=paul
password=

Diese lese ich dort aus und setzte damti mein Proxy. Jedoch wollte ich das Passwort für den Proxy nicht im Klartext ablegen. Gibt es im Qt Framework dafür schon ein schönen ControlObject, wie QCryptographicHash ?

Wobei: QCryptographicHash würde mir hier nichts bringen, da ich aus dem Hash wieder das Klartext berechnen müsste, um dies mein QNetworkProxy Objekt zu füttern..

Gibt es da was elegantes?

Ich danek schonmal, und viel Grüße
Paul

Nein, kann es auch nicht .....

Wenn man sich mal grob/näher mit cryptografie beschaeftigt, wird einem das auch schnell klar ...
passwörter ohne noch einen "secret" synchron verschlüsseln geht einfach nicht ... und secrets auf dem pc zu verstecken ist auch unsicher ....

Zu den hashes:
hashes sind assynchron. d.h. die hashfunktion errechnet dir aus einem datensatz genau einen Hash. Aber aus dem Hash koenntest du unendlich viele datensätze zurueckrechnen ....
Hashfunktionen bieten deshalb auch Schutz für das Passwort ... nicht für den Zugang.
D.H alle eingabemasken müssen die hashfunktion benutzen, und jegliche übertragung über unsichere medien darf nur per hash und nicht per klartext erfolgen ...
oder du musst dem Weg/Server vertrauen.
SSH zum beispiel bietet ausreichend schutz da iss nen klartext passwort kein problem an sich
aber der server entschlüsselt das wieder, aka die server app sieht oft das passwort im klartext.

Passwort sicherheit bedeutet: wird ein Server kompromittiert, ist zwar dein Zugang im A... (also usicher) aber dein orginal Passwort, was eventuell für andere Seiten auch verwendest, bleibt sicher ... solange die server unterschiedliche Hash funktionen / Salts verwenden .... und die Server Apps selber nicht kompromittiert werden.

Das die Theorie.
DIe Praxis ist:
Hash funktionen auf dem client machen nur Sinn vor dem Zugriff aufs Netz, andere rechner ....
Aufn server bieten hashes oft nur Passwort schutz, wenn die Serialization ebene gehackt wird (datenbank) .... aber sobald die App selber übernommen wird, sind die passwörter auch im A.....

wenn du zugriff auf Beides hasst , server und client, isses einfach und sicher hashes zu verwenden ....
Greifst du nur mit einer App / einem weg auf den server zu, kannst du generell auch nur den hash verwenden und die eingabemasge so bauen das sie die eingabe umwandelt (komfort)

wenn du über mehrere wege auf den server zugreifst wirds fast unmöglich da Schutz zu bieten ....
das heisst alle zugangswege müssten definierte Hash funktionen verwenden ... auf http/formularebene müsste das clientseitig erfolgen.
Alles andere ist unsicher

verwendest für jede App /zugang soweiso nen eigenes generiertes Passwort (also sowas wie ne eigene hash funktion) ohne zurückverfolgbare Logik, bist nicht auf Passwortsicherheit der Apps angewiesen ..... iss halt nur nicht wirklich Komfortabel ....

Hoffe das hilft bissi und gibt Anstoss nachzudenken und zu begreifen, das ne lokale passwortverschlüsselung ohne secret nichts bringt ...

Ciao ....

Unter Windows würde ich DPAPI verwenden (Windows kümmert sich um das Passwort zum ver- und entschlüsseln, speichern muss man aber noch selbst). So speichern auch die Windows Tools ihre Passwörter. Sicher ist das nur bedingt, da die DPAPI einfach nur verschlüsselt und entschlüsselt und jedes andere (Schad-)Programm im User-Kontext könnte das auch. Aber es ist etwas sicherer, weil das Passwort des Nutzers benutzt wird und wird das einfach durch einen Angreifer zurückgesetzt, dann ist auch das DPAPI-PW zurückgesetzt. Es ist jedenfalls der einfachste Weg, das selber Verschlüsseln und Speichern loszuwerden. Unter Linux o.ä. würde ich vielleicht auf Passwort-Manager mit eigener API setzen. Vielleicht gibt es auch ein DPAPI-Äquivalent...

E*