Protecting KeePass in Linux [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












I was thinking of the good way to secure my KeePass database on my personal PC.



I use Windows as my host, so my idea is to install some secure Linux distro and run KeePass from there. In addition to password, I would also use a key file, to which only root would have access. My reasoning is that if someone got access to my Linux VM, it's less likely they would compromise KeePass because key is only accessible by root.



Now that means I would have to run KeePass with root privileges, in order to use the key file (not sure if that is the good idea).



Does my setup makes sense? I feel like if I don't assign different access rights to key file, then it's completely loses it's purpose (as in, anyone who can access KeePass DB file, can access key file as well).










share|improve this question













closed as too broad by G-Man, RalfFriedl, Isaac, jimmij, Archemar Sep 14 at 6:47


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.














  • how about f the someone read the database directly from disk/image? The database might still be readable from RAM using a live-media after a hard reset as well. What is the exact threat model you trying to secure your system against?
    – sebasth
    Sep 11 at 7:11










  • @sebasth I am not trying to find 'perfect' solution. Simply now I am storing DB and key in the file filesystem, which defeats the whole purpose of key. So I want somehow to store/access the key in a more secure way.
    – user1880405
    Sep 11 at 7:19














up vote
0
down vote

favorite












I was thinking of the good way to secure my KeePass database on my personal PC.



I use Windows as my host, so my idea is to install some secure Linux distro and run KeePass from there. In addition to password, I would also use a key file, to which only root would have access. My reasoning is that if someone got access to my Linux VM, it's less likely they would compromise KeePass because key is only accessible by root.



Now that means I would have to run KeePass with root privileges, in order to use the key file (not sure if that is the good idea).



Does my setup makes sense? I feel like if I don't assign different access rights to key file, then it's completely loses it's purpose (as in, anyone who can access KeePass DB file, can access key file as well).










share|improve this question













closed as too broad by G-Man, RalfFriedl, Isaac, jimmij, Archemar Sep 14 at 6:47


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.














  • how about f the someone read the database directly from disk/image? The database might still be readable from RAM using a live-media after a hard reset as well. What is the exact threat model you trying to secure your system against?
    – sebasth
    Sep 11 at 7:11










  • @sebasth I am not trying to find 'perfect' solution. Simply now I am storing DB and key in the file filesystem, which defeats the whole purpose of key. So I want somehow to store/access the key in a more secure way.
    – user1880405
    Sep 11 at 7:19












up vote
0
down vote

favorite









up vote
0
down vote

favorite











I was thinking of the good way to secure my KeePass database on my personal PC.



I use Windows as my host, so my idea is to install some secure Linux distro and run KeePass from there. In addition to password, I would also use a key file, to which only root would have access. My reasoning is that if someone got access to my Linux VM, it's less likely they would compromise KeePass because key is only accessible by root.



Now that means I would have to run KeePass with root privileges, in order to use the key file (not sure if that is the good idea).



Does my setup makes sense? I feel like if I don't assign different access rights to key file, then it's completely loses it's purpose (as in, anyone who can access KeePass DB file, can access key file as well).










share|improve this question













I was thinking of the good way to secure my KeePass database on my personal PC.



I use Windows as my host, so my idea is to install some secure Linux distro and run KeePass from there. In addition to password, I would also use a key file, to which only root would have access. My reasoning is that if someone got access to my Linux VM, it's less likely they would compromise KeePass because key is only accessible by root.



Now that means I would have to run KeePass with root privileges, in order to use the key file (not sure if that is the good idea).



Does my setup makes sense? I feel like if I don't assign different access rights to key file, then it's completely loses it's purpose (as in, anyone who can access KeePass DB file, can access key file as well).







permissions






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Sep 11 at 6:56









user1880405

19329




19329




closed as too broad by G-Man, RalfFriedl, Isaac, jimmij, Archemar Sep 14 at 6:47


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.






closed as too broad by G-Man, RalfFriedl, Isaac, jimmij, Archemar Sep 14 at 6:47


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.













  • how about f the someone read the database directly from disk/image? The database might still be readable from RAM using a live-media after a hard reset as well. What is the exact threat model you trying to secure your system against?
    – sebasth
    Sep 11 at 7:11










  • @sebasth I am not trying to find 'perfect' solution. Simply now I am storing DB and key in the file filesystem, which defeats the whole purpose of key. So I want somehow to store/access the key in a more secure way.
    – user1880405
    Sep 11 at 7:19
















  • how about f the someone read the database directly from disk/image? The database might still be readable from RAM using a live-media after a hard reset as well. What is the exact threat model you trying to secure your system against?
    – sebasth
    Sep 11 at 7:11










  • @sebasth I am not trying to find 'perfect' solution. Simply now I am storing DB and key in the file filesystem, which defeats the whole purpose of key. So I want somehow to store/access the key in a more secure way.
    – user1880405
    Sep 11 at 7:19















how about f the someone read the database directly from disk/image? The database might still be readable from RAM using a live-media after a hard reset as well. What is the exact threat model you trying to secure your system against?
– sebasth
Sep 11 at 7:11




how about f the someone read the database directly from disk/image? The database might still be readable from RAM using a live-media after a hard reset as well. What is the exact threat model you trying to secure your system against?
– sebasth
Sep 11 at 7:11












@sebasth I am not trying to find 'perfect' solution. Simply now I am storing DB and key in the file filesystem, which defeats the whole purpose of key. So I want somehow to store/access the key in a more secure way.
– user1880405
Sep 11 at 7:19




@sebasth I am not trying to find 'perfect' solution. Simply now I am storing DB and key in the file filesystem, which defeats the whole purpose of key. So I want somehow to store/access the key in a more secure way.
– user1880405
Sep 11 at 7:19










5 Answers
5






active

oldest

votes

















up vote
1
down vote













Your solution seems overly complicated. Just use LUKS with a strong passphrase to do a whole disk encryption of your Linux VM, and you'll be fine.



You don't even need to run Linux for it -- make an encrypted volume (e.g. via Veracrypt) on your PC and store the KeePass database file in it.






share|improve this answer




















  • I am using Linux VM anyways, and my Windows host and Linux VM already use disk encryption, I am not worried that someone will steal my SSD and extract data. I am more worried about potential malware. If malware had user privileges, it could not access key protected by root.
    – user1880405
    Sep 11 at 7:36










  • How would then you - as an user, not root - access this same key?
    – dr01
    Sep 11 at 8:31










  • run keepass with sudo for instance (I don't know if that's safe, but at least I could access key, while user level malware could not).
    – user1880405
    Sep 11 at 9:15











  • If your machine is infected, as soon as you get privileged access via sudo, the malware gets it too. You should focus in maintaining your machine malware-free. Trying any damage mitigation assuming the machine is infected is quite a pointless exercise.
    – dr01
    Sep 11 at 9:46










  • Ok, I did not know that. I obviously try not to get infected, but I thought having a plan when you are in fact infected can be useful as well.
    – user1880405
    Sep 11 at 10:10

















up vote
0
down vote













To be honest, I'm not sure if it will provide You with any additional layer of security.



If You would like to do so, You would need to encrypt the Linux partition and I would recommend to use KP with regular user privileges. As You seem to be very concerned about security, I would recommend also to totally abandon Windows and, maybe, use only Linux installed on LiveCD (pen-drive).



One of the Linux distribution designed with security in mind is Qubes OS (https://www.qubes-os.org/), where every application is sandboxed in a separate virtual machine. So You can separate one program (eq. Internet browser with bank application) from other (Your password store). As far as I know, you can also totally block access to the Internet for some applications.



And, If You need it really badly, You can also virtualize Windows, in order to use some proprietary software.



Last but not least, It is recommended by Snowden himself ;)






share|improve this answer



























    up vote
    0
    down vote













    KeePass documentation says the database file is encrypted. Ideally, the attacker can not find the contents of the encrypted database without the encryption key (derived from master password).



    A strong master password will be more useful as security measure than adding additional layers of access control.






    share|improve this answer




















    • The way I see it: my main concern is some kind of malware with keylogger. I know likelihood is low but still. It would log my keystrokes and steal passphrase as well as steal DB file and key. On the other hand, if my DB + key is in Linux, it's a) already harder to steal cause it's in Linux VM, and b) only root can access key, so malware would have to get root privileges on Linux system. To me this seems like a more secure way to protect my KeePass.
      – user1880405
      Sep 11 at 7:41










    • You could also expect if the malware can log your keyboard it can also read the Linux VM disk image file and retrieve the file completely bypassing the VM. Disk encryption would prevent it, but you could as well use VeraCrypt etc. on Windows to encrypt a disk image where you store your database file, again rendering the VM irrelevant.
      – sebasth
      Sep 11 at 7:46

















    up vote
    0
    down vote













    No, your setup doesn't make any sense at all. Keepass doesn't become more secure by putting it into a VM, no matter the OS it is running. Even on Linux, root or "normal" user also doesn't make any difference at all.



    The one thing you got right is that there isn't too much added value by storing the keyfile next to (i.e. with the same permissions) the database.



    I keep my kdbx file in the cloud, b/c I am accessing it from many different devices. However, I keep the keyfile out of the Internet AND change it regularly. On my devices I keep the keyfile in an encrypted volume/file and the database itself is password protected.
    To open the file I need username/password for my cloud account, a password to uncrypt the FS holding the keyfile and another password for the DB. However, while working with the database, Keepass keeps a local copy of the database, which means database and keyfile are accessible using the same credentials on the same machine. I never checked how that local copy is stored, I only know it exists.



    IMO it doesn't get a lot more secure than that. I suppose if one uses the kdbx locally only, then you could put the kdbx in another encrypted volume/file. However, the kdbx is already encrypted and its a long shot assumiung another wrapper of encryption adds more security. There have been algorithms known to become less secure when applying more often ...






    share|improve this answer




















    • Thanks, I think your setup is really good. Also my use case does not require sync and cloud, so I just want to store everything locally. Wonder how can I store DB and key file locally white separated. Correct me if I am wrong, but If I encrypt the key, then it gets decrypted upon access anyways, so theoretically malware could access it when it's decrypted.
      – user1880405
      Sep 11 at 9:14










    • @user1880405 first you'd create two seperate encrypted volumes, one holding the key and one the kdbx, but, as I said, mathematically it's probably not worth it to put the kdbx in a seperated encrypted volume. There will always be a window where malware can access your data. Relatively often right at the point when you use it. Accessing your data means your data is accessible, otherwise you couldn't access it. However, an open database doesn't mean all its content is suddently readable by everything and everyone.
      – Bananguin
      Sep 11 at 9:20

















    up vote
    0
    down vote













    Do not use the root account for this.



    If you're concerned of malware catching your keyfile, you can create a keepass user.



    # as root

    # add user and enter credentials
    adduser keepass

    # move the files to keepass' home
    mv database.kdbx keyfile /home/keepass/

    # make keepass the owner and change permissions
    chown keepass: /home/keepass/database.kdbx,keyfile
    chmod 600 /home/keepass/database.kdbx
    chmod 400 /home/keepass/keyfile


    Then you can run keepass with the keepass user, e.g.:



    ssh -X keepass@localhost keepassx


    Read the answers to this question for more (and maybe better) methods running a GUI application as another user.




    Note that this will not protect you from someone with physical access to your computer or hard drive stealing your keyfile.





    Some additional hints



    They keyfile is a good option when you share the database via insecure channels (e.g. the internet) and store it on insecure devices (e.g. USB Sticks).



    You can also separate the database from the keyfile to make it more difficult for malware to grab both files. See this answer to a similar question which indicates to store the keyfile on USB. I doubt that an unencrypted device is secure, but when you store the keyfile in an encrypted container on an USB device (or on your computer), you should be fine.






    share|improve this answer






















    • Thanks, this is nice approach. However, in this case both DB and keyfile are stored in same location with same read permissions. From what I understand, the purpose of the key file is similar to 2-factor authentication - if attacker gets hold of DB, he will still need a key file. In this case, the attacker who can get hold of DB, also can simply get a key file. So I'd like them to be separated somehow (either by location or access level).
      – user1880405
      Sep 11 at 12:54










    • fair enough, but then I don't really see the point of the key file at all. It does not add any extra layer of security in my view. The way I see it, key file should be located somewhere else than DB or protected in some different way than DB itself.
      – user1880405
      Sep 11 at 13:09










    • Ah this makes sense. Then indeed I am trying to achieve something what was not intended. So theoretically, if i keep DB locally, i don't really need keyfile, as it's not increasing security that much.
      – user1880405
      Sep 11 at 13:15










    • I added the information from my comments to the answer to avoid lengthy conversation in the comments.
      – RoVo
      Sep 11 at 13:47

















    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    1
    down vote













    Your solution seems overly complicated. Just use LUKS with a strong passphrase to do a whole disk encryption of your Linux VM, and you'll be fine.



    You don't even need to run Linux for it -- make an encrypted volume (e.g. via Veracrypt) on your PC and store the KeePass database file in it.






    share|improve this answer




















    • I am using Linux VM anyways, and my Windows host and Linux VM already use disk encryption, I am not worried that someone will steal my SSD and extract data. I am more worried about potential malware. If malware had user privileges, it could not access key protected by root.
      – user1880405
      Sep 11 at 7:36










    • How would then you - as an user, not root - access this same key?
      – dr01
      Sep 11 at 8:31










    • run keepass with sudo for instance (I don't know if that's safe, but at least I could access key, while user level malware could not).
      – user1880405
      Sep 11 at 9:15











    • If your machine is infected, as soon as you get privileged access via sudo, the malware gets it too. You should focus in maintaining your machine malware-free. Trying any damage mitigation assuming the machine is infected is quite a pointless exercise.
      – dr01
      Sep 11 at 9:46










    • Ok, I did not know that. I obviously try not to get infected, but I thought having a plan when you are in fact infected can be useful as well.
      – user1880405
      Sep 11 at 10:10














    up vote
    1
    down vote













    Your solution seems overly complicated. Just use LUKS with a strong passphrase to do a whole disk encryption of your Linux VM, and you'll be fine.



    You don't even need to run Linux for it -- make an encrypted volume (e.g. via Veracrypt) on your PC and store the KeePass database file in it.






    share|improve this answer




















    • I am using Linux VM anyways, and my Windows host and Linux VM already use disk encryption, I am not worried that someone will steal my SSD and extract data. I am more worried about potential malware. If malware had user privileges, it could not access key protected by root.
      – user1880405
      Sep 11 at 7:36










    • How would then you - as an user, not root - access this same key?
      – dr01
      Sep 11 at 8:31










    • run keepass with sudo for instance (I don't know if that's safe, but at least I could access key, while user level malware could not).
      – user1880405
      Sep 11 at 9:15











    • If your machine is infected, as soon as you get privileged access via sudo, the malware gets it too. You should focus in maintaining your machine malware-free. Trying any damage mitigation assuming the machine is infected is quite a pointless exercise.
      – dr01
      Sep 11 at 9:46










    • Ok, I did not know that. I obviously try not to get infected, but I thought having a plan when you are in fact infected can be useful as well.
      – user1880405
      Sep 11 at 10:10












    up vote
    1
    down vote










    up vote
    1
    down vote









    Your solution seems overly complicated. Just use LUKS with a strong passphrase to do a whole disk encryption of your Linux VM, and you'll be fine.



    You don't even need to run Linux for it -- make an encrypted volume (e.g. via Veracrypt) on your PC and store the KeePass database file in it.






    share|improve this answer












    Your solution seems overly complicated. Just use LUKS with a strong passphrase to do a whole disk encryption of your Linux VM, and you'll be fine.



    You don't even need to run Linux for it -- make an encrypted volume (e.g. via Veracrypt) on your PC and store the KeePass database file in it.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Sep 11 at 7:01









    dr01

    15.9k114869




    15.9k114869











    • I am using Linux VM anyways, and my Windows host and Linux VM already use disk encryption, I am not worried that someone will steal my SSD and extract data. I am more worried about potential malware. If malware had user privileges, it could not access key protected by root.
      – user1880405
      Sep 11 at 7:36










    • How would then you - as an user, not root - access this same key?
      – dr01
      Sep 11 at 8:31










    • run keepass with sudo for instance (I don't know if that's safe, but at least I could access key, while user level malware could not).
      – user1880405
      Sep 11 at 9:15











    • If your machine is infected, as soon as you get privileged access via sudo, the malware gets it too. You should focus in maintaining your machine malware-free. Trying any damage mitigation assuming the machine is infected is quite a pointless exercise.
      – dr01
      Sep 11 at 9:46










    • Ok, I did not know that. I obviously try not to get infected, but I thought having a plan when you are in fact infected can be useful as well.
      – user1880405
      Sep 11 at 10:10
















    • I am using Linux VM anyways, and my Windows host and Linux VM already use disk encryption, I am not worried that someone will steal my SSD and extract data. I am more worried about potential malware. If malware had user privileges, it could not access key protected by root.
      – user1880405
      Sep 11 at 7:36










    • How would then you - as an user, not root - access this same key?
      – dr01
      Sep 11 at 8:31










    • run keepass with sudo for instance (I don't know if that's safe, but at least I could access key, while user level malware could not).
      – user1880405
      Sep 11 at 9:15











    • If your machine is infected, as soon as you get privileged access via sudo, the malware gets it too. You should focus in maintaining your machine malware-free. Trying any damage mitigation assuming the machine is infected is quite a pointless exercise.
      – dr01
      Sep 11 at 9:46










    • Ok, I did not know that. I obviously try not to get infected, but I thought having a plan when you are in fact infected can be useful as well.
      – user1880405
      Sep 11 at 10:10















    I am using Linux VM anyways, and my Windows host and Linux VM already use disk encryption, I am not worried that someone will steal my SSD and extract data. I am more worried about potential malware. If malware had user privileges, it could not access key protected by root.
    – user1880405
    Sep 11 at 7:36




    I am using Linux VM anyways, and my Windows host and Linux VM already use disk encryption, I am not worried that someone will steal my SSD and extract data. I am more worried about potential malware. If malware had user privileges, it could not access key protected by root.
    – user1880405
    Sep 11 at 7:36












    How would then you - as an user, not root - access this same key?
    – dr01
    Sep 11 at 8:31




    How would then you - as an user, not root - access this same key?
    – dr01
    Sep 11 at 8:31












    run keepass with sudo for instance (I don't know if that's safe, but at least I could access key, while user level malware could not).
    – user1880405
    Sep 11 at 9:15





    run keepass with sudo for instance (I don't know if that's safe, but at least I could access key, while user level malware could not).
    – user1880405
    Sep 11 at 9:15













    If your machine is infected, as soon as you get privileged access via sudo, the malware gets it too. You should focus in maintaining your machine malware-free. Trying any damage mitigation assuming the machine is infected is quite a pointless exercise.
    – dr01
    Sep 11 at 9:46




    If your machine is infected, as soon as you get privileged access via sudo, the malware gets it too. You should focus in maintaining your machine malware-free. Trying any damage mitigation assuming the machine is infected is quite a pointless exercise.
    – dr01
    Sep 11 at 9:46












    Ok, I did not know that. I obviously try not to get infected, but I thought having a plan when you are in fact infected can be useful as well.
    – user1880405
    Sep 11 at 10:10




    Ok, I did not know that. I obviously try not to get infected, but I thought having a plan when you are in fact infected can be useful as well.
    – user1880405
    Sep 11 at 10:10












    up vote
    0
    down vote













    To be honest, I'm not sure if it will provide You with any additional layer of security.



    If You would like to do so, You would need to encrypt the Linux partition and I would recommend to use KP with regular user privileges. As You seem to be very concerned about security, I would recommend also to totally abandon Windows and, maybe, use only Linux installed on LiveCD (pen-drive).



    One of the Linux distribution designed with security in mind is Qubes OS (https://www.qubes-os.org/), where every application is sandboxed in a separate virtual machine. So You can separate one program (eq. Internet browser with bank application) from other (Your password store). As far as I know, you can also totally block access to the Internet for some applications.



    And, If You need it really badly, You can also virtualize Windows, in order to use some proprietary software.



    Last but not least, It is recommended by Snowden himself ;)






    share|improve this answer
























      up vote
      0
      down vote













      To be honest, I'm not sure if it will provide You with any additional layer of security.



      If You would like to do so, You would need to encrypt the Linux partition and I would recommend to use KP with regular user privileges. As You seem to be very concerned about security, I would recommend also to totally abandon Windows and, maybe, use only Linux installed on LiveCD (pen-drive).



      One of the Linux distribution designed with security in mind is Qubes OS (https://www.qubes-os.org/), where every application is sandboxed in a separate virtual machine. So You can separate one program (eq. Internet browser with bank application) from other (Your password store). As far as I know, you can also totally block access to the Internet for some applications.



      And, If You need it really badly, You can also virtualize Windows, in order to use some proprietary software.



      Last but not least, It is recommended by Snowden himself ;)






      share|improve this answer






















        up vote
        0
        down vote










        up vote
        0
        down vote









        To be honest, I'm not sure if it will provide You with any additional layer of security.



        If You would like to do so, You would need to encrypt the Linux partition and I would recommend to use KP with regular user privileges. As You seem to be very concerned about security, I would recommend also to totally abandon Windows and, maybe, use only Linux installed on LiveCD (pen-drive).



        One of the Linux distribution designed with security in mind is Qubes OS (https://www.qubes-os.org/), where every application is sandboxed in a separate virtual machine. So You can separate one program (eq. Internet browser with bank application) from other (Your password store). As far as I know, you can also totally block access to the Internet for some applications.



        And, If You need it really badly, You can also virtualize Windows, in order to use some proprietary software.



        Last but not least, It is recommended by Snowden himself ;)






        share|improve this answer












        To be honest, I'm not sure if it will provide You with any additional layer of security.



        If You would like to do so, You would need to encrypt the Linux partition and I would recommend to use KP with regular user privileges. As You seem to be very concerned about security, I would recommend also to totally abandon Windows and, maybe, use only Linux installed on LiveCD (pen-drive).



        One of the Linux distribution designed with security in mind is Qubes OS (https://www.qubes-os.org/), where every application is sandboxed in a separate virtual machine. So You can separate one program (eq. Internet browser with bank application) from other (Your password store). As far as I know, you can also totally block access to the Internet for some applications.



        And, If You need it really badly, You can also virtualize Windows, in order to use some proprietary software.



        Last but not least, It is recommended by Snowden himself ;)







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Sep 11 at 7:21









        Piotr Sawicki

        516




        516




















            up vote
            0
            down vote













            KeePass documentation says the database file is encrypted. Ideally, the attacker can not find the contents of the encrypted database without the encryption key (derived from master password).



            A strong master password will be more useful as security measure than adding additional layers of access control.






            share|improve this answer




















            • The way I see it: my main concern is some kind of malware with keylogger. I know likelihood is low but still. It would log my keystrokes and steal passphrase as well as steal DB file and key. On the other hand, if my DB + key is in Linux, it's a) already harder to steal cause it's in Linux VM, and b) only root can access key, so malware would have to get root privileges on Linux system. To me this seems like a more secure way to protect my KeePass.
              – user1880405
              Sep 11 at 7:41










            • You could also expect if the malware can log your keyboard it can also read the Linux VM disk image file and retrieve the file completely bypassing the VM. Disk encryption would prevent it, but you could as well use VeraCrypt etc. on Windows to encrypt a disk image where you store your database file, again rendering the VM irrelevant.
              – sebasth
              Sep 11 at 7:46














            up vote
            0
            down vote













            KeePass documentation says the database file is encrypted. Ideally, the attacker can not find the contents of the encrypted database without the encryption key (derived from master password).



            A strong master password will be more useful as security measure than adding additional layers of access control.






            share|improve this answer




















            • The way I see it: my main concern is some kind of malware with keylogger. I know likelihood is low but still. It would log my keystrokes and steal passphrase as well as steal DB file and key. On the other hand, if my DB + key is in Linux, it's a) already harder to steal cause it's in Linux VM, and b) only root can access key, so malware would have to get root privileges on Linux system. To me this seems like a more secure way to protect my KeePass.
              – user1880405
              Sep 11 at 7:41










            • You could also expect if the malware can log your keyboard it can also read the Linux VM disk image file and retrieve the file completely bypassing the VM. Disk encryption would prevent it, but you could as well use VeraCrypt etc. on Windows to encrypt a disk image where you store your database file, again rendering the VM irrelevant.
              – sebasth
              Sep 11 at 7:46












            up vote
            0
            down vote










            up vote
            0
            down vote









            KeePass documentation says the database file is encrypted. Ideally, the attacker can not find the contents of the encrypted database without the encryption key (derived from master password).



            A strong master password will be more useful as security measure than adding additional layers of access control.






            share|improve this answer












            KeePass documentation says the database file is encrypted. Ideally, the attacker can not find the contents of the encrypted database without the encryption key (derived from master password).



            A strong master password will be more useful as security measure than adding additional layers of access control.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Sep 11 at 7:28









            sebasth

            6,43321644




            6,43321644











            • The way I see it: my main concern is some kind of malware with keylogger. I know likelihood is low but still. It would log my keystrokes and steal passphrase as well as steal DB file and key. On the other hand, if my DB + key is in Linux, it's a) already harder to steal cause it's in Linux VM, and b) only root can access key, so malware would have to get root privileges on Linux system. To me this seems like a more secure way to protect my KeePass.
              – user1880405
              Sep 11 at 7:41










            • You could also expect if the malware can log your keyboard it can also read the Linux VM disk image file and retrieve the file completely bypassing the VM. Disk encryption would prevent it, but you could as well use VeraCrypt etc. on Windows to encrypt a disk image where you store your database file, again rendering the VM irrelevant.
              – sebasth
              Sep 11 at 7:46
















            • The way I see it: my main concern is some kind of malware with keylogger. I know likelihood is low but still. It would log my keystrokes and steal passphrase as well as steal DB file and key. On the other hand, if my DB + key is in Linux, it's a) already harder to steal cause it's in Linux VM, and b) only root can access key, so malware would have to get root privileges on Linux system. To me this seems like a more secure way to protect my KeePass.
              – user1880405
              Sep 11 at 7:41










            • You could also expect if the malware can log your keyboard it can also read the Linux VM disk image file and retrieve the file completely bypassing the VM. Disk encryption would prevent it, but you could as well use VeraCrypt etc. on Windows to encrypt a disk image where you store your database file, again rendering the VM irrelevant.
              – sebasth
              Sep 11 at 7:46















            The way I see it: my main concern is some kind of malware with keylogger. I know likelihood is low but still. It would log my keystrokes and steal passphrase as well as steal DB file and key. On the other hand, if my DB + key is in Linux, it's a) already harder to steal cause it's in Linux VM, and b) only root can access key, so malware would have to get root privileges on Linux system. To me this seems like a more secure way to protect my KeePass.
            – user1880405
            Sep 11 at 7:41




            The way I see it: my main concern is some kind of malware with keylogger. I know likelihood is low but still. It would log my keystrokes and steal passphrase as well as steal DB file and key. On the other hand, if my DB + key is in Linux, it's a) already harder to steal cause it's in Linux VM, and b) only root can access key, so malware would have to get root privileges on Linux system. To me this seems like a more secure way to protect my KeePass.
            – user1880405
            Sep 11 at 7:41












            You could also expect if the malware can log your keyboard it can also read the Linux VM disk image file and retrieve the file completely bypassing the VM. Disk encryption would prevent it, but you could as well use VeraCrypt etc. on Windows to encrypt a disk image where you store your database file, again rendering the VM irrelevant.
            – sebasth
            Sep 11 at 7:46




            You could also expect if the malware can log your keyboard it can also read the Linux VM disk image file and retrieve the file completely bypassing the VM. Disk encryption would prevent it, but you could as well use VeraCrypt etc. on Windows to encrypt a disk image where you store your database file, again rendering the VM irrelevant.
            – sebasth
            Sep 11 at 7:46










            up vote
            0
            down vote













            No, your setup doesn't make any sense at all. Keepass doesn't become more secure by putting it into a VM, no matter the OS it is running. Even on Linux, root or "normal" user also doesn't make any difference at all.



            The one thing you got right is that there isn't too much added value by storing the keyfile next to (i.e. with the same permissions) the database.



            I keep my kdbx file in the cloud, b/c I am accessing it from many different devices. However, I keep the keyfile out of the Internet AND change it regularly. On my devices I keep the keyfile in an encrypted volume/file and the database itself is password protected.
            To open the file I need username/password for my cloud account, a password to uncrypt the FS holding the keyfile and another password for the DB. However, while working with the database, Keepass keeps a local copy of the database, which means database and keyfile are accessible using the same credentials on the same machine. I never checked how that local copy is stored, I only know it exists.



            IMO it doesn't get a lot more secure than that. I suppose if one uses the kdbx locally only, then you could put the kdbx in another encrypted volume/file. However, the kdbx is already encrypted and its a long shot assumiung another wrapper of encryption adds more security. There have been algorithms known to become less secure when applying more often ...






            share|improve this answer




















            • Thanks, I think your setup is really good. Also my use case does not require sync and cloud, so I just want to store everything locally. Wonder how can I store DB and key file locally white separated. Correct me if I am wrong, but If I encrypt the key, then it gets decrypted upon access anyways, so theoretically malware could access it when it's decrypted.
              – user1880405
              Sep 11 at 9:14










            • @user1880405 first you'd create two seperate encrypted volumes, one holding the key and one the kdbx, but, as I said, mathematically it's probably not worth it to put the kdbx in a seperated encrypted volume. There will always be a window where malware can access your data. Relatively often right at the point when you use it. Accessing your data means your data is accessible, otherwise you couldn't access it. However, an open database doesn't mean all its content is suddently readable by everything and everyone.
              – Bananguin
              Sep 11 at 9:20














            up vote
            0
            down vote













            No, your setup doesn't make any sense at all. Keepass doesn't become more secure by putting it into a VM, no matter the OS it is running. Even on Linux, root or "normal" user also doesn't make any difference at all.



            The one thing you got right is that there isn't too much added value by storing the keyfile next to (i.e. with the same permissions) the database.



            I keep my kdbx file in the cloud, b/c I am accessing it from many different devices. However, I keep the keyfile out of the Internet AND change it regularly. On my devices I keep the keyfile in an encrypted volume/file and the database itself is password protected.
            To open the file I need username/password for my cloud account, a password to uncrypt the FS holding the keyfile and another password for the DB. However, while working with the database, Keepass keeps a local copy of the database, which means database and keyfile are accessible using the same credentials on the same machine. I never checked how that local copy is stored, I only know it exists.



            IMO it doesn't get a lot more secure than that. I suppose if one uses the kdbx locally only, then you could put the kdbx in another encrypted volume/file. However, the kdbx is already encrypted and its a long shot assumiung another wrapper of encryption adds more security. There have been algorithms known to become less secure when applying more often ...






            share|improve this answer




















            • Thanks, I think your setup is really good. Also my use case does not require sync and cloud, so I just want to store everything locally. Wonder how can I store DB and key file locally white separated. Correct me if I am wrong, but If I encrypt the key, then it gets decrypted upon access anyways, so theoretically malware could access it when it's decrypted.
              – user1880405
              Sep 11 at 9:14










            • @user1880405 first you'd create two seperate encrypted volumes, one holding the key and one the kdbx, but, as I said, mathematically it's probably not worth it to put the kdbx in a seperated encrypted volume. There will always be a window where malware can access your data. Relatively often right at the point when you use it. Accessing your data means your data is accessible, otherwise you couldn't access it. However, an open database doesn't mean all its content is suddently readable by everything and everyone.
              – Bananguin
              Sep 11 at 9:20












            up vote
            0
            down vote










            up vote
            0
            down vote









            No, your setup doesn't make any sense at all. Keepass doesn't become more secure by putting it into a VM, no matter the OS it is running. Even on Linux, root or "normal" user also doesn't make any difference at all.



            The one thing you got right is that there isn't too much added value by storing the keyfile next to (i.e. with the same permissions) the database.



            I keep my kdbx file in the cloud, b/c I am accessing it from many different devices. However, I keep the keyfile out of the Internet AND change it regularly. On my devices I keep the keyfile in an encrypted volume/file and the database itself is password protected.
            To open the file I need username/password for my cloud account, a password to uncrypt the FS holding the keyfile and another password for the DB. However, while working with the database, Keepass keeps a local copy of the database, which means database and keyfile are accessible using the same credentials on the same machine. I never checked how that local copy is stored, I only know it exists.



            IMO it doesn't get a lot more secure than that. I suppose if one uses the kdbx locally only, then you could put the kdbx in another encrypted volume/file. However, the kdbx is already encrypted and its a long shot assumiung another wrapper of encryption adds more security. There have been algorithms known to become less secure when applying more often ...






            share|improve this answer












            No, your setup doesn't make any sense at all. Keepass doesn't become more secure by putting it into a VM, no matter the OS it is running. Even on Linux, root or "normal" user also doesn't make any difference at all.



            The one thing you got right is that there isn't too much added value by storing the keyfile next to (i.e. with the same permissions) the database.



            I keep my kdbx file in the cloud, b/c I am accessing it from many different devices. However, I keep the keyfile out of the Internet AND change it regularly. On my devices I keep the keyfile in an encrypted volume/file and the database itself is password protected.
            To open the file I need username/password for my cloud account, a password to uncrypt the FS holding the keyfile and another password for the DB. However, while working with the database, Keepass keeps a local copy of the database, which means database and keyfile are accessible using the same credentials on the same machine. I never checked how that local copy is stored, I only know it exists.



            IMO it doesn't get a lot more secure than that. I suppose if one uses the kdbx locally only, then you could put the kdbx in another encrypted volume/file. However, the kdbx is already encrypted and its a long shot assumiung another wrapper of encryption adds more security. There have been algorithms known to become less secure when applying more often ...







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Sep 11 at 8:29









            Bananguin

            5,1801338




            5,1801338











            • Thanks, I think your setup is really good. Also my use case does not require sync and cloud, so I just want to store everything locally. Wonder how can I store DB and key file locally white separated. Correct me if I am wrong, but If I encrypt the key, then it gets decrypted upon access anyways, so theoretically malware could access it when it's decrypted.
              – user1880405
              Sep 11 at 9:14










            • @user1880405 first you'd create two seperate encrypted volumes, one holding the key and one the kdbx, but, as I said, mathematically it's probably not worth it to put the kdbx in a seperated encrypted volume. There will always be a window where malware can access your data. Relatively often right at the point when you use it. Accessing your data means your data is accessible, otherwise you couldn't access it. However, an open database doesn't mean all its content is suddently readable by everything and everyone.
              – Bananguin
              Sep 11 at 9:20
















            • Thanks, I think your setup is really good. Also my use case does not require sync and cloud, so I just want to store everything locally. Wonder how can I store DB and key file locally white separated. Correct me if I am wrong, but If I encrypt the key, then it gets decrypted upon access anyways, so theoretically malware could access it when it's decrypted.
              – user1880405
              Sep 11 at 9:14










            • @user1880405 first you'd create two seperate encrypted volumes, one holding the key and one the kdbx, but, as I said, mathematically it's probably not worth it to put the kdbx in a seperated encrypted volume. There will always be a window where malware can access your data. Relatively often right at the point when you use it. Accessing your data means your data is accessible, otherwise you couldn't access it. However, an open database doesn't mean all its content is suddently readable by everything and everyone.
              – Bananguin
              Sep 11 at 9:20















            Thanks, I think your setup is really good. Also my use case does not require sync and cloud, so I just want to store everything locally. Wonder how can I store DB and key file locally white separated. Correct me if I am wrong, but If I encrypt the key, then it gets decrypted upon access anyways, so theoretically malware could access it when it's decrypted.
            – user1880405
            Sep 11 at 9:14




            Thanks, I think your setup is really good. Also my use case does not require sync and cloud, so I just want to store everything locally. Wonder how can I store DB and key file locally white separated. Correct me if I am wrong, but If I encrypt the key, then it gets decrypted upon access anyways, so theoretically malware could access it when it's decrypted.
            – user1880405
            Sep 11 at 9:14












            @user1880405 first you'd create two seperate encrypted volumes, one holding the key and one the kdbx, but, as I said, mathematically it's probably not worth it to put the kdbx in a seperated encrypted volume. There will always be a window where malware can access your data. Relatively often right at the point when you use it. Accessing your data means your data is accessible, otherwise you couldn't access it. However, an open database doesn't mean all its content is suddently readable by everything and everyone.
            – Bananguin
            Sep 11 at 9:20




            @user1880405 first you'd create two seperate encrypted volumes, one holding the key and one the kdbx, but, as I said, mathematically it's probably not worth it to put the kdbx in a seperated encrypted volume. There will always be a window where malware can access your data. Relatively often right at the point when you use it. Accessing your data means your data is accessible, otherwise you couldn't access it. However, an open database doesn't mean all its content is suddently readable by everything and everyone.
            – Bananguin
            Sep 11 at 9:20










            up vote
            0
            down vote













            Do not use the root account for this.



            If you're concerned of malware catching your keyfile, you can create a keepass user.



            # as root

            # add user and enter credentials
            adduser keepass

            # move the files to keepass' home
            mv database.kdbx keyfile /home/keepass/

            # make keepass the owner and change permissions
            chown keepass: /home/keepass/database.kdbx,keyfile
            chmod 600 /home/keepass/database.kdbx
            chmod 400 /home/keepass/keyfile


            Then you can run keepass with the keepass user, e.g.:



            ssh -X keepass@localhost keepassx


            Read the answers to this question for more (and maybe better) methods running a GUI application as another user.




            Note that this will not protect you from someone with physical access to your computer or hard drive stealing your keyfile.





            Some additional hints



            They keyfile is a good option when you share the database via insecure channels (e.g. the internet) and store it on insecure devices (e.g. USB Sticks).



            You can also separate the database from the keyfile to make it more difficult for malware to grab both files. See this answer to a similar question which indicates to store the keyfile on USB. I doubt that an unencrypted device is secure, but when you store the keyfile in an encrypted container on an USB device (or on your computer), you should be fine.






            share|improve this answer






















            • Thanks, this is nice approach. However, in this case both DB and keyfile are stored in same location with same read permissions. From what I understand, the purpose of the key file is similar to 2-factor authentication - if attacker gets hold of DB, he will still need a key file. In this case, the attacker who can get hold of DB, also can simply get a key file. So I'd like them to be separated somehow (either by location or access level).
              – user1880405
              Sep 11 at 12:54










            • fair enough, but then I don't really see the point of the key file at all. It does not add any extra layer of security in my view. The way I see it, key file should be located somewhere else than DB or protected in some different way than DB itself.
              – user1880405
              Sep 11 at 13:09










            • Ah this makes sense. Then indeed I am trying to achieve something what was not intended. So theoretically, if i keep DB locally, i don't really need keyfile, as it's not increasing security that much.
              – user1880405
              Sep 11 at 13:15










            • I added the information from my comments to the answer to avoid lengthy conversation in the comments.
              – RoVo
              Sep 11 at 13:47














            up vote
            0
            down vote













            Do not use the root account for this.



            If you're concerned of malware catching your keyfile, you can create a keepass user.



            # as root

            # add user and enter credentials
            adduser keepass

            # move the files to keepass' home
            mv database.kdbx keyfile /home/keepass/

            # make keepass the owner and change permissions
            chown keepass: /home/keepass/database.kdbx,keyfile
            chmod 600 /home/keepass/database.kdbx
            chmod 400 /home/keepass/keyfile


            Then you can run keepass with the keepass user, e.g.:



            ssh -X keepass@localhost keepassx


            Read the answers to this question for more (and maybe better) methods running a GUI application as another user.




            Note that this will not protect you from someone with physical access to your computer or hard drive stealing your keyfile.





            Some additional hints



            They keyfile is a good option when you share the database via insecure channels (e.g. the internet) and store it on insecure devices (e.g. USB Sticks).



            You can also separate the database from the keyfile to make it more difficult for malware to grab both files. See this answer to a similar question which indicates to store the keyfile on USB. I doubt that an unencrypted device is secure, but when you store the keyfile in an encrypted container on an USB device (or on your computer), you should be fine.






            share|improve this answer






















            • Thanks, this is nice approach. However, in this case both DB and keyfile are stored in same location with same read permissions. From what I understand, the purpose of the key file is similar to 2-factor authentication - if attacker gets hold of DB, he will still need a key file. In this case, the attacker who can get hold of DB, also can simply get a key file. So I'd like them to be separated somehow (either by location or access level).
              – user1880405
              Sep 11 at 12:54










            • fair enough, but then I don't really see the point of the key file at all. It does not add any extra layer of security in my view. The way I see it, key file should be located somewhere else than DB or protected in some different way than DB itself.
              – user1880405
              Sep 11 at 13:09










            • Ah this makes sense. Then indeed I am trying to achieve something what was not intended. So theoretically, if i keep DB locally, i don't really need keyfile, as it's not increasing security that much.
              – user1880405
              Sep 11 at 13:15










            • I added the information from my comments to the answer to avoid lengthy conversation in the comments.
              – RoVo
              Sep 11 at 13:47












            up vote
            0
            down vote










            up vote
            0
            down vote









            Do not use the root account for this.



            If you're concerned of malware catching your keyfile, you can create a keepass user.



            # as root

            # add user and enter credentials
            adduser keepass

            # move the files to keepass' home
            mv database.kdbx keyfile /home/keepass/

            # make keepass the owner and change permissions
            chown keepass: /home/keepass/database.kdbx,keyfile
            chmod 600 /home/keepass/database.kdbx
            chmod 400 /home/keepass/keyfile


            Then you can run keepass with the keepass user, e.g.:



            ssh -X keepass@localhost keepassx


            Read the answers to this question for more (and maybe better) methods running a GUI application as another user.




            Note that this will not protect you from someone with physical access to your computer or hard drive stealing your keyfile.





            Some additional hints



            They keyfile is a good option when you share the database via insecure channels (e.g. the internet) and store it on insecure devices (e.g. USB Sticks).



            You can also separate the database from the keyfile to make it more difficult for malware to grab both files. See this answer to a similar question which indicates to store the keyfile on USB. I doubt that an unencrypted device is secure, but when you store the keyfile in an encrypted container on an USB device (or on your computer), you should be fine.






            share|improve this answer














            Do not use the root account for this.



            If you're concerned of malware catching your keyfile, you can create a keepass user.



            # as root

            # add user and enter credentials
            adduser keepass

            # move the files to keepass' home
            mv database.kdbx keyfile /home/keepass/

            # make keepass the owner and change permissions
            chown keepass: /home/keepass/database.kdbx,keyfile
            chmod 600 /home/keepass/database.kdbx
            chmod 400 /home/keepass/keyfile


            Then you can run keepass with the keepass user, e.g.:



            ssh -X keepass@localhost keepassx


            Read the answers to this question for more (and maybe better) methods running a GUI application as another user.




            Note that this will not protect you from someone with physical access to your computer or hard drive stealing your keyfile.





            Some additional hints



            They keyfile is a good option when you share the database via insecure channels (e.g. the internet) and store it on insecure devices (e.g. USB Sticks).



            You can also separate the database from the keyfile to make it more difficult for malware to grab both files. See this answer to a similar question which indicates to store the keyfile on USB. I doubt that an unencrypted device is secure, but when you store the keyfile in an encrypted container on an USB device (or on your computer), you should be fine.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Sep 11 at 14:35

























            answered Sep 11 at 8:30









            RoVo

            1,800213




            1,800213











            • Thanks, this is nice approach. However, in this case both DB and keyfile are stored in same location with same read permissions. From what I understand, the purpose of the key file is similar to 2-factor authentication - if attacker gets hold of DB, he will still need a key file. In this case, the attacker who can get hold of DB, also can simply get a key file. So I'd like them to be separated somehow (either by location or access level).
              – user1880405
              Sep 11 at 12:54










            • fair enough, but then I don't really see the point of the key file at all. It does not add any extra layer of security in my view. The way I see it, key file should be located somewhere else than DB or protected in some different way than DB itself.
              – user1880405
              Sep 11 at 13:09










            • Ah this makes sense. Then indeed I am trying to achieve something what was not intended. So theoretically, if i keep DB locally, i don't really need keyfile, as it's not increasing security that much.
              – user1880405
              Sep 11 at 13:15










            • I added the information from my comments to the answer to avoid lengthy conversation in the comments.
              – RoVo
              Sep 11 at 13:47
















            • Thanks, this is nice approach. However, in this case both DB and keyfile are stored in same location with same read permissions. From what I understand, the purpose of the key file is similar to 2-factor authentication - if attacker gets hold of DB, he will still need a key file. In this case, the attacker who can get hold of DB, also can simply get a key file. So I'd like them to be separated somehow (either by location or access level).
              – user1880405
              Sep 11 at 12:54










            • fair enough, but then I don't really see the point of the key file at all. It does not add any extra layer of security in my view. The way I see it, key file should be located somewhere else than DB or protected in some different way than DB itself.
              – user1880405
              Sep 11 at 13:09










            • Ah this makes sense. Then indeed I am trying to achieve something what was not intended. So theoretically, if i keep DB locally, i don't really need keyfile, as it's not increasing security that much.
              – user1880405
              Sep 11 at 13:15










            • I added the information from my comments to the answer to avoid lengthy conversation in the comments.
              – RoVo
              Sep 11 at 13:47















            Thanks, this is nice approach. However, in this case both DB and keyfile are stored in same location with same read permissions. From what I understand, the purpose of the key file is similar to 2-factor authentication - if attacker gets hold of DB, he will still need a key file. In this case, the attacker who can get hold of DB, also can simply get a key file. So I'd like them to be separated somehow (either by location or access level).
            – user1880405
            Sep 11 at 12:54




            Thanks, this is nice approach. However, in this case both DB and keyfile are stored in same location with same read permissions. From what I understand, the purpose of the key file is similar to 2-factor authentication - if attacker gets hold of DB, he will still need a key file. In this case, the attacker who can get hold of DB, also can simply get a key file. So I'd like them to be separated somehow (either by location or access level).
            – user1880405
            Sep 11 at 12:54












            fair enough, but then I don't really see the point of the key file at all. It does not add any extra layer of security in my view. The way I see it, key file should be located somewhere else than DB or protected in some different way than DB itself.
            – user1880405
            Sep 11 at 13:09




            fair enough, but then I don't really see the point of the key file at all. It does not add any extra layer of security in my view. The way I see it, key file should be located somewhere else than DB or protected in some different way than DB itself.
            – user1880405
            Sep 11 at 13:09












            Ah this makes sense. Then indeed I am trying to achieve something what was not intended. So theoretically, if i keep DB locally, i don't really need keyfile, as it's not increasing security that much.
            – user1880405
            Sep 11 at 13:15




            Ah this makes sense. Then indeed I am trying to achieve something what was not intended. So theoretically, if i keep DB locally, i don't really need keyfile, as it's not increasing security that much.
            – user1880405
            Sep 11 at 13:15












            I added the information from my comments to the answer to avoid lengthy conversation in the comments.
            – RoVo
            Sep 11 at 13:47




            I added the information from my comments to the answer to avoid lengthy conversation in the comments.
            – RoVo
            Sep 11 at 13:47


            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay