How to securely store passwords in a configuration file on Linux?
up vote
0
down vote
favorite
I have a file in my Linux system that's called ".fetchmailrc" and it's used to configure the email address that fetchmail will get the mails from. Hence, I have to type my password and email address in plain text.
Here is how the .fetchmailrc file looks like:
set daemon 1
set logfile /home/user/.fetchmail.log
set no bouncemail
poll pop.gmail.com proto POP3 auth password no dns user "MY_EMAIL" password "MY_PASSWORD" is user keep ssl
mda "/usr/bin/procmail -d %T"
I believe there must be a better way to do this, since if a hacker get access to my server, he can easily read the file and get my credentials.
I heard that in Linux systems there is PAM (Pluggable Authentication Modules) but I don't know if that is related to what I'm trying to do.
linux credentials
add a comment |
up vote
0
down vote
favorite
I have a file in my Linux system that's called ".fetchmailrc" and it's used to configure the email address that fetchmail will get the mails from. Hence, I have to type my password and email address in plain text.
Here is how the .fetchmailrc file looks like:
set daemon 1
set logfile /home/user/.fetchmail.log
set no bouncemail
poll pop.gmail.com proto POP3 auth password no dns user "MY_EMAIL" password "MY_PASSWORD" is user keep ssl
mda "/usr/bin/procmail -d %T"
I believe there must be a better way to do this, since if a hacker get access to my server, he can easily read the file and get my credentials.
I heard that in Linux systems there is PAM (Pluggable Authentication Modules) but I don't know if that is related to what I'm trying to do.
linux credentials
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a file in my Linux system that's called ".fetchmailrc" and it's used to configure the email address that fetchmail will get the mails from. Hence, I have to type my password and email address in plain text.
Here is how the .fetchmailrc file looks like:
set daemon 1
set logfile /home/user/.fetchmail.log
set no bouncemail
poll pop.gmail.com proto POP3 auth password no dns user "MY_EMAIL" password "MY_PASSWORD" is user keep ssl
mda "/usr/bin/procmail -d %T"
I believe there must be a better way to do this, since if a hacker get access to my server, he can easily read the file and get my credentials.
I heard that in Linux systems there is PAM (Pluggable Authentication Modules) but I don't know if that is related to what I'm trying to do.
linux credentials
I have a file in my Linux system that's called ".fetchmailrc" and it's used to configure the email address that fetchmail will get the mails from. Hence, I have to type my password and email address in plain text.
Here is how the .fetchmailrc file looks like:
set daemon 1
set logfile /home/user/.fetchmail.log
set no bouncemail
poll pop.gmail.com proto POP3 auth password no dns user "MY_EMAIL" password "MY_PASSWORD" is user keep ssl
mda "/usr/bin/procmail -d %T"
I believe there must be a better way to do this, since if a hacker get access to my server, he can easily read the file and get my credentials.
I heard that in Linux systems there is PAM (Pluggable Authentication Modules) but I don't know if that is related to what I'm trying to do.
linux credentials
linux credentials
asked Dec 5 at 2:38
William Tang
114
114
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
No matter how you store your passwords, when running a program that doesn't prompt for your passwords, the program has to decrypt the stored password with information available on the server. A "hacker" gaining access to your server can use all information stored on the server. So he can also decrypt the password in the same way the program decrypts it.
If the scheme you use to encrypt and store your password is a bit more involved, it may take the "hacker" a bit longer.
So there's no way to do what you want: No matter how you store your password, you can't make it "hacker safe". The hacker just has to do whatever the program does (or maybe even just execute the program, and sniff the network traffic).
PAM modules have nothing to do with that. They are not for storing passwords, but provide ways to configure authentication methods for existing Linux services. A program wishing to use PAM has to be written for it.
add a comment |
up vote
1
down vote
Use the Kernel Key Retention Service
If you're worried about someone getting repeated root access to your system, then there's virtually nothing you can do after that. (But that's a nightmare, follow best practices & keep good backups).
However, if everything's still secure, then you could do much better than leaving a password in a plain text file (anyone finding your running or shutdown system drive can read it). Do things like:
- Encrypt your home, so the text file (in $HOME) is encrypted at least when you're not logged in.
- Encrypt your entire drive, similar to above.
- Don't keep the password in a file, only type it in yourself when needed
- If you have to store typed passwords, type them at login then put them:
- in a variable (in ram, though they could land in swap)
- in the kernel's key retention service (keyring in ram, more safely). See https://www.kernel.org/doc/Documentation/security/keys.txt and
man keyctl
,man keyrings
, perhaps some practical examples & notes from Anthony Thyssen
getting fetchmail to use the kernel keyring might be a bit of work, though.
– dirkt
Dec 5 at 12:15
It should accept a password some other way than as a command line argument (those are visible to everyone throughps
). Accepting through a pipe / stdin is very common.
– Xen2050
Dec 5 at 12:20
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1380879%2fhow-to-securely-store-passwords-in-a-configuration-file-on-linux%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
No matter how you store your passwords, when running a program that doesn't prompt for your passwords, the program has to decrypt the stored password with information available on the server. A "hacker" gaining access to your server can use all information stored on the server. So he can also decrypt the password in the same way the program decrypts it.
If the scheme you use to encrypt and store your password is a bit more involved, it may take the "hacker" a bit longer.
So there's no way to do what you want: No matter how you store your password, you can't make it "hacker safe". The hacker just has to do whatever the program does (or maybe even just execute the program, and sniff the network traffic).
PAM modules have nothing to do with that. They are not for storing passwords, but provide ways to configure authentication methods for existing Linux services. A program wishing to use PAM has to be written for it.
add a comment |
up vote
2
down vote
accepted
No matter how you store your passwords, when running a program that doesn't prompt for your passwords, the program has to decrypt the stored password with information available on the server. A "hacker" gaining access to your server can use all information stored on the server. So he can also decrypt the password in the same way the program decrypts it.
If the scheme you use to encrypt and store your password is a bit more involved, it may take the "hacker" a bit longer.
So there's no way to do what you want: No matter how you store your password, you can't make it "hacker safe". The hacker just has to do whatever the program does (or maybe even just execute the program, and sniff the network traffic).
PAM modules have nothing to do with that. They are not for storing passwords, but provide ways to configure authentication methods for existing Linux services. A program wishing to use PAM has to be written for it.
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
No matter how you store your passwords, when running a program that doesn't prompt for your passwords, the program has to decrypt the stored password with information available on the server. A "hacker" gaining access to your server can use all information stored on the server. So he can also decrypt the password in the same way the program decrypts it.
If the scheme you use to encrypt and store your password is a bit more involved, it may take the "hacker" a bit longer.
So there's no way to do what you want: No matter how you store your password, you can't make it "hacker safe". The hacker just has to do whatever the program does (or maybe even just execute the program, and sniff the network traffic).
PAM modules have nothing to do with that. They are not for storing passwords, but provide ways to configure authentication methods for existing Linux services. A program wishing to use PAM has to be written for it.
No matter how you store your passwords, when running a program that doesn't prompt for your passwords, the program has to decrypt the stored password with information available on the server. A "hacker" gaining access to your server can use all information stored on the server. So he can also decrypt the password in the same way the program decrypts it.
If the scheme you use to encrypt and store your password is a bit more involved, it may take the "hacker" a bit longer.
So there's no way to do what you want: No matter how you store your password, you can't make it "hacker safe". The hacker just has to do whatever the program does (or maybe even just execute the program, and sniff the network traffic).
PAM modules have nothing to do with that. They are not for storing passwords, but provide ways to configure authentication methods for existing Linux services. A program wishing to use PAM has to be written for it.
answered Dec 5 at 7:11
dirkt
8,98231121
8,98231121
add a comment |
add a comment |
up vote
1
down vote
Use the Kernel Key Retention Service
If you're worried about someone getting repeated root access to your system, then there's virtually nothing you can do after that. (But that's a nightmare, follow best practices & keep good backups).
However, if everything's still secure, then you could do much better than leaving a password in a plain text file (anyone finding your running or shutdown system drive can read it). Do things like:
- Encrypt your home, so the text file (in $HOME) is encrypted at least when you're not logged in.
- Encrypt your entire drive, similar to above.
- Don't keep the password in a file, only type it in yourself when needed
- If you have to store typed passwords, type them at login then put them:
- in a variable (in ram, though they could land in swap)
- in the kernel's key retention service (keyring in ram, more safely). See https://www.kernel.org/doc/Documentation/security/keys.txt and
man keyctl
,man keyrings
, perhaps some practical examples & notes from Anthony Thyssen
getting fetchmail to use the kernel keyring might be a bit of work, though.
– dirkt
Dec 5 at 12:15
It should accept a password some other way than as a command line argument (those are visible to everyone throughps
). Accepting through a pipe / stdin is very common.
– Xen2050
Dec 5 at 12:20
add a comment |
up vote
1
down vote
Use the Kernel Key Retention Service
If you're worried about someone getting repeated root access to your system, then there's virtually nothing you can do after that. (But that's a nightmare, follow best practices & keep good backups).
However, if everything's still secure, then you could do much better than leaving a password in a plain text file (anyone finding your running or shutdown system drive can read it). Do things like:
- Encrypt your home, so the text file (in $HOME) is encrypted at least when you're not logged in.
- Encrypt your entire drive, similar to above.
- Don't keep the password in a file, only type it in yourself when needed
- If you have to store typed passwords, type them at login then put them:
- in a variable (in ram, though they could land in swap)
- in the kernel's key retention service (keyring in ram, more safely). See https://www.kernel.org/doc/Documentation/security/keys.txt and
man keyctl
,man keyrings
, perhaps some practical examples & notes from Anthony Thyssen
getting fetchmail to use the kernel keyring might be a bit of work, though.
– dirkt
Dec 5 at 12:15
It should accept a password some other way than as a command line argument (those are visible to everyone throughps
). Accepting through a pipe / stdin is very common.
– Xen2050
Dec 5 at 12:20
add a comment |
up vote
1
down vote
up vote
1
down vote
Use the Kernel Key Retention Service
If you're worried about someone getting repeated root access to your system, then there's virtually nothing you can do after that. (But that's a nightmare, follow best practices & keep good backups).
However, if everything's still secure, then you could do much better than leaving a password in a plain text file (anyone finding your running or shutdown system drive can read it). Do things like:
- Encrypt your home, so the text file (in $HOME) is encrypted at least when you're not logged in.
- Encrypt your entire drive, similar to above.
- Don't keep the password in a file, only type it in yourself when needed
- If you have to store typed passwords, type them at login then put them:
- in a variable (in ram, though they could land in swap)
- in the kernel's key retention service (keyring in ram, more safely). See https://www.kernel.org/doc/Documentation/security/keys.txt and
man keyctl
,man keyrings
, perhaps some practical examples & notes from Anthony Thyssen
Use the Kernel Key Retention Service
If you're worried about someone getting repeated root access to your system, then there's virtually nothing you can do after that. (But that's a nightmare, follow best practices & keep good backups).
However, if everything's still secure, then you could do much better than leaving a password in a plain text file (anyone finding your running or shutdown system drive can read it). Do things like:
- Encrypt your home, so the text file (in $HOME) is encrypted at least when you're not logged in.
- Encrypt your entire drive, similar to above.
- Don't keep the password in a file, only type it in yourself when needed
- If you have to store typed passwords, type them at login then put them:
- in a variable (in ram, though they could land in swap)
- in the kernel's key retention service (keyring in ram, more safely). See https://www.kernel.org/doc/Documentation/security/keys.txt and
man keyctl
,man keyrings
, perhaps some practical examples & notes from Anthony Thyssen
edited Dec 5 at 11:48
answered Dec 5 at 11:43
Xen2050
9,86931536
9,86931536
getting fetchmail to use the kernel keyring might be a bit of work, though.
– dirkt
Dec 5 at 12:15
It should accept a password some other way than as a command line argument (those are visible to everyone throughps
). Accepting through a pipe / stdin is very common.
– Xen2050
Dec 5 at 12:20
add a comment |
getting fetchmail to use the kernel keyring might be a bit of work, though.
– dirkt
Dec 5 at 12:15
It should accept a password some other way than as a command line argument (those are visible to everyone throughps
). Accepting through a pipe / stdin is very common.
– Xen2050
Dec 5 at 12:20
getting fetchmail to use the kernel keyring might be a bit of work, though.
– dirkt
Dec 5 at 12:15
getting fetchmail to use the kernel keyring might be a bit of work, though.
– dirkt
Dec 5 at 12:15
It should accept a password some other way than as a command line argument (those are visible to everyone through
ps
). Accepting through a pipe / stdin is very common.– Xen2050
Dec 5 at 12:20
It should accept a password some other way than as a command line argument (those are visible to everyone through
ps
). Accepting through a pipe / stdin is very common.– Xen2050
Dec 5 at 12:20
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1380879%2fhow-to-securely-store-passwords-in-a-configuration-file-on-linux%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown