The attack in the article isn't about a malicious user eavesdropping and obtaining someone else's cookie directly. It's about a user who gets a cookie from the server, brute-forces to determine the key used to sign the cookie, and then uses that key to generate cookies that authenticate them as other users (or that execute code during deserialization, etc).
@franciscop -- keep an eye out for the rest of the article (it's already written and will be released soon). I go over the impacts of an attacker knowing the secret in much more detail. I also have sections on prevention for both application developers and library/framework authors that I think you'll find interesting!
I'll wait for it, because I don't fully understand @AgentME's comment "to generate cookies that authenticate them as other users". Those auth cookies would have a hashed token per user that must be created and validated in the back-end (besides the encryption). So just storing 'user-ID' should not be enough, you'd have to be able to decrypt a real user's cookie to know this token hash (and for this reason just guessing numbers/users ID would not be enough as well).
The cookie that the user gets might be something like userid + ":" + HMAC(server secret, userid). The user who gets that cookie can brute-force HMAC(x, userid) with different values of x until they get a match for the string in their cookie, at which point they know the server secret. Then with the server secret, they can generate a valid cookie for any userid.
That is exactly what I mean, you are not supposed to save the user id (hashed, encrypted or otherwise) in the cookie. You are supposed to save a random secure token that will be associated to that user's device/login. If you save the user id it'd be as an index, not for auth as the token is for that. See http://stackoverflow.com/a/32218069/938236
Of course then it depends on the developer, so statistically speaking there will be a % who do what you suggested and making it secure from the library/framework side would help some users, so I'm all in for it.
That strategy is often called sessions or a stateful-cookie. It requires all of the servers that accept that cookie to be able to share their session state (or for a strategy like sticky sessions to be used). The strategy I described is stateless: the servers only need to share the secret in order to verify the cookie. It's a popular strategy but it does have some trade-offs, such as being vulnerable to anyone who knows the secret.
Let's say your Python web application pickles your sessions so you can store more than just JSON serializable fields. Unpickling can result in the execution of arbitrary Python code and the only thing normally protecting you is that you MAC your session with the secret key (which was just cracked...)
