3 ms·
> imagine an Internet where the data about each user (what would normally be entries in different tables on the servers) is stored, encrypted and authenticated,
by theseoafs 12y ago
> imagine an Internet where the data about each user (what would normally be entries in different tables on the servers) is stored, encrypted and authenticated, on the user's computer, as opposed to being stored on the server.
Trying to authenticate solely on the client side isn't as fruitful as you might be imagining, since it introduces potential security isues. Without any server-side authentication using only information (i.e. a blob) that the server has access to, it becomes very easy for clients to spoof/pretend to be other clients.
Consider that if this kind of system were easy/fruitful to implement, a lot of businesses would have done it already to avoid increased development/server costs on their end.
- Potando 12y agoThis is kind of what some sites use to eliminate signing up and logging in - give each user a unique URL that itself is enough to authenticate them. Not great for security, but OK for a game or something that doesn't matter too much.
- thegeomaster 12y agoIf the data is encrypted and authenticated with a server-known key, you couldn't change the data and end up with the server accepting it. How would a spoofing scenario work in this case? If you can steal another user's blob, you can pretend to be them, but if you can steal that blob, you can also steal a cookie if the website uses cookies for authentication. Maybe I am misunderstanding you. One issue I can think of is users spoofing older blobs (reminiscent of a replay attack). I believe this could be mitigated if the server keeps a single 256-bit hash of each user's state (this would also make client-side HMACs redundant), or a 64-bit ever-increasing integer which is then included in the state. That's way more tiny than any user state.