QSettings Passwort verschlüsselt abspeichern ?

[Treehouse]

Hallo,

ich würde gerne mal wissen ob es möglich ist mit QSettings ein Passwort verschlüsselt zu speichern? Oder muss man umwege gehen über andere Libarys und wenn ja welche wären das dann und sind diese dann auch Plattform unabhänig?

Bit besten Grüßen

Treehouse

[macman]

Kommt drauf an was Du mit machen willst. Wenn es nur um einen Login für deine Anwendung geht, dann wird wohl QCryptographicHash reichen. Wenn Du allerdings das Passwort rekonstruieren musst, weil deine Anwendung es für irgendwas braucht, dann schau Dir mal QCA an.

[RHBaum]

Wenn Du allerdings das Passwort rekonstruieren musst, weil deine Anwendung es für irgendwas braucht, dann schau Dir mal QCA an.

Was soll er damit erreichen ???
fuers rekonstruieren das passwords braucht er nen synchronen Algo mit schluessel. wo sollte er den verstecken ? Auf nen austauschbaren medium ? dann kann er gleich das pwd da ablegen.
Ne richtig Sichere Methode kriegt er da ned hin, sobald die Angreifer verschluesslte und unverschluesselte beispiele bekommen. Und er sogar nen üblichen Algorythmus verwendet ...
Also wuerde er da swoieso nur nen sehr sehr schwachen schutz hinbekommen, also lohnt sich der aufwand eines richtigen Algos ned ...

Also doch lieber (nur) die asynchrone Methode, wo das passwd wenigstens sicher ist ...
Den "zugang" kriegst nie sicher, sobald er irgendwas da in den settings anlegt.

Ciao ...

[Treehouse]

Also bedeutet das im Klartext, das ich das Passwort in Plain text abspeichern soll? Ist das so richtig bei mir angekommen?

[Treehouse]

Ich will nur ein Passwort in einer config speichern und beim Programm Start wieder entschlüsseln so das ich es benutzen kann. Und das Passwort sollte in der Config nicht gerade in Klartext sein das ist alles was ich wollte.

Soll ich darfür nun QCryptographicHash verwenden ??

[pfid]

Soll ich darfür nun QCryptographicHash verwenden ??

Damit kannst dus nicht wieder entschlüsseln.

[gerome69]

Also, ich habe mir mal den Algorythmus von filezilla angeschaut und den umgesetzt für Qt. Code siehe unten.
Er geht in beide Richtungen.
Was die Sicherheit der Verschlüsselung angeht, vermag ich das nicht zu beurteilen.

Gruß, Gérôme

Code: Alles auswählen

#define SECRET_KEY QString("WHAT_EVER")

QString crypt(const QString &plainText) {
    QString encText="";
  
  char buffer[3];

    int pos=plainText.length()%SECRET_KEY.length();

    for (int i=0;i<plainText.length();i++) {
        sprintf(buffer, "%03d", (unsigned char)plainText[i].toAscii()^SECRET_KEY[(i+pos)%SECRET_KEY.length()].toAscii());

        encText=encText+QString(buffer);
	}

    return encText;
}

QString decrypt(const QString &encText) {
    QString plainText="";

    QChar c;
    char digit;

    int pos=(encText.length()/3%SECRET_KEY.length());

    for (int i=0; i<encText.length()/3; i++) {
		int number=0;

        c=encText[i*3]; digit=c.toAscii();   if (digit<'0'||digit>'9') return "";
		number+=(digit-'0')*100;
        c=encText[i*3+1]; digit=c.toAscii(); if (digit<'0'||digit>'9') return "";
		number+=(digit-'0')*10;
        c=encText[i*3+2]; digit=c.toAscii(); if (digit<'0'||digit>'9') return "";
		number+=digit-'0';
        plainText=plainText+QChar(number^SECRET_KEY[(i+pos)%SECRET_KEY.length()].toAscii());
	}

    return plainText;
}

[RHBaum]

@Treehouse

Sobald du was irgendwo aufn nen ort wo andere nicht draufkommen ablegst, ist es nicht mehr sicher. Das ist klar oder ?

