4

I am new to NOSQL and Cassandra. I am not sure if I should store usernames and password in Cassandra. If I should, what is the best way to do that? I am getting lots of conflicting ideas from research. I want to set it up to accommodate a large number of users and be able to quickly access it. Think of it as for hosting thousands of profile pages and have it open to add as much as needed in the future.

I know Cassandra is tune-able eventual consistency. I know password and usernames and things need to me very consistent.

The rest of the application/database doesn't need anywhere the level of consistency as the username and login system needs.

Should I do two different Cassandra databases? Can I set up all of it in one Cassandra database? Should I use a different type of database for login and then have Cassandra serve everything else.

I been doing research for days, but nothing definitive. If someone with experience can guide me in the right direction for this and give me like a diagram of how I should setup this up, I would really be grateful.

2
  • You will probably find it easier to use MySQL (or another relational database) for the authentication mechanism of your application. It appears that Casandra is capable of encryption, but the setup/configuration is fragile by comparison. Commented Feb 11, 2016 at 3:42
  • I know MySQL is a breeze, by I would like to be scalable by design. I don't mind doing extra work to set the database up right so i could avoid headaches later. My problem is: how would I get around the whole eventual consistency and setup the login authentication mechanism so it would be able to handle large number of users and won't break because of username or password inconsistency.
    – Nick
    Commented Feb 11, 2016 at 4:10

1 Answer 1

-1

In answer to your question, unless you really need your own login, you should allow users to login with OpenID. If not, just decide how to store passwords yourself (try not to store them the same as any other site would) with this rule

  • Two users with the same password should NOT have the same password hash. This can be achieved by either concatenating a unique id (not the best way), their username (SMF) or by using salting in whatever algorithm you're using.

This is extremely important, as although you shouldn't have any leaks, you really don't want the same problem as Adobe had with their passwords due to the fact they weren't salted and people were able to group users by passwords and use hints/other info to work them out. In big enough datasets like this, you could group by passwords and find users who are all named Jack Smith and born in 1992, which would give you some idea of what their password is. Ensure that you use something relatively secure (as in, don't use MD5), SHA512 isn't really that secure and ideally you want to use bcrypt (if you're using PHP) or something designed for this.

Again, you will find MySQL much easier (use PHP Data Objects!) and the other database platforms. I personally don't know much about NoSQL, however I imagine it does what the other "scalable" databases of the day do, such as leaving out integrity checks, not writing to disk (hah, Mongo) and various other little things which, have their own problems with scalability and problems with reality.

I would say that you shouldn't worry about the scalability of MySQL, at the end of the day, if your project needs a more powerful MySQL server as everything's already setup with MySQL you can just use Google Cloud SQL or many other solutions that are being developed.

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.