3 ms·
Ask HN: How to keep data secure without login?
So I'm building a little demo where I want to persist data for an anonymous user who's trying it out.
Rationale:
- I don't want to have the hurdle of a login as it's just a demo.
- The data, however, is confidential, so I want to keep it as secure as possible.
For the app, the user needs to interact with my DB.
The user's data doesn't need to / must not be exposed to any other devices.
The approach I'm testing right now is a uuid7-based session cookie. All data is tied to that user ID. Once the cookie gets deleted, the machine loses access to the data, which is fine. Also, it would be quite challenging to guess correct user IDs from my understanding. The downside I see is that the cookie could be exposed another way. But since this is a demo...
Can you give me any pointers? I don't want to dump too much time into this, yet keep it somewhat secure.
Are there any elegant approaches for something like this?
- raxxorraxor 3y agoThere is the possibility of using a capability URL: https://www.w3.org/TR/capability-urls/ https://www.w3.org/TR/capability-urls/ Problem is of course that URLs are not treated as a secret, but with widespread TLS I still consider it safe. I do employ some services that make use of it and access logs confirm that it is still a viable solution. Of course it depends on how well users treat this "secret" and the URL should only be valid for a limited time (That can be much longer than the usual PW reset though, depending on your use case).
- rrr_oh_man 3y agoGreat! I tried something similar to this in the early stages without having a name for that concept or an idea of how it should be implemented. You now enabled me to research different approaches. Thanks!
- raxxorraxor 3y agoI think it is one of the very few possibilities to provide privileged info without the need to create an account. Handy for a lot of applications, since users might skip access if they have to register for yet another service. The term "capability URL" isn't too widely known, but the mechanism is very widely spread (almost all password resets for example) and you do find it in several technical documents. Perhaps you could also combine it by then setting a cookie and invalidating the URL to allow for extended access. Just as URLs, secure HTTP-only cookies still do have attack surfaces. But for many applications it does provide "enough" security and storing access tokens client side is common practice. I believe cookies are still the safest option for this compared to local browser or session storage. But I am not sure.
- lesserknowndan 3y agoHow confidential is the information? Perhaps you could allow the token to be password encrypted. Store the encrypted token in local storage and store the decrypted token in session storage.