Um irgend etwas zu encrypten, brauchst du nen schluessel. Damit wandert die sicherheit von dem was verstecken willst zum schlussel. Deine Daten sind dann genau so sicher, wie sicher du den schluessel verwahren kannst. Bei synchronen Mechanismen musst du immer davon ausgehen:
- Wenn wer den Schluessel hat, wird er die Daten entschluesseln koennen
- Wenn wer beliebig Datenpaare erzeugen kann, wird er den schluessel zurueckrechnen koennen.
- Nur die Art des Verschluesselns geheimzuhalten, ist kein schutz.

Das ist dein Dilemma, irgendwas musst du vertecken ... und was "im programm" zu verstecken ist immer urks.....

Du wirst den "zugang" also nie richtig absichern koennen, sobald du was fuer andere zugaenglich hinterlaegst, und keine komponente zurueckhaelst. Also das sich wer irgendwo automatisch anmeldet ist immer unsicher irgendwie.

Was man aber schuetzen kann, ist das passwort selber.
Da kommen die asynchronen Methoden, also die hashes ins Spiel. Merkmal einer solcher methode ist.
DatenUnverschluesselt -> Key -> DatenVerschluesselt ist immer eindeutig
Aber:
DatenVerschluesselt -> Key -> DatenUnverschluesselt ist nicht eindeutig. Das heisst man koennte aus verschiedenen Daten den selben verschluesselten Datensatz bekommen. Andersrum ausgedrueckt, mit Dem wissen der verschluesselten daten und dem Schluessel Selber, Kannst du dir fast unendlich viele unverschluesselte daten ausrechen, mit dem der Mechanismus funktionieren wuerde, ergo -> du kannst von dem Verschluesselten daten nicht mehr auf die unverschluesselten zurueck.

Asynchrone Methoden eignen sich dann hervorragend dafuer, Passwoerter zu verstecken.

Um sowas nutzen zu koennen, musst du allerdings die gewalt ueber die passworter haben. Das heisst, schon verhandene Passwoerter nachtraeglich zu verschluesseln wuerde nur gehen, wenn du die in der anwendung aendern kannst.

Zu deutsch, du laesst dem user nen password eingeben. das password verschluesselst(hashst) du sofort. Dann legst den Zugang fuer den User mit dem hash als Password an, bzw aenderst das passwort auf den hash.
Dann kannst den Hash in den Settings auch speichern und zum anmelden nehmen.

Wie gesagt, du schuetzt nur das passwort selber.
Beispiel Unix ----
Wenn ich an die /etc/password rankomme (wo user und das gehashte password drinnstehen), kann ich mir mit grundlegensten mitteln nen login programm schreiben, wo ich mich mit als beliebiger user da und den hash direkt als passwort anmelden kann. Der zugang iss also ned sicher.
Aber ich kann nicht sagen, welches passwort der user orginal verwendet hatte ...
Ich koennt mir aber auch ein passwort ausrechnen, eines von vielen moeglichen, und mich als der user direkt ueber die orginal login anmelden. Wuerde funktionieren, aber die chance, das ich das selbe wie der user rauskriege waere 1: irgendwas millionen oder milliarden.

Ausgefeilte verschluesselungsmethoden nutzen meist beides, assynchrone (langsam) und feste Schluessel um die schluessel fuer den synchronen Datenaustausch auszutauschen, die daten selber werden dann natuerlich synchron verschluesselt.

Fuer deinen Anwendungsfall:
WIllst du richtig sicher bleiben (zugang), speichere dein paswort nicht ...
Willst du weitgehendst sicher sein (zugang), verlasse dich auf das BS. Und speichere dein Passwort irgendwo wo nur der user und der admin Zugriff haben. bei unix geht das, bei windows wird das eher schwerer. geht aber auch ...
Geht es nur im den Komfort und ned die sicherheit (zugang), dann leg es irgendwo ab ...
Willst Du nur cryptologischen Daus fernhalten, benutze irgend nen rotationsmechanismus und halte das prinzip geheim

Hasst du die moeglichkeit die passwoerter zu aendern oder du legst sie soweiso selber an, dann verwende immer hashes. (passwort selber zumindest sicher) !!!

