Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Allow a blank password for the database #863

WilliamVercken opened this Issue Jan 27, 2014 · 13 comments


None yet
4 participants

Hi !

I really want to test this CMS, but I can't install it without creating a new user for my database, and I don't want to (local server) or I can't (distant server).
Can you just allow us to install it without forcing us to do that ?

A comment from this issue #184 (comment) :

Forcing the user/dev to have a password set is really not a good idea. Many many developers have mysql locally installed to debug/test etc. They usually don't have a password set because the server is bound to loopback interface or hostname is restricted to "localhost" and therefore its useless to set a password. Also some cloud provider does not set a mysql password but limit the access on TCP level, which is usually more secure. (which is sometimes needed to automatically boot new load-balancer slave instances while not saving the password in the repository/image)

MySQL and PostgreSQL do support also more authentication methods than the good old password login. Restricting that isn't a good idea IMHO.

Thanks a lot ! I'm eager to test it !! :)


GawainLynch commented Jan 27, 2014

Hi William,

I have some good news for you, and it is one of the things that made me fall in love with this work myself recently. A default and unmodified install of Bolt will create its own flat database file... You can, out-of-the-box set it up and avoid using MySQL/Postgres, which is the configuration that is discussed in your linked issue.

So test away as you desire on your own machine and see how awesome this CMS is :-)

marcj commented Jan 27, 2014

@GawainLynch, you should read the quoted comment. Those issues there aren't fixed with that 'flat database file' (whatever this is)

Oh, I didn't know that ! Great !

I always think that we should have the choice to use MySql without a password (so I will not close this issue :p ), but for now I will test it without using any database system, thank you very much @GawainLynch for the information !! 👍


GawainLynch commented Jan 27, 2014

@marcj, good news is that thread and the experience I have had.

When you look in app/config/config.yaml.dist (which gets copied minus the .dist on install), you will see that the default database driver is flat file and security agnostic.... I will simply say that a password-less database is a bad idea, if you don't know why then you should try to enter the USA in my escort ;-) however, if you won't it in a simple form, this product makes it pleasantly simple for you.

P.S. I am on a cross-country train, I can't look (easily) at the code base to give references, but following @bobdenotter 's documentation, this is all very easy to achieve. Again, the people that make this software make it worth using

marcj commented Jan 27, 2014

@GawainLynch, erm, what are you trying to say? Having a password does not protect you from direct access of the database. When you say, USA opens your notebook and want see what's inside your database then a password is not necessary because mysql's binary files are not encrypted. Making your data on your notebook secure is not a question about mysql's credentials but about a protection of the whole system. (bios/operating system level)
It makes no sense to me what you're saying at all.

However, it is still not useful to force the user to use a database password. Your 'case' with entering the USA etc etc is ... quite a stretch.


bobdenotter commented Jan 28, 2014

I think having a blank password for MySQL is just plain stupid, regardless of the feasibility of @GawainLynch's example. It's just bad practice, no matter which way you spin it.
Anyhow, since this issue keeps popping up, I think i'm just going to give in, and we're going to change the behaviour to allow blank passwords. If you don't want to be safe, you should have the right to do so. :-/


GawainLynch commented Jan 28, 2014

@marcj, What I was trying to say in my sideways comment was that the US border control is interested in me and what they know is inside my head, not my laptop... the reason for being vague is that most of what I have to say can't be said publicly. My contact details can easily be found on the Internet however, and I am happy to sit with you one day and expand on it over a coffee or glass of wine.

My initial response is to the fact that @WilliamVercken made the comment that:

I really want to test this CMS

The reply I gave to that was that he can, as by default Bolt will set up an SQLite database file in app/database/bolt.db that doesn't require a database password. That is true, and I saw that as a helpful response from someone trying to contribute to a community.

@marcj I also want to say that your comment(s) do have a lot of accurate information/concern and I was not trying to argue that down. However, speaking for myself, my professional concerns with having a password free option is that is that it has the potential to create/encourage bad practice, and have lost count of the amount of time that my auditing has uncovered security holes created by brain-dead laziness as far down the track as UAT and even production.


