2

I'm working on a messaging application, based on a server/client architecture. Now I am thinking about the way how to store the user credentials. It's not a huge number, just about 20 entries with their User-IDs, Usernames and hashed passwords.

Storing it with a SQL Server in my opinion is overkill. Is it better to store it in sort of a text file or in a SQLite database file? These methods would keep the server portable and the installation simple.

And is password hashing enough to keep the passwords secret?

What is the best way to handle this?

Improve this question

2 Answers 2

Reset to default
2

If you only need to cater for such a small amount of users, you could also consider delegating credential storing to some other service, such as Google or Facebook. This is usually preferred since the user needs to remember one less set of credentials and you have one less thing to worry about.

That being said, this could be problematic if you want to run your application offline (intranet). In that case, I would go to an SQLLite approach. This would also allow your application to scale up to a certain extent, and if you would need to move to a more robust SQL server, you would already have the data in the format required, so the migration would not be that much of a headache.

Lastly, when it comes to storing passwords, if you really must do it yourself, I would recommend using salted hashes to store your database. You should find plenty of examples online to do it with your technology of choice.

Improve this answer
3
  • I looked into salted hashes, and it occurs to me that we can simply concat the user name and the password before hashing. That would fix the 'problems' that salted hashing is supposed to fix. Is it right?
    – InformedA
    Commented Jun 24, 2014 at 6:13
  • @randomA: Assuming that you do not have users with the same username and password, what you are suggesting could help.
    – npinti
    Commented Jun 24, 2014 at 6:24
  • I can't really think of a system that allow same username, let alone same username AND password.
    – InformedA
    Commented Jun 24, 2014 at 7:24
0

You can take the file approach as long as you acknowledge and understand all the implications of this. There are many applications that do this. For example adding/editing a user will possible require a re-configure/re-start of your application and the involvement of an admin. Depending on how your application will be used that could be too slow or perfectly fine.

If you do continue with the file approach it will probably be more efficient to load that into memory at the app boot time. If you don't want to restart the app when you change the config file you could add a monitor on the file to track changes and force a reload.

Hashing passwords should be fine as long as you salt them and use a proper hashing algorithm. Have a look at BCrypt.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.