Live data from Hacker News

Secure database-driven applications on Neocities

fauna.com

11–15 of 15 posts

Re: Secure database-driven applications on Neocities

#11
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 supp…

Given your response here, I think using the word "secure" in your article title is disingenuous.

You shouldn't promote a practice or technique as "secure", but then when asked about security, tell me that the sensible thing to do is to implement security myself.

You should discuss the limitations of your actor-based security model frankly in your documentation and promotional tutorials. Even more so because you plan more security features like "key-based quotas", indicating y'all are well aware of these limitations, and foresee the need for more mitigations!

As it is, I think FaunaDB is an interesting product, but because of the approach to security related messaging, I view the whole system with distrust. What other "lies of omission" would I find if I actually started using this product?

Re: Secure database-driven applications on Neocities

#12
post #11

Earlier quoted context omitted.

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 supp…

Given your response here, I think using the word "secure" in your article title is disingenuous. You shouldn't promote a practice or technique as "secure", but then when asked about security, tell me that the sensible thing to do is to implement security myself. You should discuss the limitations of your actor-based security model frankly in your documentation and promotional tutorials. Even more so because you plan…

How is this different than someone attacking a contact form on a wordpress site? In your mind what would be a sufficient mitigation for a service like this? A one time use token for example? Captcha on the signup form?

Re: Secure database-driven applications on Neocities

#13
post #12
post #11

Earlier quoted context omitted.

Given your response here, I think using the word "secure" in your article title is disingenuous. You shouldn't promote a practice or technique as "secure", but then when asked about security, tell me that the sensible thing to do is to implement security myself. You should discuss the limitations of your actor-based security model frankly in your documentation and promotional tutorials. Even more so because you plan…

How is this different than someone attacking a contact form on a wordpress site? In your mind what would be a sufficient mitigation for a service like this? A one time use token for example? Captcha on the signup form?

Yeah, I think your suggested mitigations sound reasonable. Everything in this space is going to be only partial mitigations, but it should still be discussed, especially if "secure" is a selling point and given that the FaunaDB service is billed based on usage.

What I would do:

- one-time use token for the creation form, a la CSRF tokens and nonces; Although that just doubles the number of requests needed to perform a submission

- rate-limit all endpoints based on IP, user agent, etc

- Captcha on creation form

Re: Secure database-driven applications on Neocities

#14

{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 H…

Would you consider my private keys secure if I posted them here and said that I would rotate them as soon as someone uses them in a way I don't like?

Re: Secure database-driven applications on Neocities

#15

Earlier quoted context omitted.

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 H…

Would you consider my private keys secure if I posted them here and said that I would rotate them as soon as someone uses them in a way I don't like?

It's common for client applications to encode a client secret. Many API client apps use a model like this, for example Firebase calls their equivalent token an API Key.

The "secret" in this case is really being used to select a context. So the secret you'd embed in your copy of the app would differ from mine, and it would point to your database, not mine.

Post reply on HN