I shouldn't trust a hashed username and password? How are server-based systems more secure?
you don't trust what the client says they can do
That's a non-issue if it's handled by ACLs on the server.
you don't trust what they're giving you
Like I mentioned before, though, for most applications you can trust what they're giving you. Sure, Amazon isn't going to ask the client how much an iPad costs and WoW isn't going to ask the client for the player's stats, but why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request / wall post / whatever? If you attempt to perform an unexpected action (say, post to the wall of someone who's blocked you), the other user's client application logic (which is beyond your control) can still handle the junk data gracefully and simply.
Also, later on (when you have more developer time to spare), if you want to for whatever reason, you can easily just deploy a server-side "garbage collector" of sorts to regularly clean up the database without disrupting client-side flow.
It's not something you bolt on later.
It can be, provided that it's only in the form of new features rather than fixing something which was insecurely implemented to start with. (For example, maybe the MVP is free but the next iteration is freemium and requires server-side price validation.)
I shouldn't trust a hashed username and password? How are server-based systems more secure?
How are you going to verify the password without a server? Passwords are a server-based system.
That's a non-issue if it's handled by ACLs on the server.
ACLs fine-grained enough to handle modern security scenarios are going to be just as complex as doing traditional validation. Any non-trivial sites are quickly going to get way more complex than just doing it the old-fashioned way. So why bother?
why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request?
Because privacy is mission-critical for Facebook, and an exploit that allows me to send a friend request to myself as you is an unmitigated disaster for them. And trivial to do in a mostly-client world. Beyond trivial if I have access to the other client, which I am one browser bug or open wifi access point away from having.
It can be, provided that it's only in the form of new features
And those new features are going to be written in what? Since your MVP's framework doesn't support server-side logic, you're now splitting your code in three. Now you're either in maintenance or rewrite hell, just as you're taking off.
That's not one of the good problems to have, it's one of the stupid problems you should have avoided by laying the right foundations at the start.
How are you going to verify the password without a server?
Only a dreadfully insecure system would choose to compare plain text passwords over the standard practice of hashing. It makes no difference if the hash is done client-side or server-side; if anything, even with SSL it's more secure to keep the plain text password removed from the network.
ACLs fine-grained enough to handle modern security scenarios are going to be just as complex as doing traditional validation.
How so? If I can manage my Facebook privacy settings graphically, any developer can manage ACLs in a DB schema graphically. No reason to unnecessarily clutter up code and deal with pointless architectural issues.
Because privacy is mission-critical for Facebook, and an exploit that allows me to send a friend request to myself as you is an unmitigated disaster for them. And trivial to do in a mostly-client world. Beyond trivial if I have access to the other client, which I am one browser bug or open wifi access point away from having.
Uh, what? If you have access to someone else's account then the game is already lost; no backend can solve that.
Since your MVP's framework doesn't support server-side logic, you're now splitting your code in three. Now you're either in maintenance or rewrite hell, just as you're taking off.
...What? Who says whatever framework I use won't support server-side logic? Even vanilla JavaScript or jQuery is fine for AJAX calls. Not sure where you're getting "rewrite hell" from, but you must really hate the client APIs provided by Google, Yahoo, Facebook, and Microsoft.
A hash (like a plain password) is just a meaningless string unless you have something to compare it to. That means you have to store a trusted version elsewhere. Eg: a server.
any developer can manage ACLs in a DB schema graphically
And the client?. When I as user make you admin of my facebook event, how do I do it? Can my client side code change the access for other users? That might be, y'know, bad. Exploitable.
Uh, what? If you have access to someone else's account then the game is already lost; no backend can solve that.
Not access to someone else's account, just access to the other client via the network, browser bugs, bad proxies etc. It's a whole flock of blacksheep. There is a world of XSS that is only stopped by having wary, untrusting servers.
Who says whatever framework I use won't support server-side logic
Hi. This is a thread about Fireball, which is a new BaaS, one that promises no server-side logic. You appear to be defending this idea. Now I wonder if you understand it. We are not just talking about "some code running in the client".
If you want to say client side code is fine so long as you have server-side logic for sanity checking, well, yes. Yes, it is. That's my point.
Okay, I think I was unclear in my proposal. None of what you've said is related in any meaningful way to my idea, but I think that was my fault for just pointing out the "important" parts and assuming the rest would fall into place naturally for everyone else.
---
This is the system I'm suggesting Firebase implement:
* User registers client-side with a username and password; username and password are salted/hashed to an auth key, which is then sent to the server and put into a server-side key-value store with the username.
* User logs in to the client; auth key is reconstructed and stored to a cookie to be sent with each Firebase access.
* Whenever a field in Firebase is created, an associated "owner" property is set to the username of the user who created the field, and an associated "group" property is set based on an optional API parameter with a default value of null.
* Each field has pseudo-chmod-style permissions settings of the form read/modify/create for owner/group/world; everything is "777" by default, but a simple administrative Web UI allows the developer to define database schemata and assign permissions settings.
* Groups are implemented as server-side lists of usernames.
* When a client attempts to perform an operation through Firebase's API, first the "world" permissions are checked; if the operation is allowed, it completes normally.
If the operation in question is a "create" operation, only the "world" permissions can be reasonably utilised, so if the operation is not allowed and the operation is a "create" operation, then no change is made to the data and an error code is returned (or printed to logs or something).
If the operation is not allowed and not a "create" operation, then the owner's auth key is retrieved from the earlier key-value store and compared with the auth key from the client; if the keys match, the "owner" permissions are checked to determine whether the operation is allowed; if the operation is allowed, it completes normally.
If the keys don't match or the operation isn't allowed, a search is performed to determine whether the username associated with the client auth key is in the appropriate group; if so, the "group" permissions are checked to determine whether the operation is allowed; if the operation is allowed, it completes normally.
If the group is null, the user isn't in the group, or the operation isn't allowed, no change is made to the data and an error code is returned.
---
A hash (like a plain password) is just a meaningless string unless you have something to compare it to
This should be clear now.
Can my client side code change the access for other users?
No. As mentioned above, permissions are set by the developer.
Not access to someone else's account, just access to the other client via the network, browser bugs, bad proxies etc.
I haven't seen any XSS vulnerabilities inherent to the Firebase JS library. Everything else can be reasonably addressed with SSL and a secure browser.
This is a thread about Fireball, which is a new BaaS, one that promises no server-side logic.
Don't be a condescending prick, especially when you're the one who's wrong. We were specifically on the topic of adding price validation to a freemium Firebase application; you still have yet to explain what's stopping me from leaving the bulk of my code as-is and using AJAX off my server only for the price validation.
Don't be a condescending prick, especially when you're the one who's wrong.
Stop, just stop. This isn't right/wrong, because we don't even seem to be having the same conversation. Everything you talk about assumes and depends on having a server and server-side logic. Your arguments all amount to "I can totally do client-side-only, I just have to do X on my server". Like:
Which is then sent to the _server_ and put into a server-side key-value store with the username.
Right, so your solution for Firebase is that they should have more server-side stuff? Good, we agree. Wait:
We were specifically on the topic of adding price validation to a freemium Firebase application; you still have yet to explain what's stopping me from leaving the bulk of my code as-is and using AJAX off my _server_ only for the price validation.
What's stopping you is that in this scenario you don't have a server! So if you want to add this, you have to now add a server. Now you've got your MVP running on Firebase, and a new server-side setup, just to add a feature? Seems like a disaster.
(To be fair, Firebase are talking like they'll make some private quasi-sessions that could act as servers, but setting up conversation between them and the clients sounds like a recipe for callback spaghetti, at the very least.)
The point the OP, some other posters here and I am trying to make is that client-side sounds great -- it's way simpler, for sure -- until you start to think about security. Because, frankly, security depends on things not being in the client's control, and that means servers.
If you disagree with that, please email me, because this conversation is now adding no value to HN.
Sorry, I have no idea what you are shadow-boxing at, any more. There are questions over security with Firebase. They say it will be fine when they're done. You say it will be fine in 80% of cases if they implement your idea.
I suspect that whatever the final solution is, it is going to be just as complicated as what we have now. Security isn't easy. Disabling it sure makes for great demos, though.
Er...... I don't think you understand what Firebase is... Obviously they're still running servers; the entire service is basically hosted MongoDB with a clever Scala API and a JS library that further abstracts Socket.IO.
Jeez, HN needs a better system for nested replies. Anyway.
You seem to think it can be patched up by turning it into something else. Great, we agree that it doesn't work as is, then.
Well, yeah, of course. The whole discussion started off as a debate about whether and how they could go about implementing security after the beta launch.
It's pretty well understood by all parties (and admitted by the founders themselves) that security isn't something Firebase is currently equipped to handle...
---
Sorry, I have no idea what you are shadow-boxing at, any more.
I've gone above and beyond in terms of explicit clarity to un-derail this conversation. Which part of my solution are you confused about? (I don't think I was too technical, but I can explain in more detail if necessary.)
I suspect that whatever the final solution is, it is going to be just as complicated as what we have now.
Do you mean that my system would be too complicated for developers? (The operation seems pretty straightforward to me.) Or are you just implying that you think they'll go in a different direction which involves a lot more developer labour?
You have been saying it should be mostly possible. I am sceptical.
In that case, do you see a specific hole in my design, or are you just unclear in general about how it would be used?
Yes. The discussion was over whether proper security is something it could ever be equipped to handle in an all or mostly-client world. The founders have been saying it is (and pointing to Office as an example). You have been saying it should be mostly possible. I am sceptical.
Read their front page. "No servers, no server side code". Of course there are actually servers involved, but they're inaccessible by the developer.
That's the whole point of this post: how much access will devs have to the servers, and how? Until those questions are answered, explicitly explicitly, doubts hang over the whole idea.
You seem to think it can be patched up by turning it into something else. Great, we agree that it doesn't work as is, then.
So you're saying that all server-side data that all apps using Firebase want to store should be stored centrally on Firebase owned servers. i.e since trusted user/pw hashes must be stored on a server to be matched against and the only server we have is the one that Firebase provides, all apps using Firebase will store these hashes on central servers owned by Firebase.. That sounds like a really bad idea.
I shouldn't trust a hashed username and password? How are server-based systems more secure?
you don't trust what the client says they can do
That's a non-issue if it's handled by ACLs on the server.
you don't trust what they're giving you
Like I mentioned before, though, for most applications you can trust what they're giving you. Sure, Amazon isn't going to ask the client how much an iPad costs and WoW isn't going to ask the client for the player's stats, but why should an application like Facebook care to verify whether you want to modify your own settings or send a friend request / wall post / whatever? If you attempt to perform an unexpected action (say, post to the wall of someone who's blocked you), the other user's client application logic (which is beyond your control) can still handle the junk data gracefully and simply.
Also, later on (when you have more developer time to spare), if you want to for whatever reason, you can easily just deploy a server-side "garbage collector" of sorts to regularly clean up the database without disrupting client-side flow.
It's not something you bolt on later.
It can be, provided that it's only in the form of new features rather than fixing something which was insecurely implemented to start with. (For example, maybe the MVP is free but the next iteration is freemium and requires server-side price validation.)