Obsoleting Passwords

dkokelley, discussing the future of security:

Until we discover and implement a better system that obsoletes passwords, the best we can really do is have long, complex, and unique passwords for everywhere we go, and have a system to manage them for us. I believe that something like LastPass or KeePass are the way to go for now.

Passwords, in their current form, don’t seem like they’ll stand the test of time for digital security. This is a problem that needs solving. I just installed LastPass this week. I’m still waiting for something better.

See the full comment or the discussion.

How can client-side databases be secure?

Seeing Meteor and Firebase all over HN has been exciting - I’m currently building a Node.js application but not using as much real-time updating as I could, largely because of the effort involved all over the application.

One of the benefits of developing with Node is that you can use the same code on the front and back-end, which is especially helpful for things like data validation, which some sites are inconsistent about. Meteor and Firebase are the answer to the implied question: if the code is the same in both places, do we really need it in both?

In the aftermath of building my own Firebase app in 5 minutes (!), I saw the concerns sprout up. No, I’m not talking licensing, I’m talking security. Timo Zimmerman’s post outlines how the lack of security and maturity in Meteor makes it just a toy:

There is currently no authorization or authentification system. It is planed[sic] but not implemented. So you basically expose your whole database to every client without any way to add some security.

I had seen the point about the lack of authorization in another comment on HN about Firebase (can’t find it now, oops), both of which got me thinking: how could you do authorization for a database that’s fully exposed on the client side?

When the database is completely accessible from the client, and the client can freely modify the code used to access it, isn’t it impossible to have real security?

You could limit what they have access to through some sort of ACL, but that would introduce a lot of backend complexity to your app, and involve Firebase/Meteor dictating part of your database schema. And in fact, you would have to have even more granular limits than just “Can Only Modify Record 1”, as certain parts of records have to be protected. So much for “all in the client” or “No servers.”

It seems like a great idea, it really does. And maybe I’m missing something obvious here (I hope), but it just seems downright impossible to secure a system like this. Isn’t one of the guiding principles of security “Don’t trust the client”?

I guess I’ll wait until they reveal what they’re planning.