Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One Line of Code That Compromises Your Server

martinfowler.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: One Line of Code That Compromises Your Server

#41

Post by jsjohnst »

hdhzy wrote: post #37
fpgaminer wrote: post #27

Earlier quoted context omitted.

The reason is that, at scale, all the little things matter. Having to query your database for _every_ user request, to convert their session token into the server-side underlying data, gets expensive and slow. And it's a centralizing force in the architecture, requiring your session management database to be accessible by all your user facing servers. So they store the data with the client, who can pass it back to th…

> One less DB query. This trait constantly appears in threads about JWT. But then how do you handle token invalidation? I wonder how big IT companies (Google, Microsoft, Amazon) are really doing it...

Most of the big companies to my knowledge generally don't depend on client side storage of session state (they might in a few isolated cases, but in general avoid it).

Re: One Line of Code That Compromises Your Server

#42

Post by hdhzy »

jsjohnst wrote: post #41
hdhzy wrote: post #37

Earlier quoted context omitted.

> One less DB query. This trait constantly appears in threads about JWT. But then how do you handle token invalidation? I wonder how big IT companies (Google, Microsoft, Amazon) are really doing it...

Most of the big companies to my knowledge generally don't depend on client side storage of session state (they might in a few isolated cases, but in general avoid it).

Thanks.

Google uses interesting approach to handling service accounts: JWT is used as user credential once to get the access token (session credentials) that is reused between requests.

https://developers.google.com/identity/protocols/OAuth2Servi...

Re: One Line of Code That Compromises Your Server

#43

Post by franciscop »

eleumik wrote: post #26

What do people here use to store password for servers ? Plain text configuration files ? I have pwd of DB in config files and found no way to put it elsewhere.

Environment variables which depending on the host are done differently. For heroku it's a setting, for a bare bones server it'd be a plain file called .env.

Re: One Line of Code That Compromises Your Server

#44

Post by AgentME »

franciscop wrote: post #35
AgentME wrote: post #23

Earlier quoted context omitted.

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 t…

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.

Re: One Line of Code That Compromises Your Server

#45

Post by kuon »

ameliaquining wrote: post #3
kuon wrote: post #2

I think any sane framework should generate a random secret each time an app is generated.

No; Django does that, and the result is that people check that random secret into source control. The correct solution is to not have the secret in code at all, but to read it at initialization time out of some kind of secrets management system (traditionally via environment variables). Unfortunately, frameworks generally can't do this in a hosting-setup-agnostic way; you have to understand the specific facilities th…

I am not saying the secret should be in the code itself.

The app generator could generate a .gitignore including another dotfile with the secret in it. Or print a message on how important it is to configure the secret properly.

My point was that a framework should not generate a working value that is insecure. And if generating no value and have the app not start without additional configuration is the best way, this should be the way to go.

Re: One Line of Code That Compromises Your Server

#46

Post by eleumik »

mkarazin wrote: post #28
eleumik wrote: post #26

What do people here use to store password for servers ? Plain text configuration files ? I have pwd of DB in config files and found no way to put it elsewhere.

Plain text can work, assuming that it is access controlled in a secure environment. Often times, during the build process, a secure secret management system or process will handle the combining of the code with configuration. For example, your developer (with no secret access) could commit code and Jenkins can fetch the configuration file from a secure and access-controlled service. Then the built code has the secret…

Thanks ! very nice overview.
Post reply on HN