Safeguarding MySQL password when developing in Python?
I'm writing a Python script which uses a MySQL database, which is locally hosted. The program will be delivered as source code. As a result, the MySQL password will be visible to bare eyes. Is there a good way to protect this?
The idea is to prevent some naughty people from looking at the source code, gaining direct access to MySQL, and doing something ... well, naughty.
python mysql
add a comment |
I'm writing a Python script which uses a MySQL database, which is locally hosted. The program will be delivered as source code. As a result, the MySQL password will be visible to bare eyes. Is there a good way to protect this?
The idea is to prevent some naughty people from looking at the source code, gaining direct access to MySQL, and doing something ... well, naughty.
python mysql
Define it in a central place and edit it out before shipping?
– Jacob
Aug 8 '11 at 10:56
Is this going to connect to a database of yours, or the purchaser's database?
– Raz
Aug 8 '11 at 11:06
add a comment |
I'm writing a Python script which uses a MySQL database, which is locally hosted. The program will be delivered as source code. As a result, the MySQL password will be visible to bare eyes. Is there a good way to protect this?
The idea is to prevent some naughty people from looking at the source code, gaining direct access to MySQL, and doing something ... well, naughty.
python mysql
I'm writing a Python script which uses a MySQL database, which is locally hosted. The program will be delivered as source code. As a result, the MySQL password will be visible to bare eyes. Is there a good way to protect this?
The idea is to prevent some naughty people from looking at the source code, gaining direct access to MySQL, and doing something ... well, naughty.
python mysql
python mysql
edited Jun 29 '12 at 20:36
Keith Pinson
4,60454184
4,60454184
asked Aug 8 '11 at 10:52
lang2
3,45094488
3,45094488
Define it in a central place and edit it out before shipping?
– Jacob
Aug 8 '11 at 10:56
Is this going to connect to a database of yours, or the purchaser's database?
– Raz
Aug 8 '11 at 11:06
add a comment |
Define it in a central place and edit it out before shipping?
– Jacob
Aug 8 '11 at 10:56
Is this going to connect to a database of yours, or the purchaser's database?
– Raz
Aug 8 '11 at 11:06
Define it in a central place and edit it out before shipping?
– Jacob
Aug 8 '11 at 10:56
Define it in a central place and edit it out before shipping?
– Jacob
Aug 8 '11 at 10:56
Is this going to connect to a database of yours, or the purchaser's database?
– Raz
Aug 8 '11 at 11:06
Is this going to connect to a database of yours, or the purchaser's database?
– Raz
Aug 8 '11 at 11:06
add a comment |
4 Answers
4
active
oldest
votes
Short answer
You can't.
If the password is stored in the artifact that's shipped to the end-user you must consider it compromised! Even if the artifact is a compiled binary, there are always (more or less complicated) ways to get at the password.
The only way to protect your resources is by exposing only a limited API to the end-user. Either build a programmatic API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) or only expose certain functionalities in your DB via SPROCs (see below).
Some things first...
The question here should not be how to hide the password, but how to secure the database. Remember that passwords only are often a very weak protection and should not be considered the sole mechanism of protecting the DB. Are you using SSL? No? Well, then even if you manage to hide the password in the application code, it's still easy to sniff it on the network!
You have multiple options. All with varying degrees of security:
"Application Role"
Create one database-user for the application. Apply authorization for this role. A very common setup is to only allow CRUD ops.
Pros
very easy to set-up- Prevents
DROP
queries (f.ex. in SQL injections?)
Cons
- Everybody seeing the password has access to all the data in the database. Even if that data is normally hidden in the application.
- If the password is compromised, the user can run
UPDATE
andDELETE
queries without criteria (i.e.: delete/update a whole table at once).
Atomic auth&auth
Create one database user per application-/end-user. This allows you to define atomic access rights even on a per-column basis. For example: User X can only select columns far and baz from table foo. And nothing else. But user Y can SELECT
everything, but no updates, while user Z has full CRUD (select, insert, update, delete) access.
Some databases allow you to reuse the OS-level credentials. This makes authentication to the user transparent (only needs to log-in to the workstation, that identity is then forwarded to the DB). This works easiest in a full MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) but is - as far as I am aware - also possible to achieve in other DBs.
Pros
- Fairly easy to set up.
- Very atomic authorization scheme
Cons
- Can be tedious to set up all the access rights in the DB.
- Users with
UPDATE
andDELETE
rights can still accidentally (or intentionally?) delete/update without criteria. You risk losing all the data in a table.
Stored Procedures with atomic auth&auth
Write no SQL queries in your application. Run everything through SPROCs. Then create db-accounts for each user and assign privileges to the SPROCs only.
Pros
- Most effective protection mechanism.
- SPROCs can force users to pass criteria to every query (including
DELETE
andUPDATE
)
Cons
- not sure if this works with MySQL (my knowledge in that area is flaky).
- complex development cycle: Everything you want to do, must first be defined in a SPROC.
Final thoughts
You should never allow database administrative tasks to the application. Most of the time, the only operations an application needs are SELECT
, INSERT
, DELETE
and UPDATE
. If you follow this guideline, there is hardly a risk involved by users discovering the password. Except the points mentioned above.
In any case, keep backups. I assume you want to project you database against accidental deletes or updates. But accidents happen... keep that in mind ;)
add a comment |
In this case, I create a new section in my .my.cnf, like
[files]
host=127.0.0.1
port=3307
database=files
default-character-set=utf8
password=foobar
and use it on DB initialization with
d=MySQLdb.connect(
read_default_group='files',
port=0, # read from .my.cnf
db='files',
cursorclass=cursors.DictCursor,
# amongst other stuff
)
This still lets users read the file iirc.
– exhuma
Aug 8 '11 at 11:28
This is right, but it is not distributed together with the source code. But it might be that I mis-interpreted the original motivation of the asker - I thought he wanted to prevent accidential distribution of the password included in the source.
– glglgl
Aug 8 '11 at 12:00
well... themy.cnf
file has to be located on the client. In other words, it's got to be on the machine which also runs the application. Also, the application normally runs under the same credentials as the user. This implies that the user needs read access to the file. So, this will make it less obvious but a skilled attacker could still locate this easily.
– exhuma
Aug 8 '11 at 17:39
I have the same question with the asker, but your answer does answer what I want to ask. 1UP!
– weefwefwqg3
Oct 21 '17 at 23:14
add a comment |
Similar unanswered question here: https://stackoverflow.com/questions/2850710/connect-to-a-db-with-an-encrypted-password-with-django The python DBAPI (PEP 249) has no interface for connecting to the database with an encrypted/hashed password in lieu of a plaintext password.
While this feature in other languages is comforting, it does not provide any real additional security: the hash of the password is as good as the password. You still have to control access to the database resources as exhuma describes.
MySQL itself does not provide any additional options, regardless of python bindings or not. You can read their guidance in the MySQL User Manual section on Password Security. The recommended option for protecting access to the password is to store it in an option file and protect the file, as described by glglgl.
From that page:
The methods you can use to specify your password when you run client
programs are listed here, along with an assessment of the risks of
each method. In short, the safest methods are to have the client
program prompt for the password or to specify the password in a
properly protected option file.
I disagree with the option file. This file will not hide the password from a prying user. As I explained in the comment to glglgl's answer, the client application needs read access to the file, which in turn means, the user needs read access. Usually, a non-superuser cannot escalate the access rights.
– exhuma
Aug 8 '11 at 17:45
I don't disagree with you, but I also don't know any other options. Your post covers the database design requirements to limit the exposure, but doesn't address storage of the credentials. Is there a better way?
– J.J.
Aug 8 '11 at 17:57
Not that I know of. :/
– exhuma
Aug 10 '11 at 7:05
add a comment |
Either use simple passwor like root
.Else Don't use password.
How do I prevent a user from changing the DB if there is no passd word?
– lang2
Aug 8 '11 at 11:06
To particular db, create a user with no password, for other DB create a different user and password, debuntu.org/…
– Kracekumar
Aug 8 '11 at 11:08
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
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',
autoActivateHeartbeat: false,
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%2fstackoverflow.com%2fquestions%2f6981064%2fsafeguarding-mysql-password-when-developing-in-python%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Short answer
You can't.
If the password is stored in the artifact that's shipped to the end-user you must consider it compromised! Even if the artifact is a compiled binary, there are always (more or less complicated) ways to get at the password.
The only way to protect your resources is by exposing only a limited API to the end-user. Either build a programmatic API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) or only expose certain functionalities in your DB via SPROCs (see below).
Some things first...
The question here should not be how to hide the password, but how to secure the database. Remember that passwords only are often a very weak protection and should not be considered the sole mechanism of protecting the DB. Are you using SSL? No? Well, then even if you manage to hide the password in the application code, it's still easy to sniff it on the network!
You have multiple options. All with varying degrees of security:
"Application Role"
Create one database-user for the application. Apply authorization for this role. A very common setup is to only allow CRUD ops.
Pros
very easy to set-up- Prevents
DROP
queries (f.ex. in SQL injections?)
Cons
- Everybody seeing the password has access to all the data in the database. Even if that data is normally hidden in the application.
- If the password is compromised, the user can run
UPDATE
andDELETE
queries without criteria (i.e.: delete/update a whole table at once).
Atomic auth&auth
Create one database user per application-/end-user. This allows you to define atomic access rights even on a per-column basis. For example: User X can only select columns far and baz from table foo. And nothing else. But user Y can SELECT
everything, but no updates, while user Z has full CRUD (select, insert, update, delete) access.
Some databases allow you to reuse the OS-level credentials. This makes authentication to the user transparent (only needs to log-in to the workstation, that identity is then forwarded to the DB). This works easiest in a full MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) but is - as far as I am aware - also possible to achieve in other DBs.
Pros
- Fairly easy to set up.
- Very atomic authorization scheme
Cons
- Can be tedious to set up all the access rights in the DB.
- Users with
UPDATE
andDELETE
rights can still accidentally (or intentionally?) delete/update without criteria. You risk losing all the data in a table.
Stored Procedures with atomic auth&auth
Write no SQL queries in your application. Run everything through SPROCs. Then create db-accounts for each user and assign privileges to the SPROCs only.
Pros
- Most effective protection mechanism.
- SPROCs can force users to pass criteria to every query (including
DELETE
andUPDATE
)
Cons
- not sure if this works with MySQL (my knowledge in that area is flaky).
- complex development cycle: Everything you want to do, must first be defined in a SPROC.
Final thoughts
You should never allow database administrative tasks to the application. Most of the time, the only operations an application needs are SELECT
, INSERT
, DELETE
and UPDATE
. If you follow this guideline, there is hardly a risk involved by users discovering the password. Except the points mentioned above.
In any case, keep backups. I assume you want to project you database against accidental deletes or updates. But accidents happen... keep that in mind ;)
add a comment |
Short answer
You can't.
If the password is stored in the artifact that's shipped to the end-user you must consider it compromised! Even if the artifact is a compiled binary, there are always (more or less complicated) ways to get at the password.
The only way to protect your resources is by exposing only a limited API to the end-user. Either build a programmatic API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) or only expose certain functionalities in your DB via SPROCs (see below).
Some things first...
The question here should not be how to hide the password, but how to secure the database. Remember that passwords only are often a very weak protection and should not be considered the sole mechanism of protecting the DB. Are you using SSL? No? Well, then even if you manage to hide the password in the application code, it's still easy to sniff it on the network!
You have multiple options. All with varying degrees of security:
"Application Role"
Create one database-user for the application. Apply authorization for this role. A very common setup is to only allow CRUD ops.
Pros
very easy to set-up- Prevents
DROP
queries (f.ex. in SQL injections?)
Cons
- Everybody seeing the password has access to all the data in the database. Even if that data is normally hidden in the application.
- If the password is compromised, the user can run
UPDATE
andDELETE
queries without criteria (i.e.: delete/update a whole table at once).
Atomic auth&auth
Create one database user per application-/end-user. This allows you to define atomic access rights even on a per-column basis. For example: User X can only select columns far and baz from table foo. And nothing else. But user Y can SELECT
everything, but no updates, while user Z has full CRUD (select, insert, update, delete) access.
Some databases allow you to reuse the OS-level credentials. This makes authentication to the user transparent (only needs to log-in to the workstation, that identity is then forwarded to the DB). This works easiest in a full MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) but is - as far as I am aware - also possible to achieve in other DBs.
Pros
- Fairly easy to set up.
- Very atomic authorization scheme
Cons
- Can be tedious to set up all the access rights in the DB.
- Users with
UPDATE
andDELETE
rights can still accidentally (or intentionally?) delete/update without criteria. You risk losing all the data in a table.
Stored Procedures with atomic auth&auth
Write no SQL queries in your application. Run everything through SPROCs. Then create db-accounts for each user and assign privileges to the SPROCs only.
Pros
- Most effective protection mechanism.
- SPROCs can force users to pass criteria to every query (including
DELETE
andUPDATE
)
Cons
- not sure if this works with MySQL (my knowledge in that area is flaky).
- complex development cycle: Everything you want to do, must first be defined in a SPROC.
Final thoughts
You should never allow database administrative tasks to the application. Most of the time, the only operations an application needs are SELECT
, INSERT
, DELETE
and UPDATE
. If you follow this guideline, there is hardly a risk involved by users discovering the password. Except the points mentioned above.
In any case, keep backups. I assume you want to project you database against accidental deletes or updates. But accidents happen... keep that in mind ;)
add a comment |
Short answer
You can't.
If the password is stored in the artifact that's shipped to the end-user you must consider it compromised! Even if the artifact is a compiled binary, there are always (more or less complicated) ways to get at the password.
The only way to protect your resources is by exposing only a limited API to the end-user. Either build a programmatic API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) or only expose certain functionalities in your DB via SPROCs (see below).
Some things first...
The question here should not be how to hide the password, but how to secure the database. Remember that passwords only are often a very weak protection and should not be considered the sole mechanism of protecting the DB. Are you using SSL? No? Well, then even if you manage to hide the password in the application code, it's still easy to sniff it on the network!
You have multiple options. All with varying degrees of security:
"Application Role"
Create one database-user for the application. Apply authorization for this role. A very common setup is to only allow CRUD ops.
Pros
very easy to set-up- Prevents
DROP
queries (f.ex. in SQL injections?)
Cons
- Everybody seeing the password has access to all the data in the database. Even if that data is normally hidden in the application.
- If the password is compromised, the user can run
UPDATE
andDELETE
queries without criteria (i.e.: delete/update a whole table at once).
Atomic auth&auth
Create one database user per application-/end-user. This allows you to define atomic access rights even on a per-column basis. For example: User X can only select columns far and baz from table foo. And nothing else. But user Y can SELECT
everything, but no updates, while user Z has full CRUD (select, insert, update, delete) access.
Some databases allow you to reuse the OS-level credentials. This makes authentication to the user transparent (only needs to log-in to the workstation, that identity is then forwarded to the DB). This works easiest in a full MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) but is - as far as I am aware - also possible to achieve in other DBs.
Pros
- Fairly easy to set up.
- Very atomic authorization scheme
Cons
- Can be tedious to set up all the access rights in the DB.
- Users with
UPDATE
andDELETE
rights can still accidentally (or intentionally?) delete/update without criteria. You risk losing all the data in a table.
Stored Procedures with atomic auth&auth
Write no SQL queries in your application. Run everything through SPROCs. Then create db-accounts for each user and assign privileges to the SPROCs only.
Pros
- Most effective protection mechanism.
- SPROCs can force users to pass criteria to every query (including
DELETE
andUPDATE
)
Cons
- not sure if this works with MySQL (my knowledge in that area is flaky).
- complex development cycle: Everything you want to do, must first be defined in a SPROC.
Final thoughts
You should never allow database administrative tasks to the application. Most of the time, the only operations an application needs are SELECT
, INSERT
, DELETE
and UPDATE
. If you follow this guideline, there is hardly a risk involved by users discovering the password. Except the points mentioned above.
In any case, keep backups. I assume you want to project you database against accidental deletes or updates. But accidents happen... keep that in mind ;)
Short answer
You can't.
If the password is stored in the artifact that's shipped to the end-user you must consider it compromised! Even if the artifact is a compiled binary, there are always (more or less complicated) ways to get at the password.
The only way to protect your resources is by exposing only a limited API to the end-user. Either build a programmatic API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) or only expose certain functionalities in your DB via SPROCs (see below).
Some things first...
The question here should not be how to hide the password, but how to secure the database. Remember that passwords only are often a very weak protection and should not be considered the sole mechanism of protecting the DB. Are you using SSL? No? Well, then even if you manage to hide the password in the application code, it's still easy to sniff it on the network!
You have multiple options. All with varying degrees of security:
"Application Role"
Create one database-user for the application. Apply authorization for this role. A very common setup is to only allow CRUD ops.
Pros
very easy to set-up- Prevents
DROP
queries (f.ex. in SQL injections?)
Cons
- Everybody seeing the password has access to all the data in the database. Even if that data is normally hidden in the application.
- If the password is compromised, the user can run
UPDATE
andDELETE
queries without criteria (i.e.: delete/update a whole table at once).
Atomic auth&auth
Create one database user per application-/end-user. This allows you to define atomic access rights even on a per-column basis. For example: User X can only select columns far and baz from table foo. And nothing else. But user Y can SELECT
everything, but no updates, while user Z has full CRUD (select, insert, update, delete) access.
Some databases allow you to reuse the OS-level credentials. This makes authentication to the user transparent (only needs to log-in to the workstation, that identity is then forwarded to the DB). This works easiest in a full MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) but is - as far as I am aware - also possible to achieve in other DBs.
Pros
- Fairly easy to set up.
- Very atomic authorization scheme
Cons
- Can be tedious to set up all the access rights in the DB.
- Users with
UPDATE
andDELETE
rights can still accidentally (or intentionally?) delete/update without criteria. You risk losing all the data in a table.
Stored Procedures with atomic auth&auth
Write no SQL queries in your application. Run everything through SPROCs. Then create db-accounts for each user and assign privileges to the SPROCs only.
Pros
- Most effective protection mechanism.
- SPROCs can force users to pass criteria to every query (including
DELETE
andUPDATE
)
Cons
- not sure if this works with MySQL (my knowledge in that area is flaky).
- complex development cycle: Everything you want to do, must first be defined in a SPROC.
Final thoughts
You should never allow database administrative tasks to the application. Most of the time, the only operations an application needs are SELECT
, INSERT
, DELETE
and UPDATE
. If you follow this guideline, there is hardly a risk involved by users discovering the password. Except the points mentioned above.
In any case, keep backups. I assume you want to project you database against accidental deletes or updates. But accidents happen... keep that in mind ;)
edited Nov 12 '18 at 7:57
answered Aug 8 '11 at 11:56
exhuma
9,56465481
9,56465481
add a comment |
add a comment |
In this case, I create a new section in my .my.cnf, like
[files]
host=127.0.0.1
port=3307
database=files
default-character-set=utf8
password=foobar
and use it on DB initialization with
d=MySQLdb.connect(
read_default_group='files',
port=0, # read from .my.cnf
db='files',
cursorclass=cursors.DictCursor,
# amongst other stuff
)
This still lets users read the file iirc.
– exhuma
Aug 8 '11 at 11:28
This is right, but it is not distributed together with the source code. But it might be that I mis-interpreted the original motivation of the asker - I thought he wanted to prevent accidential distribution of the password included in the source.
– glglgl
Aug 8 '11 at 12:00
well... themy.cnf
file has to be located on the client. In other words, it's got to be on the machine which also runs the application. Also, the application normally runs under the same credentials as the user. This implies that the user needs read access to the file. So, this will make it less obvious but a skilled attacker could still locate this easily.
– exhuma
Aug 8 '11 at 17:39
I have the same question with the asker, but your answer does answer what I want to ask. 1UP!
– weefwefwqg3
Oct 21 '17 at 23:14
add a comment |
In this case, I create a new section in my .my.cnf, like
[files]
host=127.0.0.1
port=3307
database=files
default-character-set=utf8
password=foobar
and use it on DB initialization with
d=MySQLdb.connect(
read_default_group='files',
port=0, # read from .my.cnf
db='files',
cursorclass=cursors.DictCursor,
# amongst other stuff
)
This still lets users read the file iirc.
– exhuma
Aug 8 '11 at 11:28
This is right, but it is not distributed together with the source code. But it might be that I mis-interpreted the original motivation of the asker - I thought he wanted to prevent accidential distribution of the password included in the source.
– glglgl
Aug 8 '11 at 12:00
well... themy.cnf
file has to be located on the client. In other words, it's got to be on the machine which also runs the application. Also, the application normally runs under the same credentials as the user. This implies that the user needs read access to the file. So, this will make it less obvious but a skilled attacker could still locate this easily.
– exhuma
Aug 8 '11 at 17:39
I have the same question with the asker, but your answer does answer what I want to ask. 1UP!
– weefwefwqg3
Oct 21 '17 at 23:14
add a comment |
In this case, I create a new section in my .my.cnf, like
[files]
host=127.0.0.1
port=3307
database=files
default-character-set=utf8
password=foobar
and use it on DB initialization with
d=MySQLdb.connect(
read_default_group='files',
port=0, # read from .my.cnf
db='files',
cursorclass=cursors.DictCursor,
# amongst other stuff
)
In this case, I create a new section in my .my.cnf, like
[files]
host=127.0.0.1
port=3307
database=files
default-character-set=utf8
password=foobar
and use it on DB initialization with
d=MySQLdb.connect(
read_default_group='files',
port=0, # read from .my.cnf
db='files',
cursorclass=cursors.DictCursor,
# amongst other stuff
)
answered Aug 8 '11 at 11:15
glglgl
65.9k788163
65.9k788163
This still lets users read the file iirc.
– exhuma
Aug 8 '11 at 11:28
This is right, but it is not distributed together with the source code. But it might be that I mis-interpreted the original motivation of the asker - I thought he wanted to prevent accidential distribution of the password included in the source.
– glglgl
Aug 8 '11 at 12:00
well... themy.cnf
file has to be located on the client. In other words, it's got to be on the machine which also runs the application. Also, the application normally runs under the same credentials as the user. This implies that the user needs read access to the file. So, this will make it less obvious but a skilled attacker could still locate this easily.
– exhuma
Aug 8 '11 at 17:39
I have the same question with the asker, but your answer does answer what I want to ask. 1UP!
– weefwefwqg3
Oct 21 '17 at 23:14
add a comment |
This still lets users read the file iirc.
– exhuma
Aug 8 '11 at 11:28
This is right, but it is not distributed together with the source code. But it might be that I mis-interpreted the original motivation of the asker - I thought he wanted to prevent accidential distribution of the password included in the source.
– glglgl
Aug 8 '11 at 12:00
well... themy.cnf
file has to be located on the client. In other words, it's got to be on the machine which also runs the application. Also, the application normally runs under the same credentials as the user. This implies that the user needs read access to the file. So, this will make it less obvious but a skilled attacker could still locate this easily.
– exhuma
Aug 8 '11 at 17:39
I have the same question with the asker, but your answer does answer what I want to ask. 1UP!
– weefwefwqg3
Oct 21 '17 at 23:14
This still lets users read the file iirc.
– exhuma
Aug 8 '11 at 11:28
This still lets users read the file iirc.
– exhuma
Aug 8 '11 at 11:28
This is right, but it is not distributed together with the source code. But it might be that I mis-interpreted the original motivation of the asker - I thought he wanted to prevent accidential distribution of the password included in the source.
– glglgl
Aug 8 '11 at 12:00
This is right, but it is not distributed together with the source code. But it might be that I mis-interpreted the original motivation of the asker - I thought he wanted to prevent accidential distribution of the password included in the source.
– glglgl
Aug 8 '11 at 12:00
well... the
my.cnf
file has to be located on the client. In other words, it's got to be on the machine which also runs the application. Also, the application normally runs under the same credentials as the user. This implies that the user needs read access to the file. So, this will make it less obvious but a skilled attacker could still locate this easily.– exhuma
Aug 8 '11 at 17:39
well... the
my.cnf
file has to be located on the client. In other words, it's got to be on the machine which also runs the application. Also, the application normally runs under the same credentials as the user. This implies that the user needs read access to the file. So, this will make it less obvious but a skilled attacker could still locate this easily.– exhuma
Aug 8 '11 at 17:39
I have the same question with the asker, but your answer does answer what I want to ask. 1UP!
– weefwefwqg3
Oct 21 '17 at 23:14
I have the same question with the asker, but your answer does answer what I want to ask. 1UP!
– weefwefwqg3
Oct 21 '17 at 23:14
add a comment |
Similar unanswered question here: https://stackoverflow.com/questions/2850710/connect-to-a-db-with-an-encrypted-password-with-django The python DBAPI (PEP 249) has no interface for connecting to the database with an encrypted/hashed password in lieu of a plaintext password.
While this feature in other languages is comforting, it does not provide any real additional security: the hash of the password is as good as the password. You still have to control access to the database resources as exhuma describes.
MySQL itself does not provide any additional options, regardless of python bindings or not. You can read their guidance in the MySQL User Manual section on Password Security. The recommended option for protecting access to the password is to store it in an option file and protect the file, as described by glglgl.
From that page:
The methods you can use to specify your password when you run client
programs are listed here, along with an assessment of the risks of
each method. In short, the safest methods are to have the client
program prompt for the password or to specify the password in a
properly protected option file.
I disagree with the option file. This file will not hide the password from a prying user. As I explained in the comment to glglgl's answer, the client application needs read access to the file, which in turn means, the user needs read access. Usually, a non-superuser cannot escalate the access rights.
– exhuma
Aug 8 '11 at 17:45
I don't disagree with you, but I also don't know any other options. Your post covers the database design requirements to limit the exposure, but doesn't address storage of the credentials. Is there a better way?
– J.J.
Aug 8 '11 at 17:57
Not that I know of. :/
– exhuma
Aug 10 '11 at 7:05
add a comment |
Similar unanswered question here: https://stackoverflow.com/questions/2850710/connect-to-a-db-with-an-encrypted-password-with-django The python DBAPI (PEP 249) has no interface for connecting to the database with an encrypted/hashed password in lieu of a plaintext password.
While this feature in other languages is comforting, it does not provide any real additional security: the hash of the password is as good as the password. You still have to control access to the database resources as exhuma describes.
MySQL itself does not provide any additional options, regardless of python bindings or not. You can read their guidance in the MySQL User Manual section on Password Security. The recommended option for protecting access to the password is to store it in an option file and protect the file, as described by glglgl.
From that page:
The methods you can use to specify your password when you run client
programs are listed here, along with an assessment of the risks of
each method. In short, the safest methods are to have the client
program prompt for the password or to specify the password in a
properly protected option file.
I disagree with the option file. This file will not hide the password from a prying user. As I explained in the comment to glglgl's answer, the client application needs read access to the file, which in turn means, the user needs read access. Usually, a non-superuser cannot escalate the access rights.
– exhuma
Aug 8 '11 at 17:45
I don't disagree with you, but I also don't know any other options. Your post covers the database design requirements to limit the exposure, but doesn't address storage of the credentials. Is there a better way?
– J.J.
Aug 8 '11 at 17:57
Not that I know of. :/
– exhuma
Aug 10 '11 at 7:05
add a comment |
Similar unanswered question here: https://stackoverflow.com/questions/2850710/connect-to-a-db-with-an-encrypted-password-with-django The python DBAPI (PEP 249) has no interface for connecting to the database with an encrypted/hashed password in lieu of a plaintext password.
While this feature in other languages is comforting, it does not provide any real additional security: the hash of the password is as good as the password. You still have to control access to the database resources as exhuma describes.
MySQL itself does not provide any additional options, regardless of python bindings or not. You can read their guidance in the MySQL User Manual section on Password Security. The recommended option for protecting access to the password is to store it in an option file and protect the file, as described by glglgl.
From that page:
The methods you can use to specify your password when you run client
programs are listed here, along with an assessment of the risks of
each method. In short, the safest methods are to have the client
program prompt for the password or to specify the password in a
properly protected option file.
Similar unanswered question here: https://stackoverflow.com/questions/2850710/connect-to-a-db-with-an-encrypted-password-with-django The python DBAPI (PEP 249) has no interface for connecting to the database with an encrypted/hashed password in lieu of a plaintext password.
While this feature in other languages is comforting, it does not provide any real additional security: the hash of the password is as good as the password. You still have to control access to the database resources as exhuma describes.
MySQL itself does not provide any additional options, regardless of python bindings or not. You can read their guidance in the MySQL User Manual section on Password Security. The recommended option for protecting access to the password is to store it in an option file and protect the file, as described by glglgl.
From that page:
The methods you can use to specify your password when you run client
programs are listed here, along with an assessment of the risks of
each method. In short, the safest methods are to have the client
program prompt for the password or to specify the password in a
properly protected option file.
edited May 23 '17 at 11:46
Community♦
11
11
answered Aug 8 '11 at 12:51
J.J.
4,27122226
4,27122226
I disagree with the option file. This file will not hide the password from a prying user. As I explained in the comment to glglgl's answer, the client application needs read access to the file, which in turn means, the user needs read access. Usually, a non-superuser cannot escalate the access rights.
– exhuma
Aug 8 '11 at 17:45
I don't disagree with you, but I also don't know any other options. Your post covers the database design requirements to limit the exposure, but doesn't address storage of the credentials. Is there a better way?
– J.J.
Aug 8 '11 at 17:57
Not that I know of. :/
– exhuma
Aug 10 '11 at 7:05
add a comment |
I disagree with the option file. This file will not hide the password from a prying user. As I explained in the comment to glglgl's answer, the client application needs read access to the file, which in turn means, the user needs read access. Usually, a non-superuser cannot escalate the access rights.
– exhuma
Aug 8 '11 at 17:45
I don't disagree with you, but I also don't know any other options. Your post covers the database design requirements to limit the exposure, but doesn't address storage of the credentials. Is there a better way?
– J.J.
Aug 8 '11 at 17:57
Not that I know of. :/
– exhuma
Aug 10 '11 at 7:05
I disagree with the option file. This file will not hide the password from a prying user. As I explained in the comment to glglgl's answer, the client application needs read access to the file, which in turn means, the user needs read access. Usually, a non-superuser cannot escalate the access rights.
– exhuma
Aug 8 '11 at 17:45
I disagree with the option file. This file will not hide the password from a prying user. As I explained in the comment to glglgl's answer, the client application needs read access to the file, which in turn means, the user needs read access. Usually, a non-superuser cannot escalate the access rights.
– exhuma
Aug 8 '11 at 17:45
I don't disagree with you, but I also don't know any other options. Your post covers the database design requirements to limit the exposure, but doesn't address storage of the credentials. Is there a better way?
– J.J.
Aug 8 '11 at 17:57
I don't disagree with you, but I also don't know any other options. Your post covers the database design requirements to limit the exposure, but doesn't address storage of the credentials. Is there a better way?
– J.J.
Aug 8 '11 at 17:57
Not that I know of. :/
– exhuma
Aug 10 '11 at 7:05
Not that I know of. :/
– exhuma
Aug 10 '11 at 7:05
add a comment |
Either use simple passwor like root
.Else Don't use password.
How do I prevent a user from changing the DB if there is no passd word?
– lang2
Aug 8 '11 at 11:06
To particular db, create a user with no password, for other DB create a different user and password, debuntu.org/…
– Kracekumar
Aug 8 '11 at 11:08
add a comment |
Either use simple passwor like root
.Else Don't use password.
How do I prevent a user from changing the DB if there is no passd word?
– lang2
Aug 8 '11 at 11:06
To particular db, create a user with no password, for other DB create a different user and password, debuntu.org/…
– Kracekumar
Aug 8 '11 at 11:08
add a comment |
Either use simple passwor like root
.Else Don't use password.
Either use simple passwor like root
.Else Don't use password.
answered Aug 8 '11 at 10:59
Kracekumar
9,87453441
9,87453441
How do I prevent a user from changing the DB if there is no passd word?
– lang2
Aug 8 '11 at 11:06
To particular db, create a user with no password, for other DB create a different user and password, debuntu.org/…
– Kracekumar
Aug 8 '11 at 11:08
add a comment |
How do I prevent a user from changing the DB if there is no passd word?
– lang2
Aug 8 '11 at 11:06
To particular db, create a user with no password, for other DB create a different user and password, debuntu.org/…
– Kracekumar
Aug 8 '11 at 11:08
How do I prevent a user from changing the DB if there is no passd word?
– lang2
Aug 8 '11 at 11:06
How do I prevent a user from changing the DB if there is no passd word?
– lang2
Aug 8 '11 at 11:06
To particular db, create a user with no password, for other DB create a different user and password, debuntu.org/…
– Kracekumar
Aug 8 '11 at 11:08
To particular db, create a user with no password, for other DB create a different user and password, debuntu.org/…
– Kracekumar
Aug 8 '11 at 11:08
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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%2fstackoverflow.com%2fquestions%2f6981064%2fsafeguarding-mysql-password-when-developing-in-python%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
Define it in a central place and edit it out before shipping?
– Jacob
Aug 8 '11 at 10:56
Is this going to connect to a database of yours, or the purchaser's database?
– Raz
Aug 8 '11 at 11:06