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