8 ms·

> August 2013 > hashed passwords (using MD5) I don't even know what to say. > investigating the creation of forged cookies that could allow an intruder to ac

by niftich 10y ago

> August 2013 > hashed passwords (using MD5) I don't even know what to say. > investigating the creation of forged cookies that could allow an intruder to access users' accounts without a password. Based on the ongoing investigation, we believe an unauthorized third party accessed our proprietary code to learn how to forge cookies How is this possible? Aren't most auth cookies just a session ID that can be used to look up a server-side session? Did they not use random, unpredictable, non-sequential session IDs?

xanadohnt 10y ago
Web tokens, for example, don't necessarily include just a session ID. Some include the full session details within its payload. This can be quite useful, actually, because it offloads session-lookup onto the client.
- camus2 10y ago
  How do you invalidate a JWT server-side without the user interacting with the server ?
  - perlin 10y ago
    With JSON web tokens (JWT), the client or server must know the secret key used to sign the token in order to validate it, but anyone can view its payload.
  - bpicolo 10y ago
    Could do it if you knew the JWT token text in theory?
  - Alex3917 10y ago
    Each JWT has an issued at date, so you just need to reject all tokens issued before that time. In addition to invalidating all tokens if there is a breach, each user account can have its own datefield to invalidate all the tokens for that account if a user changes their password or whatever.
  - xanadohnt 10y ago
    The client can hold onto the token indefinitely, the server doesn't care. But next time a request comes in with that token it will be expired. The server validates the timestamp which is part of the encrypted payload that only the server can decrypt; instant validation and no DB lookup.
    - deleted 10y ago
      [deleted]
  - Normal_gaussian 10y ago
    My preferred method: Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Allow some or all tokens to "refresh" by calling a particular endpoint (call with valid token and get a token with expiry from now). Optionally add some form of identifier to the token (user_id works great) so that you can push a message out to your servers that looks like this: "All tokens for x expiring before y are invalid". Once time y has passed your server can forget about the message. This will be a very small set (often 0) as very few people use the "log out my devices" features. Logouts should be done client side by deleting the token. If you are worried about your token being sniffed you are either not using HTTPS, or sticking it somewhere stupid.
    - danielweber 10y ago
      > Now all token s auto-invalidate after a certain period. You need to make sure that there is some process that will refuse to keep on re-upping the cookie lifetime. Otherwise an attacker could indefinitely keep the stolen cookie alive.
      - merb 10y ago
        You CBS Combine a session cookie with a jwt Token That get sent over a Header
        Normal_gaussian 10y ago
        Which gives you the worst of both worlds
      - Normal_gaussian 10y ago
        If you see a suspicious usage pattern then force a login by invalidating the tokens. Allowing indefinite refreshing is a feature and a drawback of this method.
    - knz 10y ago
      > Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Doesn't JWT already have this - "exp" is a reserved claim for expiration time? https://tools.ietf.org/html/rfc7519#section-4.1.4 https://tools.ietf.org/html/rfc7519#section-4.1.4 4.1.4. "exp" (Expiration Time) Claim The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.
  - corford 10y ago
    Tokens have in-built expiry dates (cryptographically signed by the server upon issuance). Once that date has passed the token becomes useless. If you meant "how can you prematurely invalidate a specific user's JWT without needing a server side lookup", you can't. I think the best you can do is issue different classes of JWT to a user based on what actions you wish to grant them. This lets you reduce load going to backend lookups to only a subset of JWTs where the ability to invalidate them earlier than planned on a per user basis is necessary/desired. For JWTs that aren't tied to backend lookups the only solution if one or more users are accessing resources they no longer should be via one of these tokens is to invalidate all of them.
  - edibleEnergy 10y ago
    This is possible if you support the 'jti' claim[1]. There's a discussion of an implementation of it here[2]. [1]: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#jtiDef http://self-issued.info/docs/draft-ietf-oauth-json-web-token... [2]: https://auth0.com/blog/blacklist-json-web-token-api-keys/ https://auth0.com/blog/blacklist-json-web-token-api-keys/
  - arpa 10y ago
    I'm not too familiar with JWT, but i have some hands-on experience with Macaroons; the simplest way would be to have a custom caveat of validity set in the token, let's say, a validity GUID, which is an id of server-side record of validity (true/false), e.g. in some database table. Once you set that record of validity to false, the token bearing that GUID automatically becomes invalid. Otherwise, without server-side changes (such as change of secret key used for signature generation), it is impossible.
