Blank root password wtf



  • I just started a new project, coded by a team of crack experts I'm sure, and this is the first file I look in, and the first few lines I see...

    [code]$dbserver = "localhost";
    $dbuser = "root";
    $dbpass = '';
    $dbname = "newproject"; [/code]
    Not anonymized at all. It's gonna be a long winter...


  • Is the database daemon running on a network port?  Why is this a problem? 



  • I'm going to assume that you got that code from a source repository. In which case this is just the default data, and on production they actually have it configured. If this is prooduction, then it's just sloppy, and a potential security risk.



  •  Are you sure this is really a WTF? What are the IP of the server and port MySQL is listening to?

     whistle



  •  Assuming this is in a closed enviroment it might be excusable. But I still don't want to see this kind of thing where I work. First of all the amount of work it takes to create a new user in a database is trivial so this is just laziness. Second you never know when this might end up in production. Maybe some PHB decides to use the dev enviroment as production, maybe some inept programmer is charged to make this public and forgets/can't be bothered to change the db user. It happens all the time and then it ends up here.



  • @DOA said:

     Assuming this is in a closed enviroment it might be excusable. But I still don't want to see this kind of thing where I work. First of all the amount of work it takes to create a new user in a database is trivial so this is just laziness. Second you never know when this might end up in production. Maybe some PHB decides to use the dev enviroment as production, maybe some inept programmer is charged to make this public and forgets/can't be bothered to change the db user. It happens all the time and then it ends up here.

     

    I actually agree with you on something...  You never know when your param file will make it into production.  I had a release myself last week where I left in the C: ( from testing on my machine) and forgot to put it to /usr/...   I forgot, it happens shrug, but it is definitely a bad idea to do passwords / accounts this way.



  • @DOA said:

    Second you never know when this might end up in production.

    Years ago, I found a bug in some code I'd put into 'review' a few hours before.  I considered posting a correction immediately, but thought, "No, it'll be a good test of the review process."  Two days later, I went on vacation for two weeks.  About 3/4 of the way through that time, I got a panicked call from the office - they ran into a problem that required the new code, so they'd put it into production.  For what it's worth, this didn't show the reviewers missed the flaw - they hadn't reviewed it yet, because they knew I was going to be out and wasn't going to be replying to issues.  When the first crisis occurred, management directed them to put it into production immediately, so it went in without review, and caused an even bigger crisis.



  • i guess i should have clarified in my OP...this is production.

    So thats why its a wtf...



  • @fizzle said:

    i guess i should have clarified in my OP...this is production.

    So thats why its a wtf...

     

     

    That makes it a wtf if nothing else does. 



  • @DOA said:

    Assuming this is in a closed enviroment it might be excusable. But I still don't want to see this kind of thing where I work. First of all the amount of work it takes to create a new user in a database is trivial so this is just laziness. Second you never know when this might end up in production. Maybe some PHB decides to use the dev enviroment as production, maybe some inept programmer is charged to make this public and forgets/can't be bothered to change the db user. It happens all the time and then it ends up here.

    Why even bother with user accounts and passwords in a closed environment? 



  • @fizzle said:

    <FONT size=2 face="Lucida Console">$dbname = "newproject"; </FONT>
    Not anonymized at all. It's gonna be a long winter...

    So it's actually called "newproject"? What if another project springs up, will it be "newnewproject"?



  • @fizzle said:

    i guess i should have clarified in my OP...this is production.

    So thats why its a wtf...

    I never assumed it wasn't production.  My question is, why does this matter?  Is the mysqld running on a network port that is accessible via the Internet, or at least on a network that it shouldn't be?  That would obviously be a WTF, but you haven't given enough info to be sure.  I use a blank password for the root user on my production DBs and that's certainly not a WTF. 



  • IT increases the danger possed by sql injection. Instead of only being able to query for data or perhaps affect the site specific data, they will now be able to do everything. It's common sense to create a restricted user for any application. Be it internal/external website or whatever. It's good practice to create two users of whom one has only read access and the other write.

    You can say your application can't be exploited via that angle, but i rather make sure that if it does happen the damage is limited. It's a small bit of extra work that can save a butload of work if something bad happens.

     



  • @stratos said:

    IT increases the danger possed by sql injection. Instead of only being able to query for data or perhaps affect the site specific data, they will now be able to do everything. It's common sense to create a restricted user for any application. Be it internal/external website or whatever. It's good practice to create two users of whom one has only read access and the other write.

    You can say your application can't be exploited via that angle, but i rather make sure that if it does happen the damage is limited. It's a small bit of extra work that can save a butload of work if something bad happens. 

    If SQL injection is even a possibility in your app, then that is TRWTF.  Restricted DB users are just a band-aid for SQL injection and a decent programmer won't even be vulnerable to injection so the user accounts just get in the way.  It also requires 2 connections to the DB server.  In some cases you might already have 2 connections to 2 different servers (some types of replication) but personally I prefer simpler replication setups that use only 1 connection and plenty of people don't even use replication at all, making 2 connections to 1 server quite wasteful. 



  • You're right, a decent programmer would not only catch every potential SQL injection hole, but they'd also go through any libraries they happen to be using and fix them too.



  • @morbiuswilters said:

    @stratos said:

    IT increases the danger possed by sql injection. Instead of only being able to query for data or perhaps affect the site specific data, they will now be able to do everything. It's common sense to create a restricted user for any application. Be it internal/external website or whatever. It's good practice to create two users of whom one has only read access and the other write.

    You can say your application can't be exploited via that angle, but i rather make sure that if it does happen the damage is limited. It's a small bit of extra work that can save a butload of work if something bad happens. 

    If SQL injection is even a possibility in your app, then that is TRWTF.  Restricted DB users are just a band-aid for SQL injection and a decent programmer won't even be vulnerable to injection so the user accounts just get in the way.  It also requires 2 connections to the DB server.  In some cases you might already have 2 connections to 2 different servers (some types of replication) but personally I prefer simpler replication setups that use only 1 connection and plenty of people don't even use replication at all, making 2 connections to 1 server quite wasteful. 

     

    I rather not assume i'm infallible, nor do i assume i will be the only one working on a app. Mistakes happen, damage control is key in these moments. And depending on the type of app, performance issues due to use of 2 separate connections is very small. On your average website for instance, write will only be used very little. If it is however a problem, it isn't a iron fist rule, just a precaution that can be left if needed.



  • @lolwtf said:

    You're right, a decent programmer would not only catch every potential SQL injection hole, but they'd also go through any libraries they happen to be using and fix them too.

    They're called prepared statements and have been around forever.  If you are manually escaping values in dynamically-generated SQL, that is the problem.  Trying to compensate by coming up with a convoluted DB user policy is just bad security practice.



  • @stratos said:

    And depending on the type of app, performance issues due to use of 2 separate connections is very small. On your average website for instance, write will only be used very little.

    I have to disagree here.  Each connection will use up a DB thread and limit the number of connections the daemon can accept. 



  •  So if you open too many connections and there aren't enough threads available, the daemon will escape?



  • @stratos said:

    @morbiuswilters said:

    @stratos said:

    IT increases the danger possed by sql injection. Instead of only being able to query for data or perhaps affect the site specific data, they will now be able to do everything. It's common sense to create a restricted user for any application. Be it internal/external website or whatever. It's good practice to create two users of whom one has only read access and the other write.

    You can say your application can't be exploited via that angle, but i rather make sure that if it does happen the damage is limited. It's a small bit of extra work that can save a butload of work if something bad happens. 

    If SQL injection is even a possibility in your app, then that is TRWTF.  Restricted DB users are just a band-aid for SQL injection and a decent programmer won't even be vulnerable to injection so the user accounts just get in the way.  It also requires 2 connections to the DB server.  In some cases you might already have 2 connections to 2 different servers (some types of replication) but personally I prefer simpler replication setups that use only 1 connection and plenty of people don't even use replication at all, making 2 connections to 1 server quite wasteful. 

     

    I rather not assume i'm infallible, nor do i assume i will be the only one working on a app. Mistakes happen, damage control is key in these moments. And depending on the type of app, performance issues due to use of 2 separate connections is very small. On your average website for instance, write will only be used very little. If it is however a problem, it isn't a iron fist rule, just a precaution that can be left if needed.

     

    I have two user accounts to my own database, one which I use for maintenance and manual queries and a restricted one used by other programs (such as websites and chatbots).  The restricted one has all the permissions it needs, which in my case is manipulating data (select, insert, update, delete).  However, it has no need to manipulate the structure of the database.  Perhaps I am a bit paranoid, but then again I have a RAID6 array in my fileserver at home and still take weekly backups to an external HDD, requiring a minimum of three disk failures within a day or two to lose any data.  No offsite backups yet but I'm working on a plan for those.  And this is all for my home system, mind you, personal data which is unlikely to be of interest to anyone else or cause me any significant financial loss (although the emotional loss would be great indeed).



  •  @tdb said:

    personal data which is unlikely to be of interest to anyone else or cause me any significant financial loss (although the emotional loss would be great indeed).
    It's sheep porn, isn't it?



  • @morbiuswilters said:

    I never assumed it wasn't production.  My question is, why does this matter?  Is the mysqld running on a network port that is accessible via the Internet, or at least on a network that it shouldn't be?
    I agree with morbs here.  My MySQL daemon is only open to localhost, but what do I have on localhost?  PHPMyAdmin.  Therefore it would be retarded of me to make a blank password.

    Yeah, this comment is probably worthless, but I wanted to point out that even if you don't have your daemon opened up to the network, other things can expose you.



  • @belgariontheking said:

    I wanted to point out that even if you don't have your daemon opened up to the network, other things can expose you.
     

    Or a scenario the other way around: the application might remain on that (presumably dedicated) server, but one fine day the server itself gets turned into a shared hosting server... blank passwords simply scare me, sorry. There's absolutely zero excuse to not just create one. Then again, web apps connecting to a DB as root scare me, password or no.



  • @morbiuswilters said:

    If SQL injection is even a possibility in your app, then that is TRWTF.  Restricted DB users are just a band-aid for SQL injection and a decent programmer won't even be vulnerable to injection so the user accounts just get in the way.
     

    According to your logic, all applications should just be running as root/administrator. After all, a decent programmer won't even be vulnerable to security holes so the user accounts just get in the way.



  • @Eternal Density said:

     So if you open too many connections and there aren't enough threads available, the daemon will escape?

    That would explain why someone painted a pentagram under the DBMS box...



  • @dtech said:

    @morbiuswilters said:

    If SQL injection is even a possibility in your app, then that is TRWTF.  Restricted DB users are just a band-aid for SQL injection and a decent programmer won't even be vulnerable to injection so the user accounts just get in the way.
     

    According to your logic, all applications should just be running as root/administrator. After all, a decent programmer won't even be vulnerable to security holes so the user accounts just get in the way.

    Well, that depends.  On a single-purpose server then I run everything as root.  On my workstation machines I prefer just running everything as root, although some stupid applications complain about it.  There's nothing insecure about it. 



  • @Monomelodies said:

    Or a scenario the other way around: the application might remain on that (presumably dedicated) server, but one fine day the server itself gets turned into a shared hosting server... blank passwords simply scare me, sorry. There's absolutely zero excuse to not just create one.

    Obviously a shared-hosting solution would be different, but any serious money-generating web app is run on dedicated hardware.  If the network itself is locked down and physical access to the machines is secure, the empty password is no problem.  Having a blank password is simpler to maintain but I prefer just disabling authentication altogether seeing as that will give a bit of a speed boost as well.

     

    @Monomelodies said:

    Then again, web apps connecting to a DB as root scare me, password or no.

    Root is the only one with a blank password that doesn't scare me.  It indicates that the DB is running in a homogenous, controlled environment where security is handled somewhere other than the DB daemon itself.  If you have an untrusted environment (which, seriously, no for-profit company should) then you need to lock down things in more ways than one.  Of course, who even cares about DB access in that scenario, seeing as an attacker in that untrusted environment might be able to obtain real root and proceed to pwn all of your data anyway?



  • @morbiuswilters said:

    @Monomelodies said:

    Or a scenario the other way around: the application might remain on that (presumably dedicated) server, but one fine day the server itself gets turned into a shared hosting server... blank passwords simply scare me, sorry. There's absolutely zero excuse to not just create one.

    Obviously a shared-hosting solution would be different, but any serious money-generating web app is run on dedicated hardware.  If the network itself is locked down and physical access to the machines is secure, the empty password is no problem.  Having a blank password is simpler to maintain but I prefer just disabling authentication altogether seeing as that will give a bit of a speed boost as well.

    Initially i thought your argument of speed increase was bogus, however i figured it wouldn't hurt to do a quick google for it, and indeed it seems to give quite a nice speed boost in certain situations.

    http://www.arlogilbert.com/2008/10/26/mysql-skipgranttables/

     

    I still think having restrictions in place is simply good practice, but i can see how in some situations it would be benefital to make that sacrifice in favor of speed. 



Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.