Compromise your server with this one weird line of code!
One Line of Code That Compromises Your Server
31–40 of 46 posts
Re: One Line of Code That Compromises Your Server
#32I've seen one character compromising the server
Re: One Line of Code That Compromises Your Server
#33Jack Singleton is a developer and security specialist at ThoughtWorks. What a splendid example of an aptronym! [0] [0] https://en.wikipedia.org/wiki/Aptronym
Max Venturi, a test driver at Ferrari, is my favorite one.
Mine is Staff Sergeant Max Fightmaster, US Army.
I'm also found of Rick Wagoner, former CEO of GM, and I often daydream of US Senator Sheldon Whitehouse becoming President.
Re: One Line of Code That Compromises Your Server
#34How long would it have taken to crack the secret on that same setup if HMAC-SHA256 had been used instead?
What's the recommended minimum number of bytes for an HMAC secret when using SHA1? SHA256?
Re: One Line of Code That Compromises Your Server
#35Earlier quoted context omitted.
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 guessi…
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.
Re: One Line of Code That Compromises Your Server
#36Earlier quoted context omitted.
Max Venturi, a test driver at Ferrari, is my favorite one.
Mine is Staff Sergeant Max Fightmaster, US Army. I'm also found of Rick Wagoner, former CEO of GM, and I often daydream of US Senator Sheldon Whitehouse becoming President.
Richie Rich and Bob Diamond - Bank executives is my favourite.
Re: One Line of Code That Compromises Your Server
#37This is why I prefer not to pass session information to the client in the first place. Have the session key be just an opaque, cryptographically random token that is then associated with data on the server (via a keystore of some sort). Then the cookie becomes nothing more than a bearer token. There are some use cases this does not cover, such as authentication across multiple systems, where one or more may not have…
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...
Re: One Line of Code That Compromises Your Server
#38The cookies spec really should be incorporated into the SSL/TLS layer. Right now it's basically performing two encryption/signing steps immediately after each other, one at the web server, and another for the applications server. This is a pain-in-the-ass for the web server framework and adds several milliseconds of redundant latency. The cookie data should be signed with the web server's private key.
Token Binding achieves something simular to what you propose. See http://www.browserauth.net/token-binding
Re: One Line of Code That Compromises Your Server
#39I don't know why anyone would ever do this since there is no cost to SECRET_KEY = os.urandom... or even just hammering on the keyboard. It is not like you are ever going to be challenged for that password? You could even say here is another line of code that will compromise your server: rm -rf /* brb off to search github for SECRET_KEY =
> there is no cost to SECRET_KEY = os.urandom
Only if you generate the key up front and use the same value everywhere.
If you just call os.urandom in your app, then the cost is every restart (and every separate server instance) invalidates the cookies.
Probably not what you want.
Re: One Line of Code That Compromises Your Server
#40Earlier quoted context omitted.
Mine is Staff Sergeant Max Fightmaster, US Army. I'm also found of Rick Wagoner, former CEO of GM, and I often daydream of US Senator Sheldon Whitehouse becoming President.
Richie Rich and Bob Diamond - Bank executives is my favourite.
Rich Fairbank, CEO of Capital One. Doesn't get much better than that, folks.