jsjohnst 10y ago
1) As Yahoo "upgraded" all password storage in UDB (where all login / registration details are stored) to be bcrypt before 2013, I'm curious how this was possible. 2) Yahoo doesn't use a centralized session storage. If you know a few values (not disclosing the exact ones) from the UDB, it's theoretically (guess not so theoretical now) possible to create forged cookies if you steal the signing keys. To my knowledge, the keys were supposed to only be on edit/login boxes (but it's been a while so I may be forgetting something), so this is a pretty big breach.
- niftich 10y ago
  Is the info about the Y and T cookies in this pdf [1][2] accurate? [1] (EDIT: now with screenshots) http://imgur.com/a/g61VZ http://imgur.com/a/g61VZ [2] (Not affiliated with link, but the risk-averse may wish to open in a sandbox) ftp://hackbbs.org/milworm/270
  - jsjohnst 10y ago
    Doing a google search for the link showed me the title of the document which I remember reading in the past. The overall coverage of Y&T cookies is more or less accurate at the time of writing back in like 2010/2011, but there's a bunch of mostly minor technical inaccuracies too. I don't want to comment on much without rereading it, but I remember the description of Sled ID made me laugh (which btw I'd guess less than 1% of current Yahoo employees knows what that is).
    - jsjohnst 10y ago
      Also, the video that goes with the PDF is too funny! Just watched it on YouTube [0] again. Notice how he doesn't actually sign into Web Messenger, just goes to the login page? If he had, it would've failed. Same thing with him closing the browser before Yahoo Mail loaded. "Sensitive" reads and everything that did a write operation always (unless there was a bug) validated the cookie against the UDB. So even if you stole the signing key, without the values from the UDB, you would have very limited ability to do anything other than the trivial things shown in the video. [0] https://m.youtube.com/watch?v=n2CNp_zmje8 https://m.youtube.com/watch?v=n2CNp_zmje8
baby 10y ago
I'm wondering if this is one of the reason Alex Stamos left...
imaginenore 10y ago
MD5 is still not too bad, if properly salted. And if you use multiple rounds of hashing, it can be as slow as Bcrypt. As far as I know, MD5 is still not generally broken, we only found some weaknesses. To prove me wrong you can try and reverse this one (unsalted , just one round): 27c8ac15df9357d92385f59aea2049e0
- joatmon-snoo 10y ago
  Even so, the fact that we have the knowledge to generate collisions in MD5 means you really shouldn't be relying on it when there are better alternatives.
  - imaginenore 10y ago
    Try and generate a collision with the hash I gave. You can't, as far as I'm aware. We can only generate collisions of carefully crafted sources, not arbitrary ones. So MD5 is fine, as long as you follow the standard procedure for storing password hashes: 1) Unique salts + long master salt (to prevent rainbow table lookups). 2) Enough rounds of hashing. 3) Don't allow the most common passwords. 4) Don't allow very short passwords. I'm not saying MD5 is ideal, I use Bcrypt / Scrypt myself. But it's not MD5's fault Yahoo's engineers are lame.

by niftich 10y ago

xanadohnt 10y ago

Web tokens, for example, don't necessarily include just a session ID. Some include the full session details within its payload. This can be quite useful, actually, because it offloads session-lookup onto the client.

camus2 10y ago
How do you invalidate a JWT server-side without the user interacting with the server ?
- perlin 10y ago
  With JSON web tokens (JWT), the client or server must know the secret key used to sign the token in order to validate it, but anyone can view its payload.
- bpicolo 10y ago
  Could do it if you knew the JWT token text in theory?
- Alex3917 10y ago
  Each JWT has an issued at date, so you just need to reject all tokens issued before that time. In addition to invalidating all tokens if there is a breach, each user account can have its own datefield to invalidate all the tokens for that account if a user changes their password or whatever.
- xanadohnt 10y ago
  The client can hold onto the token indefinitely, the server doesn't care. But next time a request comes in with that token it will be expired. The server validates the timestamp which is part of the encrypted payload that only the server can decrypt; instant validation and no DB lookup.
  - deleted 10y ago
    [deleted]
- Normal_gaussian 10y ago
  My preferred method: Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Allow some or all tokens to "refresh" by calling a particular endpoint (call with valid token and get a token with expiry from now). Optionally add some form of identifier to the token (user_id works great) so that you can push a message out to your servers that looks like this: "All tokens for x expiring before y are invalid". Once time y has passed your server can forget about the message. This will be a very small set (often 0) as very few people use the "log out my devices" features. Logouts should be done client side by deleting the token. If you are worried about your token being sniffed you are either not using HTTPS, or sticking it somewhere stupid.
  - danielweber 10y ago
    > Now all token s auto-invalidate after a certain period. You need to make sure that there is some process that will refuse to keep on re-upping the cookie lifetime. Otherwise an attacker could indefinitely keep the stolen cookie alive.
    - merb 10y ago
      You CBS Combine a session cookie with a jwt Token That get sent over a Header
      - Normal_gaussian 10y ago
        Which gives you the worst of both worlds
    - Normal_gaussian 10y ago
      If you see a suspicious usage pattern then force a login by invalidating the tokens. Allowing indefinite refreshing is a feature and a drawback of this method.
  - knz 10y ago
    > Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Doesn't JWT already have this - "exp" is a reserved claim for expiration time? https://tools.ietf.org/html/rfc7519#section-4.1.4 https://tools.ietf.org/html/rfc7519#section-4.1.4 4.1.4. "exp" (Expiration Time) Claim The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.
