This is a really cool product! I'm so glad someone is finally trying to solve this problem.
Not having control of your secrets is a big problem. It is why I continue to use TOTP for some things.
Maybe lean into the practical problem this solves and how it empowers the user?
I am going to suggest this to people. But I feel like I'd have to explain to them what it does, and why it is cool. I remember a few years ago when Keybase took off a few years ago. I think Keybase did a pretty good job of presenting itself to it's audience.
I know plenty of people who understand what a Yubikey is, but might not understand what this app is.
Personally, I love that I could keep backups of my TOTP secret keys in encrypted qr codes on paper in a safe, if I wanted to.
I think it is deeper than just the technical part of it. I think people really like anchoring their accounts to something that they can "see".
It would be really easy to let you import and export your secrets to physical media. And there are some interesting options with chaining your secrets to other hardware tokens (that you are in control of).
Of course it gets very tricky when suggesting anything security related. I don't want to tell people that they shouldn't use hardware tokens. But I think that relying on hardware tokens can be really inaccessible, which can itself be make a system less secure.
I was amazed when I learned that most powerbanks do not function that way. Some of them will switch modes if you unplug them, but there is still an interruption.
It is so nice to be able to unplug my Pi to move it, and have it stay on. I also use them for my usb powered wifi security cameras. So far they have not failed me.
> Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns.
If you scale up high enough, it does matter.
But beyond that, it is also about decoupling the server serving the content and the user database.
To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables to see if a specific user for that specific session is authorized to access that content.
There are going to be many joins involved. Even with good caching, it will still be a more complex operation.
Even if not computationally complex, it will be logically complex.
But when using a JWT, my server actually does not need ANY db access. It merely needs to verify the cryptographic validity of the included JWT header, which uses no IO. After that, it can safely trust any user metadata included in the JWT.
So, if a user has paid for access to all premium content after 2018, you would just include a field for that in your JWT payload. Done.
It depends of course on how your business data models work of course. But you can often put enough information in your JWT to cut out a lot of account processing logic.
> But when using a JWT, my server actually does not need ANY db access.
You don't need any db access with signed cookies either. Just stash your data in a signed cookie and you're done. Should you need more than 4k for session data, maybe it's time to rethink about what should be stored in the session and what should be stored in the db.
When people talk about caching user information, access is one of the things cached. That complicated joining happens exactly as often with sessions as it does with JWT's.
> To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables
It does this on initial logon and then stores it in cache. You can think of a JWT as cache as well.
Still not comparable. Session cookie requires a session datastore server side. It then requires to enable sticky session, to replicate the session between the server or to have a distributed datastore. if user information are cached it will require either a local cache or a distributed cache.
I'm unsure why you're so hell-bent on arguing something so silly, but at the end of the day you made a mistaken point and I responded to it.
You want to try and move the goalpost that's on you, but your point about the joins is flawed. As is the rest of it, but I'm certainly not going to waste my time.
you can use signed cookies for sessions - which have none of the drawbacks you mentioned. i.e. session data and expiration form the payload, and you sign the payload - then you validate the expiration and signature on subsequent requests.
no - i mean the generic concept of a signed cookie as I described, which would have none of the drawbacks you mentioned. They can even be encrypted, if desired.
There are many, many implementations in use "in the wild". They are just signed payloads, so they can contain "expiration", "not-before" or whatever else you think isnt "baked-in". You can use any method of signing them, but would probably make sense to use a strategy that is considered secure :) No doubt the libs you mention can be extended trivially with this "missing" functionality.
Signed/encrypted cookies predate JWT - they even predate JSON...
Im not presuming that they are better/worse than JWT, just responding to the incorrect statement about cookie based sessions requiring server-side storage
I dislike organizations that take open source things like git, and then extend them to add features making them propriety work flow lock in making it hard to move to a new platform
Another company was famous for this, they used to call it Embrace, Extend, Extinguish
I think it is good that it is so flexible, because you never know what kind of data you may want represented on your filesystem. I would rather that there be as few restrictions as possible.
There are cases where you will encounter lots of nasty filenames, especially if you are handling user generated content, like scraping from YouTube or Instagram.
Oh cool! I use nasty-files as a submodule with some of my tests. I can't believe how long I went without without testing against the filename corner cases.
I've found so much software that doesn't properly handle nasty filenames, I think it should be tested for more.
I would try to use JavaScript tooling in JavaScript projects, especially if I share it with other developers.
I would love to see better handling of filename transformation, file watching, and parallelization.
A few times over the years I had given up and just used Make instead of Gulp or Grunt. Most recently, I wanted to watch if files had been deleted (if directory entries had been modified). It ended up being a few lines of Makefile.
And once you understand the syntax, it is expressive and simple, and way more portable. There was some good discussion awhile ago on this[1]:
Thanks for sharing!
I wish this functionality was better exposed, it is such a game changer. I need to clean up and publish some of my scripts. I like to use firejail, xpra, and I'm trying to improve btrfs ephemeral subvolumes for my sandboxes.
Not having control of your secrets is a big problem. It is why I continue to use TOTP for some things.
Maybe lean into the practical problem this solves and how it empowers the user?
I am going to suggest this to people. But I feel like I'd have to explain to them what it does, and why it is cool. I remember a few years ago when Keybase took off a few years ago. I think Keybase did a pretty good job of presenting itself to it's audience.
I know plenty of people who understand what a Yubikey is, but might not understand what this app is.
Personally, I love that I could keep backups of my TOTP secret keys in encrypted qr codes on paper in a safe, if I wanted to.
I think it is deeper than just the technical part of it. I think people really like anchoring their accounts to something that they can "see".
It would be really easy to let you import and export your secrets to physical media. And there are some interesting options with chaining your secrets to other hardware tokens (that you are in control of).
Of course it gets very tricky when suggesting anything security related. I don't want to tell people that they shouldn't use hardware tokens. But I think that relying on hardware tokens can be really inaccessible, which can itself be make a system less secure.
Best of luck!