4 ms·

Good article and callout for those projects (and mine). I am doing an express alternative[1] with something that is not secure as a temporary session secret[2]

Good article and callout for those projects (and mine). I am doing an express alternative[1] with something that is not secure as a temporary session secret[2] formed with `secret: 'secret-' + parseInt(1000000 * Math.random())` so I'll modify it to use a real random key from a crypto library or display a prominent warning. Then I am also documenting it in a small production security guide [3]. Also, if the key in the documentation is used there's a warning[4] similar to how Dropbox stops you from using 'correct-horse-battery-stapler' as a password. If you have any other tip/recommendation I'd be really thankful. BTW, doesn't SSL/TLS mitigate this a lot? Like, if the user is using SSL then only with physical access to a decrypted device would an attacker be able to impersonate the user, limiting greatly the possible attacks. And if someone has access to your decrypted device then you have bigger problems. Though devs who don't change 'super secret' are probably probably less likely to set up https... Edit: I almost didn't include the BTW comment because I agree that it is an important part of security, so I didn't want to make it sound less severe, but I am curious about attack possibilities with https enabled. [1] https://serverjs.io/ https://serverjs.io/ [2] https://github.com/franciscop/server/blob/master/src/config/defaults.js#L8 https://github.com/franciscop/server/blob/master/src/config/... [3] https://github.com/franciscop/server/issues/3 https://github.com/franciscop/server/issues/3 [4] https://github.com/franciscop/server/blob/master/src/config/index.js#L45 https://github.com/franciscop/server/blob/master/src/config/...

AgentME 10y ago
SSL doesn't protect you from a malicious user who is trying to crack the key used on the cookie you gave him. It just means that no one else will eavesdrop on the malicious user's connection.
- franciscop 10y ago
  But then it also means the malicious user cannot eavesdrop on other users, so other users will be secure, right?
  - AgentME 10y ago
    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).
    - jacksingleton 10y ago
      @AgentME -- correct @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!
      - franciscop 10y ago
        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).
        AgentME 10y ago
        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.
        franciscop 10y ago

AgentME 10y ago

SSL doesn't protect you from a malicious user who is trying to crack the key used on the cookie you gave him. It just means that no one else will eavesdrop on the malicious user's connection.

franciscop 10y ago
But then it also means the malicious user cannot eavesdrop on other users, so other users will be secure, right?
- AgentME 10y ago
  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).
  - jacksingleton 10y ago
    @AgentME -- correct @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!
    - franciscop 10y ago
      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).
      - AgentME 10y ago
        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.
        franciscop 10y ago