- corford 10y ago
  Tokens have in-built expiry dates (cryptographically signed by the server upon issuance). Once that date has passed the token becomes useless. If you meant "how can you prematurely invalidate a specific user's JWT without needing a server side lookup", you can't. I think the best you can do is issue different classes of JWT to a user based on what actions you wish to grant them. This lets you reduce load going to backend lookups to only a subset of JWTs where the ability to invalidate them earlier than planned on a per user basis is necessary/desired. For JWTs that aren't tied to backend lookups the only solution if one or more users are accessing resources they no longer should be via one of these tokens is to invalidate all of them.
- edibleEnergy 10y ago
  This is possible if you support the 'jti' claim[1]. There's a discussion of an implementation of it here[2]. [1]: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#jtiDef http://self-issued.info/docs/draft-ietf-oauth-json-web-token... [2]: https://auth0.com/blog/blacklist-json-web-token-api-keys/ https://auth0.com/blog/blacklist-json-web-token-api-keys/
- arpa 10y ago
  I'm not too familiar with JWT, but i have some hands-on experience with Macaroons; the simplest way would be to have a custom caveat of validity set in the token, let's say, a validity GUID, which is an id of server-side record of validity (true/false), e.g. in some database table. Once you set that record of validity to false, the token bearing that GUID automatically becomes invalid. Otherwise, without server-side changes (such as change of secret key used for signature generation), it is impossible.

jsjohnst 10y ago

1) As Yahoo "upgraded" all password storage in UDB (where all login / registration details are stored) to be bcrypt before 2013, I'm curious how this was possible. 2) Yahoo doesn't use a centralized session storage. If you know a few values (not disclosing the exact ones) from the UDB, it's theoretically (guess not so theoretical now) possible to create forged cookies if you steal the signing keys. To my knowledge, the keys were supposed to only be on edit/login boxes (but it's been a while so I may be forgetting something), so this is a pretty big breach.

niftich 10y ago
Is the info about the Y and T cookies in this pdf [1][2] accurate? [1] (EDIT: now with screenshots) http://imgur.com/a/g61VZ http://imgur.com/a/g61VZ [2] (Not affiliated with link, but the risk-averse may wish to open in a sandbox) ftp://hackbbs.org/milworm/270
- jsjohnst 10y ago
  Doing a google search for the link showed me the title of the document which I remember reading in the past. The overall coverage of Y&T cookies is more or less accurate at the time of writing back in like 2010/2011, but there's a bunch of mostly minor technical inaccuracies too. I don't want to comment on much without rereading it, but I remember the description of Sled ID made me laugh (which btw I'd guess less than 1% of current Yahoo employees knows what that is).
  - jsjohnst 10y ago
    Also, the video that goes with the PDF is too funny! Just watched it on YouTube [0] again. Notice how he doesn't actually sign into Web Messenger, just goes to the login page? If he had, it would've failed. Same thing with him closing the browser before Yahoo Mail loaded. "Sensitive" reads and everything that did a write operation always (unless there was a bug) validated the cookie against the UDB. So even if you stole the signing key, without the values from the UDB, you would have very limited ability to do anything other than the trivial things shown in the video. [0] https://m.youtube.com/watch?v=n2CNp_zmje8 https://m.youtube.com/watch?v=n2CNp_zmje8

baby 10y ago

I'm wondering if this is one of the reason Alex Stamos left...

imaginenore 10y ago

MD5 is still not too bad, if properly salted. And if you use multiple rounds of hashing, it can be as slow as Bcrypt. As far as I know, MD5 is still not generally broken, we only found some weaknesses. To prove me wrong you can try and reverse this one (unsalted , just one round): 27c8ac15df9357d92385f59aea2049e0

joatmon-snoo 10y ago
Even so, the fact that we have the knowledge to generate collisions in MD5 means you really shouldn't be relying on it when there are better alternatives.
- imaginenore 10y ago
  Try and generate a collision with the hash I gave. You can't, as far as I'm aware. We can only generate collisions of carefully crafted sources, not arbitrary ones. So MD5 is fine, as long as you follow the standard procedure for storing password hashes: 1) Unique salts + long master salt (to prevent rainbow table lookups). 2) Enough rounds of hashing. 3) Don't allow the most common passwords. 4) Don't allow very short passwords. I'm not saying MD5 is ideal, I use Bcrypt / Scrypt myself. But it's not MD5's fault Yahoo's engineers are lame.