Safeguarding MySQL password when developing in Python?












12














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.










share|improve this question
























  • 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
















12














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.










share|improve this question
























  • 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














12












12








12


4





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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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


















  • 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












4 Answers
4






active

oldest

votes


















13














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 and DELETE 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 and DELETE 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 and UPDATE)


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 ;)






share|improve this answer































    6














    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
    )





    share|improve this answer





















    • 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... 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



















    0














    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.







    share|improve this answer























    • 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



















    -3














    Either use simple passwor like root.Else Don't use password.






    share|improve this answer





















    • 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











    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    13














    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 and DELETE 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 and DELETE 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 and UPDATE)


    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 ;)






    share|improve this answer




























      13














      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 and DELETE 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 and DELETE 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 and UPDATE)


      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 ;)






      share|improve this answer


























        13












        13








        13






        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 and DELETE 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 and DELETE 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 and UPDATE)


        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 ;)






        share|improve this answer














        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 and DELETE 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 and DELETE 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 and UPDATE)


        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 ;)







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 12 '18 at 7:57

























        answered Aug 8 '11 at 11:56









        exhuma

        9,56465481




        9,56465481

























            6














            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
            )





            share|improve this answer





















            • 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... 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
















            6














            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
            )





            share|improve this answer





















            • 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... 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














            6












            6








            6






            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
            )





            share|improve this answer












            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
            )






            share|improve this answer












            share|improve this answer



            share|improve this answer










            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... 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


















            • 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... 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
















            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











            0














            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.







            share|improve this answer























            • 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
















            0














            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.







            share|improve this answer























            • 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














            0












            0








            0






            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.







            share|improve this answer














            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.








            share|improve this answer














            share|improve this answer



            share|improve this answer








            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


















            • 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











            -3














            Either use simple passwor like root.Else Don't use password.






            share|improve this answer





















            • 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
















            -3














            Either use simple passwor like root.Else Don't use password.






            share|improve this answer





















            • 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














            -3












            -3








            -3






            Either use simple passwor like root.Else Don't use password.






            share|improve this answer












            Either use simple passwor like root.Else Don't use password.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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


















            • 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


















            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Full-time equivalent

            さくらももこ

            13 indicted, 8 arrested in Calif. drug cartel investigation