I am planning creating a small personal blog application that handles only one user - the content author, let's call that user admin. There would not be any registration option, only a hidden login page that only the admin is aware of. There would not be any options that requires registration (no commenting, no posting, no voting, etc.). Normally I would store user data in a database and use that data during authentication process but in this case I am thinking of hard coding a username/password combination the admin can log in with, and create blog posts. I know this way there won't be chance to add more users later and the admin cannot modify the password without modifying the code or a properties file and redeploying the app. But besides these are there any more cons of this "quick and dirty" solution, especially from security point of view?
3 Answers
Your solution (hardcoding) is a perfect fit for your requirements. There is no need to implement a more complex architecture.
The usual gotchas about password authentication still apply – don't store them as plaintext but hash them with a suitable hash function. Preferably bcrypt, or else PBKDF2. The password should be sufficiently strong. Use HTTPS encryption for your site. Be aware that whoever has access to your configuration can change the password, so protecting access to your server is even more important than protecting access to the blog's admin account.
-
If we own/manage the hosting, another approach could be setting the hash (pass) as env var. So that, in case of having to change the password, no new build and deployment is requiered. It would takes to change the var and restart the app.– LaivCommented Aug 31, 2017 at 11:50
-
I would not recommend storing anything in clear text in the environment, a hash would be fine though - this recent example is a good reason to avoid plain text - theregister.co.uk/2017/08/02/typosquatting_npm Commented Aug 31, 2017 at 14:55
-
If you know that the one and only user will have a long, high-entropy password then you don't even technically need a slow hashing algorithm. Something like sha256 or probably even md5 could be secure enough. But there's little reason not to use something like bcrypt.– bdslCommented Mar 25, 2019 at 22:13
To answer your question, you might want to consider not 'coding' them in, especially if you are using a compiled language. If you do, rotating passwords is much harder. You will also need to consider things like:
- Where you store the passwords, if in a file make sure it is not browsable
- Make sure robots cant find your login (or post-login) pages
- Make sure you still add auth checks on your post-login and all
hiddenpages so you have to login to see them - Hash the password and check hashs, don't encrypt and decrypt them
- Do all this behind SSL
To offer another approach, as a more robust and quite simple to implement solution, I would suggest using OAuth and using a Google or social login, instead of trying to home bake an authentication scheme. OAuth is quite simple now. If you Google OAuth 'your implementation language' you should find some code that is mostly drag and drop.
Yet another approach, if you are not undertaking this for the exercise of coding a blog site, and just want a blog, you would be better served getting a free blog account like WordPress ... or the many others.
As a rule only authentication professionals should undertake writing authentication schemes as it is a complicated area that is prone to error ... and attack to find and exploit said errors.
If you undertake this as a way of learning authentication and all its wonder, you will be on a very satisfying journey.
-
1generally good suggestions (+1) though OAuth has no advantages here. The blog software would still have to store the admin identity, only verification of the identity would be outsourced. You don't have to be an “authentication professional” to safely implement password-based authentication, you just have to use suitable existing crypto algorithms like bcrypt.– amonCommented Aug 30, 2017 at 15:08
-
Tank you for the suggestions. I just started to learn about securing applications and this little app would be my first step. Your answer contains a lot of good ideas that I will definitely consider.– Tamas G.Commented Aug 31, 2017 at 7:14
This is a perfectly good solution for your immediate needs and remains so even if, later on, you do go back and add in the capability for more users. DO NOT create database accounts for each and every client user. Doing so just makes permissions management far more complicated and tiresome, especially for the end user(s).
Contrast these two models:
Model #1: Individual user accounts in the database.
PLUS: Database takes care of authentication; no additional [user] tables required.
MINUS: Database takes care of authentication.
If the user forgets their password, they cannot get into the database in order to reset their password. Results in unhappy users, service desk calls, etc.
MINUS: Database permissions must be set up/ maintained for each and every user. OK, Roles make this a lot easier, but it's still an overhead.
Model #2: "Application" Account
PLUS: Database connections are made through a single account with permissions that are set up once and left in place. No user ever holds the credentials for this account.
PLUS: Password reset capabilities can be offered, because the user can still "get in", even if they've forgotten their [application] password.
MINUS: Application must handle authentication.
You have to add extra tables to manage "your" users, rather than the database doing it "for you".