Hoffe das war verstaendlich ....

[Treehouse]

@ RHBaum

Hoffe das war verstaendlich ....

Das war sogar sehr verständlich und sehr hilfreich. Ich danke dir vielmals das du dir die Mühe gemacht hast, detaliert zu erklären was es mit den verschiedenen Verfahren auf sich hat. Das ist, wie ich leider in letzter Zeit in immer mehr Foren feststellen muss, eine absolute Seltenheit geworden. Meist werden immer nur Brocken hingeworfen aus dennen man dann schlau werden soll. Aber egal das gehört hier nicht hin und hat nichts mit dem Thema zu tun.

Nochmal ein großes Lob

Zu deutsch, du laesst dem user nen password eingeben. das password verschluesselst(hashst) du sofort. Dann legst den Zugang fuer den User mit dem hash als Password an, bzw aenderst das passwort auf den hash.
Dann kannst den Hash in den Settings auch speichern und zum anmelden nehmen.

Wie du weiter unten du schon richtig erwähnt hast, scheint diese Methode dann für mein Vorhaben genzlich unangebracht zu sein. Denn das Passwort gehört nicht zu meiner Anwendung sondern zu einem Email Account was bedeudet ich müßte aus dem Hash den Weg zurück bekommen was ja wie ich jetzt gelernt habe nicht möglich ist.

Willst du weitgehendst sicher sein (zugang), verlasse dich auf das BS. Und speichere dein Passwort irgendwo wo nur der user und der admin Zugriff haben. bei unix geht das, bei windows wird das eher schwerer. geht aber auch ...

Ich denke das wird die Methode meiner Wahl werden. Unter Unix liegt die Datei eh schon im Home Verzeichniss und auf dieses hat bekanntlich nur der User selbst und der Root Zugriff. Unter Windows werde ich das Passwort dann sehr wahrscheinlich auch im jeweiligen User Verzeichniss unter Anwendungsdaten parken. Ich denke das macht Sinn. ( Zumindest hoffe ich das )

In diesem Sinne besten Dank an alle die geholfen haben.

Gruß

Treehouse

[RHBaum]

Unter Linux, zumindest unter Gnome und KDE gibt es eine andere Möglichkeit.
Der Schluesselring ....
Der macht nix anderes als alle passwoerter in einen gesicherten Datenblock zu schreiben. Der datenblock selber ist wiederum nur per Schlussel (configurierbar ob passwort, usb stick, Chipkarte, oder dem System vertraut) gesichert.

Was man erreichen will damit, ist das man statt viele unterschiedliche Passwoerter nur 1 zusaetzliches passwort hat.
Da gibts auch ne API fuer, die man in seinen Programmen nutzen kann ... und wenn das auf dem rechner eh schon in verwendung ist, isses ne gute sache sich da einzuklinken ...

Unter windows gibts sowas nur als third party tool ... Obs da was gescheites gibt ... keine ahnung.

Weiss nicht wie professionell deine anwendung ist ... und wie "kritisch" die Kunden dazu, aber ich wuerde empfehlen das speichern des passwortes unbedingt optional machen. Wenn man was unsichereres mit seinen Programmen "erzwingt", geraet man genz schnell in die Kritik ... mit ner Option kamm man es immer noch aufn user schieben

Ciao ...

[Treehouse]

Unter Linux, zumindest unter Gnome und KDE gibt es eine andere Möglichkeit.
Der Schluesselring ....

Ja du hast Recht diese Möglichkeit des Keyrings kenne ich. Du wirst lachen daran habe ich auch schon gedacht, aber das Programm soll Plattform unabhängig Programmiert werden und ich habe dann das Problem das ich mir für Windows wieder was neues ausdenken muss.

Ich werde die Speicherung Optional machen dann gehe ich wie du schon richtig angemerkt hast Kritikern aus dem Weg. (VORERST!!)

Auf Dauer werde ich sehr wahrscheinlich eine Blowfish Implementierung einbinden. Da habe ich schon ein paar nette Ansätze gefunden.

Gruß

Treehouse