←back to thread

Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

(github.com)
200 points dcu | 7 comments | 03 Jul 25 15:35 UTC | HN request time: 0s | source | bottom
Show context
fkyoureadthedoc ◴[03 Jul 25 16:07 UTC] No.44456481[source]▶
> Another important file is _users.csv which contains user credentials and roles. It has the same format as other resources, but with a special _users collection name. There is no way to add new users via API, they must be created manually by editing this file:

    admin,1,salt,5V5R4SO4ZIFMXRZUL2EQMT2CJSREI7EMTK7AH2ND3T7BXIDLMNVQ====,"admin"
    alice,1,salt,PXHQWNPTZCBORTO5ASIJYVVAINQLQKJSOAQ4UXIAKTR55BU4HGRQ====,
> Here we have user ID which is user name, version number (always 1), salt for password hashing, and the password itself (hashed with SHA-256 and encoded as Base32). The last column is a list of roles assigned to the user.

I haven't had to handle password hashing in like a decade (thanks SSO), but isn't fast hashing like SHA-256 bad for it? Bcrypt was the standard last I did it. Or is this just an example and not what is actually used in the code?

replies(4): >>44456509 #>>44457381 #>>44457415 #>>44457642 #
1. bob1029 ◴[03 Jul 25 18:02 UTC] No.44457642[source]▶
> isn't fast hashing like SHA-256 bad for it

Fast hashing is only a concern if your database becomes compromised and your users are incapable of using unique passwords on different sites. The hashing taking forever is entirely about protecting users from themselves in the case of an offline attack scenario. You are burning your own CPU time on their behalf.

In an online attack context, it is trivial to prevent an attacker from cranking through a billions attempts per second and/or make the hashing operation appear to take a constant amount of time.

replies(1): >>44459120 #
2. ehutch79 ◴[03 Jul 25 20:58 UTC] No.44459120[source]▶
Users don’t use unique passwords. Don’t expect them to.
replies(1): >>44464498 #
3. sneak ◴[04 Jul 25 13:44 UTC] No.44464498[source]▶
For a backend you can enforce unbruteforceable API keys that are long and random.
replies(1): >>44464731 #
4. ehutch79 ◴[04 Jul 25 14:10 UTC] No.44464731{3}[source]▶
What does that look like, and how does that prevent a compromise exposing users whose non-unique passwords are stored in a known broken hash?
replies(1): >>44465374 #
5. sneak ◴[04 Jul 25 15:29 UTC] No.44465374{4}[source]▶
if you enforce long random server-assigned api keys they are guaranteed to be unique.

you don’t need bcrypt or pbkdf with api keys, as they are not passwords. they are high entropy and unique and long - unlike passwords.

replies(1): >>44466322 #
6. ehutch79 ◴[04 Jul 25 17:23 UTC] No.44466322{5}[source]▶
Ok, but if the passwords are stored in a broken sha hash, and the server is compromised, how do api keys prevent users who use “packers123” for every site from having their passwords exposed?
replies(1): >>44467509 #
7. bob1029 ◴[04 Jul 25 20:11 UTC] No.44467509{6}[source]▶
I think the more interesting conversation goes like:

How many CPU seconds should I burn for every user's login attempt to compensate for the remote possibility that someone steals the user database? Are we planning to have the database stolen?

Even if you spin for 30 minutes per attempt, someone with more hardware and determination than your enterprise could eventually crack every hash. How much money is it worth to play with a two-layer cake of unknowns?

Has anyone considered what the global carbon footprint is of bitcoin mining for passwords? How many tons of CO2 should be emitted for something that will probably never happen? This is like running the diesel generators 24/7/365 in anticipation of an outage because you couldn't be bothered to pay for a UPS.