Not a first time Chess.com has an alleged leak, this one seems to be like the ones before but on a larger scale

The dump had a uuid column and a member_since column. UUIDv1 isn't random, it embeds a 60-bit timestamp, so if the data is genuine the two should agree. They did, 100.00% across 200k rows: python import uuid, datetime u = uuid.UUID("0bcc8686-c684-11e7-805e-000000000000") print(datetime.datetime.utcfromtimestamp((u.time - 0x01b21dd213814000) / 1e7)) # 2017-11-11 02:00:09 <- exactly the claimed signup time Two other tells that it's a scrape and not a breach: captured_at spans nine consecutive days in uneven batches, and 7.4% of user_ids repeat, all of them the same account re-captured on a later date, zero byte-identical rows. A table dump doesn't repeat its primary key. Caveat we can't resolve: every row has Google Ad Manager audience tags, which aren't in the public API. No passwords or payment data in the set.The dump had a uuid column and a member_since column. UUIDv1 isn't random, it embeds a 60-bit timestamp, so if the data is genuine the two should agree. They did, 100.00% across 200k rows: python import uuid, datetime u = uuid.UUID("0bcc8686-c684-11e7-805e-000000000000") print(datetime.datetime.utcfromtimestamp((u.time - 0x01b21dd213814000) / 1e7)) # 2017-11-11 02:00:09 <- exactly the claimed signup time Two other tells that it's a scrape and not a breach: captured_at spans nine consecutive days in uneven batches, and 7.4% of user_ids repeat, all of them the same account re-captured on a later date, zero byte-identical rows. A table dump doesn't repeat its primary key. Caveat I can't resolve: every row has Google Ad Manager audience tags, which aren't in the public API. No passwords or payment data in the set. submitted by /u/lexcor [link] [comments]

from hacking: security in practice https://ift.tt/RoJTQXI