Live data from Hacker News

Secure database-driven applications on Neocities

fauna.com

1–10 of 15 posts

Re: Secure database-driven applications on Neocities

#2
Author here: Only a few years ago the idea of the browser connecting directly to a cloud database was considered unthinkable from a security standpoint. Now backend APIs are used directly by browser and mobile apps everywhere.

Has anything changed other than developer's comfort with connecting directly from the browser to the backend? Mobile apps are common, and single page applications are accepted. In my experience moving to a simpler stack is good for security.

Re: Secure database-driven applications on Neocities

#3
What is the security model here? I see the word "secure", but no discussion of threat models or what this security provides.

If there's a key that can create users and arbitrary records, and the key is stored in plaintext in your browser code, what's to keep an enterprising user from using your FaunaDB instance as their own data store if they copy-paste the key into their own scripts?

Does FaunaDB protect against a resource usage attack where the client key is used to (maliciously) create millions or billions of new users, costing $$$$?

Re: Secure database-driven applications on Neocities

#5
post #3

What is the security model here? I see the word "secure", but no discussion of threat models or what this security provides. If there's a key that can create users and arbitrary records, and the key is stored in plaintext in your browser code, what's to keep an enterprising user from using your FaunaDB instance as their own data store if they copy-paste the key into their own scripts? Does FaunaDB protect against a r…

Dunno. They have a white paper, but it's not available unless you provide an email.

Re: Secure database-driven applications on Neocities

#6
post #3

What is the security model here? I see the word "secure", but no discussion of threat models or what this security provides. If there's a key that can create users and arbitrary records, and the key is stored in plaintext in your browser code, what's to keep an enterprising user from using your FaunaDB instance as their own data store if they copy-paste the key into their own scripts? Does FaunaDB protect against a r…

Dunno. They have a white paper, but it's not available unless you provide an email.

Link to the whitepaper: https://fauna.com/public/FaunaDB-Technical-Whitepaper.pdf

Re: Secure database-driven applications on Neocities

#7
post #3

What is the security model here? I see the word "secure", but no discussion of threat models or what this security provides. If there's a key that can create users and arbitrary records, and the key is stored in plaintext in your browser code, what's to keep an enterprising user from using your FaunaDB instance as their own data store if they copy-paste the key into their own scripts? Does FaunaDB protect against a r…

You are correct that a script could create new users at machine speed. Rate limiting is typically done outside of the app server stack, but the FaunaDB dynamic schedule, QoS, and quota system have the potentially to mitigate this kind of attack. For instance, as we add support for per-key quotas etc, the publicly exposed key can be provisioned with the limits you describe.

The use case we're illustrating here is support for the early stages of experimental apps. In the case of a successful app needing to patch this vulnerability in realtime, the sensible thing to do may be to put the user creation function behind a Lambda-like endpoint or a smart proxy that can apply non-application logic to manage resource attacks.

You can learn about the object-level security model here: https://fauna.com/documentation/security

Re: Secure database-driven applications on Neocities

#8

{secret:"fnACW7G2d0ACAeiItklGS3QR-FW3sjHK3zwP1kus"} What is the point in having database access with secrets available to the end-user and how is that secure?

This secret is merely the token that allows for new users to sign up. Once you are authenticated, you get a per-user secret that is kept in local storage.

Many signup forms don't even have the equivalent of the first secret. It's purpose is more as a client identifier than a genuine secret. If a malicious client were to grab that published secret, the web service author could rotate keys and put a new secret in the HTML, and rate limit the attacked secret.

Post reply on HN