Hi, by now it seems to be common knowledge that passwords shouldn’t be stored in a database. Backend devs generally know to hash and salt and what-not their transmitted passwords. It seems to be well documented.
However, I wasn’t exactly able to find such a clear answer for client applications accessing e.g. web APIs. For example, lets assume you were to create a Lemmy desktop application with support for multiple accounts. Ideally, that software would work like a password manager and store its master password as hash only.
However(2), sometimes users like to start said application without entering their password. Like an Email client in pleb mode. Which requires the passwords to be stored somewhere. In this case, what is the best course of action?
You deskktop app could login to Lemmy via the web app and store the login cookie as it’s token for future access. This security is effectively on-par with the existing web app in terms of what happens if the machine falls into bad hands.
But the same thing via an API would be preferred.
The idea that you can login to a website and get a cookie that last 3 weeks may feel absurd, but when you think about clients keeping unencrypted passwords it sort of makes it more appealing comparitively. Especially if you can lock down the cookie to the hardware to prevent theft somehow.