5 ms·

Actually not. Just use a loopback cypto FS to store the sensitive stuff. The reason they had to reboot the machine is that they just had access to the HDD whe

• tlb 15y ago
  Indeed. Well-designed money storage systems aren't vulnerable no matter who has console access.
• lsc 15y ago
  where do you keep the key to the crypto fs?
  • kbuck 15y ago
    You memorize it.
    • lsc 15y ago
      how do you transmit it to the server in such a way that it can't be intercepted by someone that compromises the bits of your virtual that boot before the key is uploaded?
      • RLG_RLG 15y ago
        By using your public key. http://www.debian-administration.org/articles/152 http://www.debian-administration.org/articles/152 You can also require a password AND a cert.
        • lsc 15y ago
          Yes, but will that help you if the attacker trojans whatever it is that is doing the decryption? I mean, I'm very clearly not a crypto expert, but I do believe that this would be quite a lot like what Bruce Schnier calls 'the evil maid' attack. Instead of having a bootloader, you have a minimal Linux install, then you get a key to that minimal linux install, and that minimal linux install uses that key to decrypt your encrypted disk. I believe that if that minimal linux install that does the decrypting is compromised before you log in, in theory, the attacker could then insert something in the code that runs after the data is decrypted to, say, send some of that data elsewhere, or, say, open a back door for them to log in and examine the decrypted data. I mean, certainly, you are making the attacker wait for you to log in (assuming that they've only compromised the admin interface and don't have full root on the dom0) and that's another step you are forcing the attacker to take, and you do at least have a chance then of detecting the compromise and /not/ sending the key, so I'm not saying that it's worthless. Of course, this is all protecting against a compromise of the admin tools that does not lead to a compromise of the dom0. If the attacker compromises the dom0 without rebooting it or otherwise disturbing the guests? they have access to your ram. They can snapshot both the ram and the disk and take apart the system at their leisure.
          • RLG_RLG 15y ago
            I advise you seek the services of a professional sys admin to secure systems.
            • marshray 15y ago
              He's right though. I don't think I've ever met a professional sysadmin who could defeat the evil maid attack. All the ones I've met would refuse to think about an attack vector if it implied they could not boot their servers.
              • nknight 15y ago
                Yep. Classically, we abdicate responsibility as soon as physical security is breached. With virtual machines the problem is mostly the same, but it moves from "true physical" to "virtual physical" -- once the host environment is breached, all bets are off. Any sysadmin that claims to be able to protect against a physical access attack or its contextual equivalent is either lying or incompetent. In neither case should that sysadmin be considered "professional".
                • RLG_RLG 15y ago
                  Use BIOS & boot loader passwords. Encrypt the file systems. This will not stop 3 letter agencies, foreign governments, or aliens.
                  • nknight 15y ago
                    It won't stop a private individual, either, not even one with a budget of approximately $0. Cold boot and similar attacks, even just yanking the memory or forcing a CMOS reset, are trivial. Please tell me you don't do this for a living.
                    • RLG_RLG 15y ago
                      We are talking about live servers. Monitoring should detect server going down, raising suspicion of a physical attack. The evil maid attack would be useful against the system admin's workstation. Securing NOCs is beyond the scope of this discussion, but it is not difficult.
  • RLG_RLG 15y ago
    Written on a scrap of paper in your wallet. only the password and no other info should be on the scrap. If you can memorize it, it is a bad password.
    • bronson 15y ago
      That's not strictly true. If you're careful and imaginative, with moderate effort you can commit a fair amount of highly random data to memory. You just can't expect to change it every month. This may be oversimplified, but it's the correct horse battery staple.
    • mckoss 15y ago
      My password was randomly generated, has 85 bits of entropy and, it took me only a couple of days to memorize.
    • eli 15y ago
      Hmm, hope you don't take many vacations
    • Avshalom 15y ago
      Eh, it depends, a random fragment of a very long poem for instance can be quite easy to memorize but at 80-90 words/300-400 characters long is pretty damn secure, doesn't even need to be written down then.
    • kristianp 15y ago
      https://www.xkcd.com/936/ https://www.xkcd.com/936/
    • DanBC 15y ago
      "muscle memory" helps here. People only need to refer to the scrap of paper for the first couple of weeks of entering a password. Then that scrap can be securely stored somewhere else. (eg: In your "in case of death" box if you want people to have access when you die.)
    • korny 15y ago
      What the? If you write it down, it's a bad password. Make it a pass phrase, make it long. And possibly store it in an encrypted password database, protected by a master pass phrase.
• marshray 15y ago
  I really doubt that "only HDD access" is a secure position in cases where your cloud provider CSR is pwned. If that's even the case here. We don't have much indication that the attacker couldn't have taken a snapshot of a running system (or that that will be how it happens next time). So, sure, use a loopback crypto filesystem. It just doesn't provide much in the way of a security guarantee (but it adds some measurable costs).