5 ms·

over the standard practice of hashing A hash (like a plain password) is just a meaningless string unless you have something to compare it to. That means you ha

by bonaldi 15y ago

over the standard practice of hashing 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.

buu700 15y ago
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.
- bonaldi 15y ago
  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.
  - buu700 15y ago
    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.
    - bonaldi 15y ago
      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.

by bonaldi 15y ago

buu700 15y ago

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.

bonaldi 15y ago
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.
- buu700 15y ago
  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.
  - bonaldi 15y ago
    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.