My Favorite Database is the Network | Hacker News Reader

My Favorite Database is the Network

lucumr.pocoo.org

Technology, just like fashion, is cyclical. There are only so many configurations of communication patterns so technological constraints dictate usefulness.

The two being contrasted here are the one centralized database (w/ master/slave, replica sets, etc of course) versus a peer-to-peer configuration.

We've been in a centralized hub and spoke model as cloud servers have taken off. As clients get more powerful and network links slow[1], we're going to move more to peer-to-peer models.

The concept described by the author is right in the middle: hub and spoke, but keep all the data on the spokes. Of course, the comments (EGreg) points out that this has a disadvantage of difficult access if the spoke is storing another spokes information.

Adding a couple peer-to-peer connections can help with this and WebRTC is a good technology for doing it. Once you connect peers, you can move data from peer-to-peer without hitting a central server again. Now, the central server is merely orchestrating rather then dictating.

The author (author of flask, werkzeug, ...) is probably on the forefront of things, so while you may not find that this model is useful yet, it's prudent to watch as it will become more prominent in the next couple years.

[1] Phones are getting more powerful and computers/laptops already feel like overkill for the youtube/redditing etc that we do. Networks are not slowing so much as wireless connections are getting clogged as more people are overloading cell providers.

You really need to be careful how you implement the signing of these types of systems. I have broken several of these systems and extracted the secret key. If you can extract the secret key, you can essentially become anyone and do anything that is controlled by the state in the cookie. Properly implemented, this shouldn't be a problem. I recommend having a separate key for each client session and storing the sessions in something fast and ephemeral like memcache. This has the advantage of also giving you a place to store another secret key for CSRF mitigation. Storing information in the cookie is convenient but it isn't without its risks.

That kind of defeats the purpose of what's being proposed. Why wouldn't you just store all of the data in memcache instead of just the key? If you lost the memcache you're losing all of your sessions either way.

One way you could get around it would be some kind of time based key like an RSA token. That way each of the servers would know all of the tokens a priori and you only accept that token for a limited period of time. Not perfect, but you still benefit from not being tied to your database.

Looks like this is only useful for storing objects related to a single session of a user. If you have more than one device accessing the same data on a server, the server needs to persist the data between requests.

However, it would be interesting to get rid of the client/server dichotomy and use WebRTC between clients.

Is this use of MD5 subject to the known length extension attack? If so, what would a better alternative use for an HMAC hash?

Discussed here: http://tools.ietf.org/html/rfc6151

The articles recommends using a form of HMAC and not MD5 directly. The first code example is just a basic example of what the general concept behind is.

I guess this is yet another reminder that the first example sticks (waterfall model).

That particular case isn't vulnerable to length extension, since the key is placed at the end of the message. This MAC breaks down, however, when the function used is not collision-resistant.

HMAC offers some level of protection against collision-weak hash functions, and that's why you can still use HMAC-MD5 today and be pretty OK (although I don't recommend it!).

If it was `message = payload + "." + MD5(secret_key + payload)` then yes, it would be vulnerable.

It is `message = payload + "." + MD5(payload + secret_key)` though, so it is not vulnerable. The attacker cannot extend the payload part.

In other words, the "signed-secret cookie" session-store approach of Rails et al, but for data bigger than a user ID.

Reply on news.ycombinator.com