search

khonsulabs / bonsaidb

A developer-friendly document database that grows with you, written in Rust
https://bonsaidb.io/
Apache License 2.0
1k stars 37 forks source link

Constant-Time Authentication Methods #94

Open daxpedda opened 2 years ago

daxpedda commented 2 years ago

To protect against client-enumeration attacks, it is useful to sometimes build a custom delay when registering or logging in. This is far from ideal and I believe would be better served by the database.

I'm unaware if this is something an other DB implements, but I think it would be incredibly unique and useful.

So the goal is to provide an API to query login data, but the time it takes should always be the same, even if the account doesn't exist. I think this feature would be useful in a couple of other use-cases, but I don't believe it's necessary to expand the scope of this any further, e.g. more complex queries.

ecton commented 2 years ago

I've finally spent some time looking into this rather than just thinking about it.

I'm curious how much of a statistical significance the difference in the response time to the login_with_password request takes. The only difference is the deserialization of the user record itself.

I'm not sure how we can make the lookup constant time without caching the entire user set in memory, which isn't feasible for our hypothetical idea of hosting an MMO -- millions of potential players, I know I wouldn't want to dedicate that much RAM.

I agree with the idea that we should add an artificial delay on all responses, perhaps self-tuning based on measuring the average response time to looking up a user record.

Great suggestion.

daxpedda commented 2 years ago

I agree with the idea that we should add an artificial delay on all responses, perhaps self-tuning based on measuring the average response time to looking up a user record.

As far as I'm aware this is really the only method. Additionally I think what PliantDB can provide here is some sort of heuristic with the available introspection: where user records are located, how far away clusters are that hold user records, and build some kind of smart guess, on top of statistics.

ecton commented 2 years ago

We're a bit early to be designing the cluster response, but I think by each server tuning itself to return an average response time, the quorum itself will be tuned to an average response time. I need to think more on that -- and of course we'll want to actually try to measure that eventually.