Find the answer to your Linux question:
Results 1 to 7 of 7
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Secure Storage based on login password


    having seeked for such a solution for a while, and haven't found anything, I would like to ask this here:

    Is anyone aware of any possibility of having same data encrypted/stored encrypted (and then decrypted/read decrypted from an encrypted storage) in a way that no key needs to be supplied for encryption and decyption, but instead the system will use the login password (or similar user provided secret) as a basis for deriving the encryption key?

    windows has it via the CryptProtectData API call.

    Any help would be highly appreciated.

    Thanks & Regards,

  2. #2
    There are lots of ways of encrypting files, gpg, for instance. You could have a encrypted partition. Why you would want the computer to decrypt it automatically at some point in the boot up process, (if I understand you correctly), is beyond me.

  3. #3
    Just Joined!
    Join Date
    Jan 2011
    Fairfax, Virginia, USA
    Hi kurtdriver,

    I'm not a Windows guy, but I think CryptProtectData() is a Windows "C" library call and looks like the candidate for how Windows does NTFS encryption. I have a weak grasp on practical Linux encryption and can help.

    If your concerned about implications of a disk being lost or stolen, then I'm pretty sure you want to use some flavour of Linux disk encryption. TrueCrypt has the benefit of being cross platform and it seems to perform best (for me anyway). Linux dm-crypt is very reliable and has the benefit of being indigenous to most distributions. Both solutions probably offer superior cryptographic performance to Windows counterparts. Typical usage for both solutions is to issue keys (which can be a password but don't have to be) to decrypt a filesystem at mount time. A Linux PAM plugin for dm-crypt used to decrypt and mount the filesystem when you login (Gentoo Forums :: View topic - Automatically mount dm-crypt encrypted home with pam_mount) but its performance about a decade ago wasn't very good (I'll bet there is something better now, I'm just not aware of it). In this case, the "credentials" for encryption are based from your login password which isn't quite the same as the more specific Windows credentials passed to CryptProtectData(). If your concerned about the security of your media, you probably are interested in a filesystem based solution to contain the data you are encrypting. Under most circumstances its generally a bad idea to attempt file based encryption within a unsecure plain text filesystem.

    If your concerned about implications of ease dropping over a network, then there are tons of solutions ... the easiest to implement in seconds is sshfs however its not the best for high performance use. Sshfs's "credentials" are based from a login password and the remote user needs UNIX permissions to access the filesystem being served.

    I hope this helps.

  4. $spacer_open
  5. #4
    Hi kurtdriver,

    thanks for your reply. The point behind the whole idea would be to avoid the storage of any key used for encrypting the data anywhere on the computer the application is running at. This rules out solutions where the key is stored elsewhere on the file system, or hardcoded into the application.
    I would like to rely on the OS at least attempting to provide some capabilities for encryption which is based on a secret that is never stored in a reversible form on the computer.

    This is expected to contribute to security in a way that even if file system permissions are not set up right, or someone have access to disk, and read its full contents, without the secret needed for decryption, the show should be over. And once again, the secret would be coming from a different source (e.g. user types in password upon start of the computer).

    I had a look at GPG, but what I have understood was that if you wish to use GPG for this purpose, you always have to supply a password explicitly. Then we are back to square one, because the password has to come from somewhere - and I would like to avoid asking for an application specific password, and storing it somewhere - even avoiding storing it in memory. Using an OS feature for such things would be a good way of getting rid of the complexitiy of handling this in the application.


  6. #5
    Hi BrianMicek,

    thank you for answering. Basically I am concerned about two things in this regard:
    - either an attacker can read disk contents (and indeed, full disk encryption would be a solution here)
    - an improperly configured file system access policy (or a software bug, e.g. path traversal) might allow unauthorized parties to access these files

    The latter is harder to adress, I think. Even if the whole disk is encrypted, once you are "inside" the file system, you might have many ways of accessing information you are not authorized to. For this reason I would like to look for a solution, where access is bound to the user who was entering credentials upon logon, and processes, that are running under the identity of this user.


  7. #6
    Just Joined!
    Join Date
    Jan 2011
    Fairfax, Virginia, USA
    Hi kommersz,
    I'm pretty sure Linux does disk encryption like it should be done and don't consider what I'm about to say as a bug. Based on what you mentioned, the problem you will have with virtually all Linux filesystem based encryption tools is once the secure filesystem is mounted into the Linux file tree, its contents are clear text on demand (is no longer encrypted) and anyone (or any program) the kernel deems acceptable to access your clear text data will be granted permission to retrieve and manipulate your data. SELinux hints at addressing this issue by adding more restrictions but a compromised machine is still insecure.

    More specifically, the encrypted cipher text filesystem is viewed by the kernel as a block device and a new clear text block device is created once keys are presented to the cryptography portions of the operating system. This clear text block device read()s, write()s and seek()s decrypted data and usually contains a filesystem suitable for mount command.

    Tools exist to operate on files instead of filesystems but a compromised (rooted) system could still reveal your data and file based tools are mostly a bad idea IMHO.

    Furthermore, paged operating systems will normally move portions of their data segments into swap based on pressure. Its a good idea to consider approaches for encrypting swap to hide secure paged data but this won't help if your machine has been compromised.

    Computer forensic people will go to clever lengths to keep a running machine running if possible for this reason ... they want potentially mounted encrypted data accessable rather than encrypted. Incidentally, this is also why people running encrypted laptops should consider not hibernating their laptops.

    One final note is that you mentioned security aspects of Windows and I feel compelled to mention Microsoft has been careless with the design of their cryptography in the past. I'm biased against Windows for anything demanding stability or integrity so I suppose its bad for me to elaborate further here.

    If this type of security is important to you, I'd recommend you check out the various flavors of BSD UNIX because they seem to be even more paranoid about security than Linux.
    Last edited by BrianMicek; 09-24-2011 at 01:37 AM.

  8. #7


    Windows Encrypted File System seems to be what you're looking for (if in fact Windows is an option as an o/s for the app). If the service is owned by the account that encrypts the file system, then the data will be encrypted to any other accounts and therefore inaccessible. It's very easy to set up, too. You can create the encrypted file system and Windows will generate a self-signed cert, or you could install a cert from your certificate authority for this purpose.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts