1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Inception: System-Login auf…

Langsam wird das zu einem ernsten Problem

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Langsam wird das zu einem ernsten Problem

    Autor lisgoem8 10.01.13 - 17:50

    Immer wieder lese ich es und finde das es langsam doch ein ernstes Problem wird.

    Wird es nicht Zeit das man mal die Klartexterei im Speicher lässt?

    read password. hash the password. overwrite readed plain text string. und darüber noch eine Signatur legen um den Betrug auszuschliessen (durch überschreiben des hashes).

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: Langsam wird das zu einem ernsten Problem

    Autor pythoneer 10.01.13 - 18:14

    lisgoem8 schrieb:
    --------------------------------------------------------------------------------
    > Immer wieder lese ich es und finde das es langsam doch ein ernstes Problem
    > wird.
    >
    > Wird es nicht Zeit das man mal die Klartexterei im Speicher lässt?
    >
    > read password. hash the password. overwrite readed plain text string. und
    > darüber noch eine Signatur legen um den Betrug auszuschliessen (durch
    > überschreiben des hashes).

    Wie stellst du dir das vor? Ich kann es mir gerade nicht vorstellen. Das müsste doch Hardwareseitig irgendwie gelöst werden, oder der Kernel erlaubt lesen aus einem bestimmten Bereich des RAMs nicht, der nur für solche Passwörter bereit gehalten wird – vielleicht auch durchs BS verschlüsselt, wo sich die Frage stellt, wo man diesen Schlüsseln dann wieder speichern soll ??

    Weil mit einem Hash kann man nicht allzu viel anfangen. Mit einem Hash kann ich nur Prüfen ob ein Schlüssel/Passwort gleich also richtig ist. Das hilft mir aber nichts, wenn das Passwort mein Schlüssel ist, mit dem ich entschlüssle, dafür brauche ich den Schlüssel im Klartext im RAM (irgendwann zumindest, vielleicht nur temporär)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: Langsam wird das zu einem ernsten Problem

    Autor Shadow27374 10.01.13 - 19:06

    Stichworte: Tresor und TreVisor.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: Langsam wird das zu einem ernsten Problem

    Autor pythoneer 10.01.13 - 19:15

    Shadow27374 schrieb:
    --------------------------------------------------------------------------------
    > Stichworte: Tresor und TreVisor.

    Oh cool, sagt mir erstmal nix, bin auch in Crypto nicht so bewandert. Ist das sone art Hypervisor? (der Name lässt es vermute) ... ich bin dann mal bei google :)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: Langsam wird das zu einem ernsten Problem

    Autor pythoneer 10.01.13 - 19:42

    Shadow27374 schrieb:
    --------------------------------------------------------------------------------
    > Stichworte: Tresor und TreVisor.

    Vielen dank noch mal! War echt spannend. Wen es interessiert [*]
    Sehr cool das einfach in die Register zu packen, da bin ich erst gar nicht drauf gekommen. Schade dass es so seinen Weg wohl nie in den Linux Kernel (oder OSX/Win)
    finden wird, da es ja einige Register dadurch unbrauchbar macht gerade so Sachen wie VT-x scheint diese wohl zu brauchen (bin es nur überflogen) und das wäre schon ärgerliche für normale Benutzer mit VirtualBox etc.

    [*] http://www1.cs.fau.de/filepool/projects/trevisor/trevisor.pdf

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: Langsam wird das zu einem ernsten Problem

    Autor Vanger 10.01.13 - 22:56

    Man sollte anmerken, dass konzeptbedingt eine Verschlüsselung *niemals* absolut sicher sein kann wenn physischer Zugang zur Hardware besteht. Die Bits müssen nunmal irgendwo liegen - und an diese Bits kommt man immer auch ran, sonst könnte sie das System ja nicht lesen. Das wurde im Vortrag beim 28C3 zu Tresor auch klar gesagt: Selbstverständlich kann man auch gegen die Register der CPU einen Angriff fahren und dadurch den Schlüssel extrahieren. Physikalisch spricht da rein gar nichts gegen. Es ist nur schwieriger als beim RAM. Verschlüsselung ist immer ein Wettrüsten - das sollte jedem klar sein.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Samsung Galaxy Tab S im Test: Flaches, poppig buntes Leichtgewicht
Samsung Galaxy Tab S im Test
Flaches, poppig buntes Leichtgewicht
  1. Samsung Neue Galaxy Tabs ab 200 Euro erhältlich

IMHO: Share Economy regulieren, nicht verbieten
IMHO
Share Economy regulieren, nicht verbieten
  1. NSA-Affäre Macht euch wichtig!
  2. IMHO Und wir sind selber schuld!
  3. Head Mounted Display Valve zeigt neue Version seiner VR-Brille

Oneplus One im Test: Unerreichbar gut
Oneplus One im Test
Unerreichbar gut
  1. Oneplus One Eigenes ROM mit Stock Android 4.4.4 vorgestellt
  2. Oneplus One-Update macht verkürzte Akkulaufzeit rückgängig
  3. Oneplus One könnte ab dem dritten Quartal vorbestellbar sein

  1. Nvidia: H.265-Hardwarebeschleunigung für Linux-Treiber
    Nvidia
    H.265-Hardwarebeschleunigung für Linux-Treiber

    Für die Hardwarebeschleunigung zur Videodekodierung unter Unix-Systemen gibt es die Schnittstelle VDPAU. Diese wird nun von Nvidia um H.265 alias HEVC erweitert, was in FFMpeg und MPlayer verwendet werden soll.

  2. Sel4: Fehlerloser Microkernel unter der GPL freigegeben
    Sel4
    Fehlerloser Microkernel unter der GPL freigegeben

    Der von der National ICT Australia mitentwickelte Microkernel Sel4 steht ab sofort unter der GPL. Er wurde durch mehrere Testverfahren als vollständig fehlerfrei eingestuft.

  3. Shamu: Hinweise auf neues Nexus-Smartphone verdichten sich
    Shamu
    Hinweise auf neues Nexus-Smartphone verdichten sich

    Im Internet tauchen immer mehr Gerüchte zu einem neuen Google-Smartphone mit dem Codenamen Shamu auf. Gemutmaßt wird, dass das Nexus-Gerät ein 5,9 Zoll großes Display haben wird. Außerdem soll es mit Extrafunktionen von Motorola kommen.


  1. 12:40

  2. 12:26

  3. 12:19

  4. 12:01

  5. 11:52

  6. 11:36

  7. 11:26

  8. 11:19