3 ms·

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? Password

by bonaldi 15y ago

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.

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

by bonaldi 15y ago

buu700 15y ago

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.

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.