@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 ....
)