NAS Verschlüsselung sinnlos?

  • ...also back to the roots...

    Daher als Rechnerschlüssel anlegen, diese funktionieren nur auf Deiner spezifischen Synology, dann auf einem USB Stick ablegen. Selbst wenn Du den Stick nun immer drin und vom Schlüsselmanager automatisch un-mounten lässt, muss jemand erstmal noch über Deine sicheren Zugangspasswörter zur Synology reinkommen.

    Das wäre jetzt eine Variante, wo das NAS ohne weiteres Zutun nach einem reboot (autoupdate, Stromausfall) wieder mit entschlüsselten Ordnern hochkommt und ein Dritter dennoch nur über reguläre Accounts (Passwörter) an die Daten kommt?

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • Wenn Du einen USB Stick als Speicher für den Schlüsselmanager definierst ist zumindest eine Anforderung erfüllt. Die Keys liegen nicht mehr intern auf der Synology.


    Folgendes grobes Vorgehen:

    • USB Stick auswählen und in die Synology einstecken
    • Am besten frisch formatieren (Systemsteuerung/Externe Geräte/Formatieren). Dominik von iDomix formatiert den Stick ext4 in seinem Video ... ist aber Dir überlassen
    • USB Stick mit passenden Name versehen (Systemsteuerung/Gemeinsame Ordner/Bearbeiten)
    • Den Schlüssel-Manager entsprechend zu Speicherung auf diesen USB Stick definieren (Systemsteuerung/Gemeinsame Ordner/Aktion/Schlüssel-Manager)
      => Benötigt eine weitere einzigartige Passphrase für den "Tresor".
      => Die Migration bestehender Schlüssel in diesen neuen "Tresor" auswählen.
      => Anschliessend bestehende Ordner nach und nach in den "Tresor" übernehmen, man benötigt jeweils einmalig das verwendete Passphrase. Empfohlenes Chiffre "Rechnerschlüssel"
      => Die Schlüssel so definieren, das der entsprechende Ordner beim Hochfahren automatisch gemountet wird.
    • In der Konfiguration des Schlüsselspeichers nun definieren, dass der USB Stick nach dem Hochfahren und Mounten aller verschlüsselten Ordner ausgeworfen wird

    Der USB Stick taucht nun nachdem Neustart nimmer im DSM auf, bis zum einmaligen Abziehen und wieder Einstecken, oder eben nächsten Reboot. Wobei er beim Reboot dann wieder automatisch nach dem Mounten aller verschlüsselten Ordner (logisch) ausgeworfen wird. Es dauert aber nach Reboot ein paar Minuten bis alle verschlüsselten Ordner wieder montiert sind und der USB Stick ausgworfen wurde.


    Wenn Du nun kein Terminal Zugriff auf die Synology zulässt, http auf https umleitest und noch die Zwei-Faktor Authentifizierung aktiviert hast, wird es schon schwierig irgendwie an die ranzukommen. Aber selbst wenn, muss derjenige erstmal den USB Stick irgendwie wieder auf der Synology sichtbar bekommen. Und wenn er das auch noch schafft, muss er dann noch über die Verschlüsselung des "Tresors" auf dem USB Stick überwinden um an die Schlüssel zu kommen. Die ja wie definiert als Rechnerschlüssel nur an Deiner spezifischen DS funktionieren. Aber dann hat er immer noch nur die Schlüssel und noch nicht Deine Passphrase(s).


    Aber die abschließende Sicherheit bietet am Ende natürlich nur das Abziehen des USB Stick nach jedem Reboot, das ist aber nun Deine Entscheidung ...

    HowTo: APT pinning

  • Wenn Du einen USB Stick als Speicher für den Schlüsselmanager definierst ist zumindest eine Anforderung erfüllt. Die Keys liegen nicht mehr intern auf der Synology.


    Folgendes grobes Vorgehen:

    ...

    Ehlich gesagt: Ich versteh kein Wort. Wo ist der Unterschied, ob die Schlüssel nun auf dem USB-Stick liegen oder der Platte, wenn ich bzw. der Dieb beides haben?

    Mein NAS dient nur zur Bereitstellung von Shares, u.a. um unsere Bilder auf mehrere Laptops zu synchronisieren. Terminalzugriffe, aus dem Internet u.ä. sollte nicht möglich sein. Aber bei meiner Blickung….

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • Ich hätte übrigens auch noch ne FritzBox oder nen Raspbery (primär für FHEM bzw. Heizungssteuerung und Hausautomatisierung) als Schlüsselplatform zu bieten...

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • Wo ist der Unterschied, ob die Schlüssel nun auf dem USB-Stick liegen oder der Platte, wenn ich bzw. der Dieb beides haben?

    Ok, fangen wir mal mit den technischen Details an, läßt Du die Schlüssel auf der Systempartition ablegen, werde diese in einem unverschlüsselten Bereich abgelegt, siehe "schlüsselspeicher_systempartition.png". Läßt Du die Schlüssel auf dem USB Stick ablegen, werden diese dort in einem gesondert verschlüsselten Bereich abgelegt, nennen wir es mal "Tresor", siehe "schlüsselspeicher_usbstick.png".


    Liegen die Schlüssel auf der Systempartition, kannst Du die da ja nicht einfach mal eben entfernen. Liegen die auf einem USB Stick kannst Du diesen jederzeit abziehen und die Schlüssel sind dann weg von der Synology.


    Wenn Du den Schlüssel-Manager entsprechend konfigurierst, ist der USB Stick nach dem Reboot nicht im System eingebunden, während die Systempartition immer eingebunden sein wird.


    Du erhöhst Deine Sicherheit alleine schon wenn die Schlüssel nicht mehr auf der Systempartiton liegen, weil der Zugriff deutlich erschwert wird, selbst wenn Du diesen stecken läßt.


    Für die perfekte Sicherheit zieht man aber am Besten den USB Stick nach Reboot ab, aber das möchtest Du ja nicht ...

  • Hauptunterschied mit den Schlüsseln auf dem USB-Stick:

    Wenn die Platte mal den Geist aufgibt, ist sie verschlüsselt und die Schlüssel dazu sind extern, also nicht auf der Platte. D.h. wenn jemand die aus dem Müll holt, kann er nichts damit anfangen. Man kann sie also gefahrlos entsorgen.


    Das ist auch der Hauptanwendungszweck für ein TPM. Es geht nicht darum, dass die Platten geschützt sind, wenn jemand den ganzen Rechner klaut, sondern dass man die Platten bei einem Wechsel ohne große Mühe entsorgen kann.


    Der USB-Stick ist in diesem Fall eine Art günstiger TPM-Ersatz.

  • Naja, da hilft im Zweifelsfall auch absolut zuverlässig die Hammermethode. Ich rede hier von Otto-Normalverbraucher, für den ein NAS wie meines ja wohl primär gedacht ist. Da sollte die Sicherheit soweit als möglich ootb vorhanden sein, ohne kniefizlige Zusatzorgien. Nebenbei verringert Komplexität neben der Zuverlässigkeit auch die Sicherheit.

    Wie es ohne Zusatzbrimborium prinzipiell ginge habe ich ja schon geschrieben: Schlüssel über Hashes (+ Salt (+ Pepper)) der Passworte verschlüsselt ablegen. Dann noch über (Default) Passwortregeln sichere Passworte erzwingen. Fertig!

    Aber ist halt nicht so. Ich packe mein NAS jetzt entweder mit hinter die Kaminklappe in den Kaminschacht, den ich ohnehin für die Steigleitungen nutze, oder hänge einen Stick via USB im Nachbarraum daran. Da liegt noch eine USB-Verlängerung aus Zeiten, wo ich meine Heizungsanlage via USB-Karte und i386-Desktop aus dem Nachbarraum gesteuert habe...

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • Oft bezahlt man gerade bei Komplettlösungen, wie es die Massen NAS Systeme nun mal sind, mit eingeschränkten Konfigmöglichkeiten. Gern werden auch sinnlose Features ( oder teils sogar Bugs ) als ach so tollen Zusatz beworben. So hab ich auf Mineralwasser auch schon groß gelesen : "Neu ! Jetzt Laktosefrei und für Veganer geeignet". Ist in der IT Welt nicht anders - Alle bekloppt *fg


    Ergo : Alles muss man selber machen !


    Ich verfahre folgendermaßen : NAS unverschlüsselt ( macht bei 24/7 auch nicht so viel Sinn ) dafür liegen auf dem NAS LUKS Container für alles Mögliche. Die LUKS Container werden via sshfs auf den jeweiligen Clients entschlüsselt. Hat den Vorteil, dass bei einem Kompromittieren NAS keine Schlüsseleingaben abgefangen werden können und das NAS nicht entschlüsseln muss.


    Alternativ könnte man eine Prüfsumme aus fest verbauten ( also Geräte, die immer online sind wie z.b. der Router ) Netzwerkgeräten genieren. Damit hätte man einen Schlüssel der Automatisch erzeugt wird und das System entschlüsselt. Startet man das NAS in einem anderen Netzwerk ( NAS wurde geklaut und steht beim Dieb zu Hause ) wird kein oder der falsche Schlüssel generiert. Man könnte auch ein Altes Handy nehmen und nur wenn dieses im WLAN ist wird nach dem o.g. Muster der Schlüssel generiert - das wäre auch DAU tauglich.



    Code
    1. EncKey=$(arp -a | grep -w '(192.168.1.1\|192.168.1.2)' | tr -d [[:cntrl:]] > /tmp/file && md5sum /tmp/file | cut -d " " -f1 && rm /tmp/file)
    2. echo $EncKey





    Ob das allerdings mit den "DAU" Systemen der Hersteller möglich ist bezweifle ich allerdings.


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO 860 Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 18 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 18 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de

    The post was edited 2 times, last by speefak ().

  • Ich habe ein Synology DS116 und dort von Anfang an alle Ordner mit Verschlüsselung angelegt. Ein Bekannter meinte nun, das bringe nicht wirklich was, denn jeder mit etwas Ahnung, der das NAS in die Hand bekäme, könne dort die Schlüssel problemlos auslesen. Was ich dazu bisher ergoogelt habe scheint das zu bestätigen.


    Hallo und zeitgleich sorry, wenn ich diesen alten Thread wieder ausgrabe.

    Wie ist diese Aussage zu verstehen?

    Das Auslesen des Schlüssels ist nur einfach möglich, wenn auch der verschlüsselte Ordner erfolgreich eingebunden und gemountet ist. Wenn der verschlüsselte Ordner jedoch nicht gemountet wurde und der Schlüssel auch nicht zur Verfügung steht, so ist eine AES-256bit Verschlüsselung nicht gerade ohne.

    Oder habe ich da was falsch verstanden?

  • Wenn das NAS Ordner automatisch entschlüsseln soll ( also ohne usereingabe ) muss der Schlüssel auf dem NAS hinterlegt sein. Wie die Hersteller die Schlüssel schützen kann ich nicht sagen, ich nutze keine Systeme von der Stange.


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO 860 Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 18 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 18 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de

  • Die Verschlüsselung nützt nur gegen Diebstahl der Geräte was - über Netzwerk kann, ggf. auch mit "anonymous", jederzeit zugegriffen werden.

    Daß auch nach einem Standby das Kennwort neu eingegeben werden muß, funktioniert bei Laptops, das NAS im Keller wird sich so aber nicht gut verkaufen :)

    Daher muß bei NAS-Lösungen z.B. das Vorhandensein einer "bekannten" MAC-Adresse im Netzwerk als (unzulänglicher) Ersatz dienen. Ich könnte mir auch ein über ein etwas längeres USB-Kabel angeschlossenes und etwas verstecktes Key-Device (USB-Stick) vorstellen, welches bei Diebstahl abgestöpselt wird.

    Oder das Kennwort zum Mounten der Datengräber, nicht aber des Betrübssystems, wird nach dem initialen Boot inkl. Netzwerkstack irgendwo im LAN abgefragt.

    Andere "Fertiglösungen" sind eher "obfuscation" als Verschlüsselung.

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 12 GB Ram, zram-swap/tmp, ubuntu-focal, softhddevice-vdpau
    ddbridge-6.5 mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF720 SFF passiv (nvidia-455, --no-unified-memory), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.4.5-patches, vdr-epg-daemon mit Frodo-plugins, Kernel 5.9.9-xfsscrub

    vdradmin-am, live+webstreaming, vdrmanager (Smartphones als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv. Folding@home läuft auf CPU.

  • Danke soweit. Dann konkretisier ich mal meine Frage.

    Kennt ihr meine Möglichkeit den verschlüsselten Ordner, dessen Key-Schlüssel (*.key) sich ebenso in diesem verschlüsselten Ordner befindet, wieder einzubinden?

  • Danke soweit. Dann konkretisier ich mal meine Frage.

    Kennt ihr meine Möglichkeit den verschlüsselten Ordner, dessen Key-Schlüssel (*.key) sich ebenso in diesem verschlüsselten Ordner befindet, wieder einzubinden?

    Noch unkonkreter hätte man die Frage jetzt aber nicht stellen können... :wand

    • Welches Betriebssystem?
    • Welche Verschlüsselung?
    • Mit welchem Programm angelegt?


    Was soll das bedeuten: "key sich ebenso in diesem verschlüsselten Ordner befindet"?

  • Danke soweit. Dann konkretisier ich mal meine Frage.

    Kennt ihr meine Möglichkeit den verschlüsselten Ordner, dessen Key-Schlüssel (*.key) sich ebenso in diesem verschlüsselten Ordner befindet, wieder einzubinden?

    Das Weltall ist super für Allergiker, denn da gibt es keine Pollen ...

    Du hast das PW vergessen und auf dem Datenträger gespeichert wo es verschlüsselt ist und möchtest zum entschlüsseln der Daten das in den Daten enthaltene Passwort nutzen ?

    Hast vllt. jmd. in Nähe der dir mal auf den Hinterkopf hauen kann ?


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO 860 Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 18 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 18 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de

  • Beide letzten Antworten sind analog dem Threadtitel "sinnlos". Dennoch antworte ich wie folgt, wenn auch die Diskussion scheinbar in speefak`s Weltall führt.

    Auch in diesem Fall handelt es sich um eine Synology, respektive einer AES 256-bit Verschlüsselung - respektive DiskStation Manager Betriebssystem. Würde es sich hierbei um ein gänzlich anderes System handeln, hätte ich wohl auch nicht auf diesen Thread aufgesetzt.

    Auf der Synology DS215j wurde ein verschlüsselter Ordner angelegt. Wegen dem eingestellten permanenten mounten wurde das Key-file in selbigen verschlüsselten Order abgespeichert. Durch ein Softwareupdate wurde allerdings der verschlüsselte Ordner dismounted. Seither besteht kein Zugriff auf den Ordner. So einfach ist die Geschichte, wenn auch äußerst depremierend. Für irgendwelch Besserwisserisches, ala dem dem Weltall- und Pollen-Philosoph hab ich im nachhinein äußerst wenig.

    Der Thread begann einst so, dass es für jemanden wohl kein Problem ist den Schlüssel auszulesen - egal wie und wo abgespeichert. Darauf wollte ich ansetzen...

  • Fährt das Betrübssystem etwa nie richtig runter? Beim shutdown muß doch alles unmounted werden, und irgendein Teil wird beim Booten das wieder mounten müssen. Was sagt der Synology-Support dazu?

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 12 GB Ram, zram-swap/tmp, ubuntu-focal, softhddevice-vdpau
    ddbridge-6.5 mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF720 SFF passiv (nvidia-455, --no-unified-memory), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.4.5-patches, vdr-epg-daemon mit Frodo-plugins, Kernel 5.9.9-xfsscrub

    vdradmin-am, live+webstreaming, vdrmanager (Smartphones als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv. Folding@home läuft auf CPU.

  • Beim Hochfahren wurde der Ordner automatisch gemounted, das konnte man einstellen. Das Softwareupdate hat allerdings diese Automatik deaktiviert und seitdem wird das Keyfile- oder Passworteingabe benötigt, um den Ordner wieder zu mounten - das befindet sich allerdings im ungemounteten, verschlüsseltem Ordner.

    Der Support zieht sich zurück, nachdem kein Zugriff auf das Keyfile oder das Passwort besteht.

  • Ja, aber auch für das automatische Mounten wird irgendwo das/ein (General?-)Passwort bzw. dessen Hash benötigt. Vielleicht sogar in einer Bibliothek "hardcoded"?

    Wenn dem nicht so ist, welches magische Tool erledigt zum Bootzeitpunkt das Mounten eines verschlüsselten Ordners?

    Wie auch immer ... siehe auch https://www.synology-forum.de/…utomatisch-mounten.89311/

    Vermutlich wurde das vor Version 6.1 irgendwie "obfuskatorisch" gelöst, das war aber doch ein Sicherheitsloch.

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 12 GB Ram, zram-swap/tmp, ubuntu-focal, softhddevice-vdpau
    ddbridge-6.5 mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF720 SFF passiv (nvidia-455, --no-unified-memory), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.4.5-patches, vdr-epg-daemon mit Frodo-plugins, Kernel 5.9.9-xfsscrub

    vdradmin-am, live+webstreaming, vdrmanager (Smartphones als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv. Folding@home läuft auf CPU.

  • Danke soweit. Dann konkretisier ich mal meine Frage.

    Kennt ihr meine Möglichkeit den verschlüsselten Ordner, dessen Key-Schlüssel (*.key) sich ebenso in diesem verschlüsselten Ordner befindet, wieder einzubinden?

    Beide letzten Antworten sind analog dem Threadtitel "sinnlos". Dennoch antworte ich wie folgt, wenn auch die Diskussion scheinbar in speefak`s Weltall führt.

    Auch in diesem Fall handelt es sich um eine Synology, respektive einer AES 256-bit Verschlüsselung - respektive DiskStation Manager Betriebssystem. Würde es sich hierbei um ein gänzlich anderes System handeln, hätte ich wohl auch nicht auf diesen Thread aufgesetzt.

    Auf der Synology DS215j wurde ein verschlüsselter Ordner angelegt. Wegen dem eingestellten permanenten mounten wurde das Key-file in selbigen verschlüsselten Order abgespeichert. Durch ein Softwareupdate wurde allerdings der verschlüsselte Ordner dismounted. Seither besteht kein Zugriff auf den Ordner. So einfach ist die Geschichte, wenn auch äußerst depremierend. Für irgendwelch Besserwisserisches, ala dem dem Weltall- und Pollen-Philosoph hab ich im nachhinein äußerst wenig.

    Der Thread begann einst so, dass es für jemanden wohl kein Problem ist den Schlüssel auszulesen - egal wie und wo abgespeichert. Darauf wollte ich ansetzen...

    Ich hatte eigentlich nur an den klaren Menschenverstand appelliert, nach dem Motto erst denken, dann fragen.

    Hier man die Fragen :
    - Welchen Sinn macht eine Verschlüsselung wenn diese einfach geknackt werden kann ?

    - Wenn der Schlüssel zum Safe im Safe liegt und dieser Verschlossen ist kann man den Safe nur mir Gewalt öffnen, geht das zu leicht s. obrige Frage.

    - Wieso Hinterlegt man den Schlüssel in dem verschlüsselten Ordner selbst ?

    - Warum wurden keine Backupserstellt ?


    Für die Zukunft : Erstelle dir ein LUKS Container ( https://speefak.spdns.de/oss_l…Container%20-%20Partition ) mit einem extrem Starken Passwort ( mind. 20 Stellen, alles Zeichen nutzen die es gibt, Groß/Kleinschreibung, Zahlen Sonderzeichen, kein zusammenhängendes Wort oder Satz s. https://speefak.spdns.de/oss_lifestyle/passwoerter/ ). Sichere den Luks Header falls dieser Beschädigt wird kann du mit der Sicherung auf die eigentlichen Daten zugreifen ( natürlich nur mit dem Passwort ). Wenn du dir das Passwort nicht merken kannst, schreib es auf und vergrabe es irgendwo, alternativ gib das Passwort einige Monate jeden Tag ein und du wirst es nicht mehr vergessen.

    Ansonsten bleibt nur zu sagen : Erstelle Backups von wichtigen Daten - das kann man nicht oft genug sagen, ich habe so viele Bekannte und Kunden denen ich das immer wieder sage und es wird ignoriert bis die Kacke am dampfen ist nur ist dann zu spät. Und mit Backups meine ich nicht einfach den Ordner auf dem gleichen System oder der gleichen Platte zu spiegeln sonder wirkliche Backups, auf einem Datenträger der offline und am besten in einem Anderen Gebäude liegt. Das ist nervig und aufwendig aber damit ist man wirklich sicher unterwegs.

    Und nun hab ich wieder auf eine sinnlose Geschichte geantwortet - die Hoffnung stirbt zuletzt : Erst denken, dann Handeln ...

    PS : du könntest ggf. das Passwort bruteforcen - am besten mit einer Passwortliste in der du alle in Frage kommenden Passwörter in allen Variationen notierst. Weist du das PW nicht mal mehr ansatzweise hat nun Lehrgeld bezahlt.



    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO 860 Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 18 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 18 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de