bobdenotter commented Feb 2, 2014

I've made a small change, so that Bolt will now allow empty passwords for all users, except root. There is really, really no good reason ever to want to have an empty password for root.

At the same time, if you're stuck in the hypothetical situation that you're trying out Bolt on a system and you only have 'root' and can't change the password, you should simply add a new user with a password. You are root, after all. ;-)

Yeah... So you didn't solved the issue and you instead of listening to your users, you prefer tell them what to do because "this is stupid". (Every others CMS are stupid, by the way.) Ok, nevermind. I think a simple warning message was enough to explain people why you think we should have database password.
I hope you'll change your mind one day, your project is promising.


bobdenotter commented Feb 2, 2014

So you didn't solved the issue and instead of listening to your users

That is absolutely not true. Just because I disagree with you on this subject, does not mean I'm not listening to what you have to say.

And, I think this issue is actually 'solved' as it is. As far as i can tell, there are four different possibilities:

  • Root with password: Bolt works
  • User with password: Bolt works
  • Root with empty password: Bolt won't work, but you can easily add another user. Or, just use SQLite for testing.
  • User with empty password: Bolt works.

So, that leaves no cases where you can't use bolt, right?

Also, it would've been much easier to just give in, and allow an empty password for Bolt. But, that's just bad practice, and (imho) would've made bolt a worse product overall because of it. To make a good and consistent product, unfortunately sometimes we have to say "no" to suggestions. If you're interested, read this excellent article on the matter: http://insideintercom.io/product-strategy-means-saying-no/

your project is promising.

Thanks, we think so too. I hope this little disagreement about a minor issue isn't going to make you go away. We really are a friendly bunch, most of the time. :-)

marcj commented Feb 2, 2014

Do you have more information about

But, that's just bad practice

? I disagree here.

It should be up to the developer how they configure their system. You should focus on being a CMS not a teacher for admins. I want to setup my system how I want and not how others want it to be. Of course, would it be a requirement to be able to run your system then I'd do it, but it isn't. If you'd strictly follow your argumentation of this is bad practice then the next logical step would be to allow only passwords with min length of X or something like that.
Also those developers who don't want to setup a password use then passwords like root or password. I don't think that is better. Please, just let lazy developers be lazy and don't try to dictate your personal best practices. No one benefits from being forced to do it.


bobdenotter commented Feb 2, 2014

Some quick googling gave me these sources:

  • "When installed, MySQL enables any user with physical permissions to the server to connect to the MySQL via unauthenticated users. MySQL also provides complete access to all super user privileges via the ‘root’ user with no default password." - very first point to fix
  • "Do not have an empty root password. Otherwise anyone can connect as root without a password and be granted all privileges." source
  • "The default administrator username on the MySQL server is "root". Hackers often attempt to gain access to its permissions. To make this task harder, rename "root" to something else and provide it with a long, complex alphanumeric password." - source

You should focus on being a CMS not a teacher for admins

You're right about that. However, we take security very seriously with Bolt. So far we've had no significant security-issues, and we intend to keep it that way. However, it's totally possible that one day a security issue would be discovered, or there's an (other, unrelated) security issue with an extension. There's always a possibility that one tiny issue could be escalated to a huge issue, because potential issues are left open. I consider "blank root password" to be one of such "potential issues".
Therefore we consider this not something that's "let them be lazy", but "we will not allow it, to prevent possible issues in the future" instead.

marcj commented Feb 2, 2014

Yes, your links are about productive systems. However, I think we're talking at cross-purposes here. You're arguing for productive systems/usage, I'm talking about dev/evaluation/testing environments like the intention of the thread creator here. Would you extend your test suite in travis you'd see that even travis does not have root/postgres passwords set because it makes not much sense in such environments. When I test/evaluate some software, I do have a kinda equal virtual machine for that - without passwords. I won't change that only for Bolt as almost all other systems allow me to use no passwords.

Ok, nevermind, I give up as I see it's pointless to discuss with people who don't pick up my argumentations and do not discuss about it but bring in arguments of personal best practices from a complete different use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment